CAA records and certificate issuance: how to fix errors

Read the DNS response before changing records

Suppose issuance fails for www.shop.example.com. Start with that exact name and inspect its parents and any CNAME target. These dig commands keep the DNS status header visible; a short answer alone can hide the difference between no records and a failed lookup. Replace the example names with your own.

NOERROR with no CAA data at a name can be a normal empty answer; continue the applicable lookup instead of declaring the whole policy absent. SERVFAIL is a lookup failure, not permission to issue. Record the status and returned owner names alongside the certificate provider’s exact error.

dig www.shop.example.com CAA +noall +comments +answer
dig shop.example.com CAA +noall +comments +answer
dig example.com CAA +noall +comments +answer
dig www.shop.example.com CNAME +noall +comments +answer

1. List every requested certificate name, including apex, service and wildcard names, and identify the intended issuing CA.
2. Check the exact names, relevant parents and any returned CNAME targets; keep DNS failures separate from empty answers.
3. Compare the effective records with the provider’s current requirements, make the smallest justified correction and retry issuance after DNS answers update.

Reference: ISC BIND: dig queries and output controls

Read the tags and the actual CA identifier

CAA values use the CA’s documented authorization identifier, which need not match the issuer’s display name in a certificate or your hosting brand. Let’s Encrypt uses letsencrypt.org. The BIND-style record below is appropriate only if Let’s Encrypt is an intended issuer at that name. It is an example to merge into a reviewed policy, not a replacement for all existing records.

Use flags 0 for ordinary records. Flag 128 marks a property as critical: a CA that does not understand or support its tag must not issue. It is not a priority value. Check provider-specific parameters as well as the identifier.

example.com. 300 IN CAA 0 issue "letsencrypt.org"

Reference: Let’s Encrypt: CAA identifiers, flags and parameters

Find the applicable policy without merging parents

Under RFC 8659, query the requested name with normal DNS alias following. If no CAA set is found, repeat at its parent, continuing up the original name’s ancestors until a set is found or the DNS root is reached. The first non-empty set applies; parent policies are not merged into it.

A CNAME can therefore lead to the applicable CAA set. If that alias lookup finds no CAA, resume at the parent of the original queried name, not automatically at the alias target’s parent. Do not add CAA alongside a CNAME at the same DNS owner.

For *.shop.example.com, start with shop.example.com. Within the relevant set, issuewild overrides issue for the wildcard request; without issuewild, issue applies. Check every certificate name separately. A policy containing only iodef does not itself restrict issuance.

Reference: RFC 8659: relevant CAA sets and wildcard processing

Fix the failed layer and keep required issuers

For an authorization error, verify which CA will issue the replacement or renewal. A managed CDN can use several partner CAs, and those requirements can change. Check the current provider documentation and the returned DNS records; a dashboard may omit provider-managed additions. Preserve the authorities and parameters still required by your active services instead of blindly replacing everything with the example above.

For SERVFAIL, investigate DNSSEC validation, authoritative-server availability and DNS handling with your DNS provider. Repeating the certificate order does not repair a persistent DNS failure. Compare authoritative answers and a validating recursive resolver; successful authoritative output alone does not demonstrate successful DNSSEC validation.

Do not delete CAA as a generic workaround. Correct the intended restriction or DNS fault, allow cached answers to expire, then use the provider’s retry or staging workflow. CAA authorization still leaves domain-control validation and the provider’s other issuance checks to complete.

Reference: Cloudflare: managed CAA records and current CA requirements

Use CheckSSL as evidence, then verify issuance

CheckSSL performs a bounded CAA lookup through aliases and parents and reports found, absent or unknown. It displays discovered values; it does not interpret every flag or parameter, decide whether a particular CA is authorized, validate DNSSEC itself or simulate domain-control challenges and complete issuance.

An unknown result can reflect a timeout, DNS failure, alias loop or lookup limit. An absent result means this lookup found no CAA set, not that the CA’s request will succeed. CAA findings are separate from the served certificate’s trust and CRL revocation results.

1. Save the corrected policy and confirm it covers every requested name and required issuing service.
2. Confirm the provider actually completes issuance or renewal, then deploy the resulting certificate.
3. Check the public hostname again for the expected certificate, trust, name coverage and validity.