Domain connected but HTTPS certificate not issued? Check hostnames, CAA and validation

A hosting platform accepting your custom domain does not prove that its HTTPS certificate has been issued, deployed or configured for every entry point. Record the certificate status and error before changing anything. This guide focuses on issuance; missing pages and failed business APIs need separate checks.

Separate issuance, deployment and access problems

Describe the failure precisely: www.example.com may be waiting for validation while example.com already works. Treat them as separate test cases. A working root domain does not establish that www is ready.

Match coverage to the exact hostname

List the root domain, www and campaign subdomains you intend to launch. Check each against certificate coverage. For example, Cloudflare Universal SSL alone in a full DNS setup covers the root and first-level subdomains; deeper names need an appropriate certificate option. Its CNAME setup has different rules. This product-specific limitation is not a rule for every host.

Buying a domain at one company does not establish who issues every website certificate. For a third-party website builder, inspect that project's custom-domain and HTTPS instructions. With a proxy, distinguish the certificate delivered to visitors from the one used at the origin.

Put validation records in authoritative DNS

Confirm the active nameservers and edit the provider actually serving authoritative DNS. It may differ from the company that sold the domain. Copy the record type, full name and value supplied for the current request. Check that a dashboard has not appended the zone suffix twice, and do not reuse a value from an older request.

DNS and HTTP validation follow different paths. Let's Encrypt DNS-01 checks a specified TXT record; HTTP-01 retrieves a challenge response at a defined path. A working homepage does not prove that the challenge path works. Do not add an unrelated challenge method unless the platform requests it.

Cloudflare TXT validation can require multiple values, and an unvalidated hostname can prevent the certificate from being issued. Check every supplied record, then use the platform's recheck procedure. Preserve automation or delegation needed for renewals; confirm a record's purpose before removing it.

Check CAA permissions separately from routing

CAA limits which certificate authorities can issue; it does not replace A, AAAA or CNAME records or domain control validation. A restrictive policy must allow the CA actually used for the request. Do not copy another site's CA list. Cloudflare's partner CAs and requirements can change, so consult current product documentation.

Inspect applicable CAA at the hostname, parent domains and CNAME target. Distinguish issue from issuewild when checking wildcard requests. Even without manually configured CAA, a lookup failure can matter: a failed query is different from a successful query returning no CAA records.

Do not make deleting every CAA record the default fix. Save the policy, identify its owner and other services that need issuance, then make the smallest justified change. Changing permission does not bypass domain control validation.

Keep a repeatable acceptance record

Verify each adjustment before moving to another. Repeated issuance requests are not a diagnosis, and there is no universal waiting-time promise. Give support the hostname, status, error text and change time, without private keys or DNS API credentials. Once HTTPS passes, continue with redirects, canonical URLs and the sitemap. Reachability and search indexing are separate results.