Your CDN dashboard says domain validation passed, but the managed certificate still fails to issue. Re-entering the validation record may not help: the certificate authority also checks CAA to determine whether it is authorized to issue for the domain. AWS Certificate Manager explicitly documents CAA errors that can occur after successful validation.[1]
This guide is for operators managing DNS and CDN certificates. Identify the issuer and the failed stage, inspect the effective CAA records and DNS responses, then make a narrowly scoped change. Replace the example domains with your own. The commands below are read-only; this guide is based on official documentation, without production DNS changes or issuance tests.
Identify the stage that failed
DNS resolution, domain-control validation, certificate issuance, and deployment to CDN edge nodes are separate checks. Save the complete error message, certificate order status, requested domain names, and the validation method specified by your platform.
A pending validation status calls for checking the required TXT record, CNAME, or HTTP file. An explicit CAA or unauthorized-issuer error calls for checking issuance authorization. If the certificate has already been issued but browsers still report errors, inspect hostname coverage, the certificate chain, and CDN deployment.
Confirm the actual CA and its CAA identifier with the platform. A CDN brand name is not necessarily the value you should authorize. The letsencrypt.org examples here illustrate Let’s Encrypt’s rules; they do not identify the default issuer for CloudFlew or any other CDN.[2]
Inspect the full DNS response
These commands work on Linux, macOS, or WSL with dig installed. Keep the response status and the ANSWER and AUTHORITY sections during the initial investigation; +short alone hides useful context.
dig www.example.com CAA dig www.example.com CNAME dig example.com CAA dig example.com NS
Check the response status, record owner names, and TTLs. A NOERROR response without a CAA answer requires different handling from SERVFAIL, REFUSED, or a timeout. A failed query does not establish that the domain has no issuance restrictions.[2]
In a simple case without a CNAME, the CA starts with the requested name and queries parent names until it finds the first applicable CAA record set or reaches the root. A subdomain’s own CAA record set stops that search; it is not automatically merged with the parent’s records.[3]
For example, an issue policy at example.com may affect www.example.com when the latter has no CAA records. Check every name in a multi-domain certificate order, rather than only its primary domain.
Follow CNAMEs without confusing the parent lookup
CAA queries follow CNAME aliases. If www.example.com points to a hostname supplied by the CDN, the answer may contain CAA records from that target. Looking only at the apex records in your DNS dashboard can miss this part of the lookup.[2][3]
dig www.example.com CNAME dig www.example.com CAA # Replace this placeholder with the actual CNAME target returned above dig actual-cdn-target.example.net CAA
RFC 8659 defines the search in two parts: a CAA query for the current name follows DNS aliases; if that query returns no CAA record set, the algorithm removes the leftmost label from the current search name and queries its parent. This is not a general instruction to walk through every parent of the CNAME target.[3]
In ordinary DNS configurations, a CNAME cannot coexist with ordinary records such as CAA at the same owner name. Do not add a CAA record directly alongside an existing www CNAME. If the effective restriction comes from a provider-controlled alias target, ask that provider to verify its records and supported issuers. Changing your own apex CAA records may not resolve that restriction.[2]
ALIAS, ANAME, and CNAME flattening depend on the DNS provider’s implementation. Inspect the public DNS answers and consult that provider’s documentation for these configurations.
Interpret issue and issuewild before changing records
The following is an illustrative DNS zone-file example. DNS dashboards often provide separate fields for the name, flags, tag, and value. Confirm the required issuer before applying a production change.[2][3]
example.com. 300 IN CAA 0 issue "letsencrypt.org" example.com. 300 IN CAA 0 issuewild "letsencrypt.org"
issue authorizes an issuer. In the absence of issuewild, it also applies to wildcard issuance. When issuewild is present, wildcard issuance follows those authorizations instead. If a regular hostname succeeds but *.example.com fails, inspect the wildcard policy separately.[2][3]
Multiple authorizations with the same tag are additive. Preserve the CA authorizations that your other services still need when adding another issuer. An issue ";" entry grants no authorization by itself; it does not override a valid authorization elsewhere in the same applicable set. A relevant set containing only denial entries blocks issuance.[3]
Parameters in the value can impose further restrictions. Let’s Encrypt supports validationmethods and accounturi, which restrict challenge methods and ACME accounts respectively. Check whether parameters copied from an older setup match the current platform’s workflow.[2]
Deleting all CAA records broadens issuance permissions and may conceal a restriction located elsewhere. Export the relevant DNS records first, including their values and TTLs, and record the change time. Modify the effective record set only after confirming the issuer. To roll back, restore the saved values and check the public DNS answers again.
Investigate SERVFAIL and timeouts as DNS problems
CAA lookups can fail because of DNSSEC validation errors, unavailable authoritative servers, incorrect handling of the CAA query type, or firewalls dropping queries. Let’s Encrypt documents these failure modes separately.[2]
Compare recursive and authoritative answers:
dig @1.1.1.1 www.example.com CAA dig @8.8.8.8 www.example.com CAA dig example.com NS # Replace this placeholder with an authoritative server for the relevant zone dig @ns1.example-dns.net example.com CAA +norecurse
The public resolvers above are cross-checks. Their successful responses do not prove that the CA’s resolution path works. An authoritative server for the original domain may return only a CNAME; inspect the target domain separately. For a separately delegated subdomain, query that subdomain’s authoritative servers.
If recursive queries return SERVFAIL while authoritative queries return records, investigate DNSSEC and the delegation chain. Different answers from authoritative servers call for checking zone synchronization and NS configuration. Save the query output for your DNS provider; avoid disabling DNSSEC as a workaround.[2]
After a change, compare authoritative and recursive answers and account for the previous TTL or negative caching. Refreshing a browser does not clear a CA’s DNS cache. Repeated issuance requests do not make an unpublished or cached DNS change visible sooner.
Check the validation records required by the current order
Correct CAA authorization does not complete domain-control validation. For Let’s Encrypt ACME, DNS-01 uses a TXT record under _acme-challenge. HTTP-01 uses a specified HTTP path on port 80 and cannot issue wildcard certificates. Let’s Encrypt supports CNAME or NS delegation for DNS-01 challenge names.[4]
A managed CDN certificate may instead require a dedicated validation CNAME. Use the exact name and value from the current order. A business hostname pointing to the CDN does not automatically satisfy certificate validation.
# Use these checks only when the platform explicitly uses ACME DNS-01 dig _acme-challenge.example.com TXT dig _acme-challenge.example.com CNAME
CAA checks concern the name being certified, while challenge records demonstrate domain control. Placing CAA on _acme-challenge does not fix the business hostname’s issuance authorization. Avoid removing a live business CNAME while investigating a certificate failure.
Once the underlying issue is fixed, follow the platform’s retry or reapplication instructions. AWS ACM requires a new certificate request for its documented post-validation CAA failure case; verify the procedure for other platforms individually.[1]
Verify edge deployment and future renewal
After issuance succeeds, check the CDN’s certificate binding and deployment status. Visit the actual hostname and inspect the certificate in the browser. Confirm that the SAN covers the requested hostname, the validity dates are correct, and the connection is not still presenting an older certificate. Order completion and delivery of the new certificate to visitors need separate confirmation.
Document the requested names, actual CA, effective CAA location, validation method, and DNS changes. Retain persistent validation CNAMEs when the managed platform requires them for renewal. Let the ACME client manage single-use DNS-01 TXT records according to the challenge lifecycle; those records have a different purpose.
Continue monitoring expiry and automated renewal after this order recovers. A record of the working configuration helps identify conflicts before a future change of CDN, CA, or DNS provider.
Official references
Sources verified on October 13, 2026.
[1] AWS Certificate Manager: Certification Authority Authorization (CAA) problems. The failure case and reapplication requirement here are specific to ACM.
[2] Let’s Encrypt: Certificate Authority Authorization (CAA). Configuration, aliases, issuer identifiers, and DNS errors.
[3] RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record. Applicable record-set lookup and authorization rules.
[4] Let’s Encrypt: Challenge Types. HTTP-01, DNS-01, and challenge delegation.
