A certificate renewal can fail even though the existing certificate still works and the DNS address is correct. Certification Authority Authorization, or CAA, is one place to investigate. A domain's CAA policy can restrict which certificate authorities may issue new certificates for its names.
CAA is an issuance control. It does not revoke certificates already issued, replace domain validation or guarantee that a website is secure. Its operational value comes from making the permitted issuers explicit while keeping the policy consistent with the services that renew your certificates.
Read the three parts of a CAA record
A CAA record contains flags, a property tag and a value. Common tags include issue for ordinary issuance, issuewild for wildcard issuance and iodef for incident-reporting information. The value's meaning depends on the tag and can include issuer-specific parameters.
The CAA policy analyzer reviews pasted records and highlights their structure. It does not contact a certificate authority or prove that a renewal will succeed. Use the DNS explorer separately to check what the relevant names currently publish.
Read the complete record set. Several issue records can authorise several issuers. A single displayed line is not necessarily the full policy. Record the owner name too, because an apparently correct policy at the wrong DNS name may not be the one used for the certificate request.
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild ";"This example authorises the named issuer for ordinary issuance and expresses a restrictive wildcard policy. It is an illustration, not a recommendation for every deployment. Confirm the issuer identifier and any parameters against your certificate provider's current documentation before using them.
Find the policy that applies to the requested name
CAA processing includes a lookup procedure that can find policy at the requested name or a relevant ancestor, with alias handling defined by the standard. Do not assume the apex domain's policy always applies unchanged to every hostname. A more specific record set can alter the effective result.
For a certificate containing several names, the issuer must evaluate the relevant authorisation for those names. A renewal that adds a new subdomain can encounter a policy that the earlier certificate never needed to satisfy. Review the complete requested name list rather than checking only the first subject alternative name.
Managed hosting and CDN services may obtain certificates through an issuer different from the one used by your origin server. Inventory both paths. Restricting CAA to the origin's issuer can unexpectedly block a managed edge certificate even though the origin renewal continues to work.
| Question | Evidence to collect | Action |
|---|---|---|
| Which issuer renews the certificate? | Provider documentation and account configuration | Authorise the correct issuer identifier |
| Is a wildcard requested? | The complete certificate name list | Review issuewild and its relationship to issue |
| Where is policy found? | Requested name, aliases and ancestors | Inspect the effective lookup path |
| Did policy recently change? | Old values and TTLs | Allow caches and provider checks to refresh |
| Are unknown critical properties present? | Flags and tags in the full set | Confirm issuer support before deployment |
Separate wildcard and ordinary issuance
When issuewild properties are present, they control wildcard issuance according to the CAA rules. If they are absent, issue properties can govern wildcard authorisation as well. This distinction is easy to miss when a team adds a wildcard certificate to an existing non-wildcard deployment.
A certificate for *.example.com also has name-matching limits separate from CAA. It does not automatically cover the apex or every deeper level. Keep certificate identity rules and issuance authorisation in separate checks; a permitted issuer can still issue a certificate whose name coverage does not fit your application.
Use explicit test cases for the names your automation requests. A staging order can reveal a policy problem before expiry, but check whether the provider's staging and production environments use the same authorisation requirements. Record any difference in the renewal procedure.
Work through a change of certificate provider
Suppose example.com currently authorises provider A and is moving to a service using provider B. First identify B's documented CAA identifier and any required parameters. Add the intended authorisation while A remains available for the existing service, if that overlap fits your policy.
Verify the authoritative DNS response and allow for the previously cached TTL. Then request the new certificate and confirm that the deployed service presents it correctly for every required hostname. A successful order in a control panel is not the same as the edge actually serving the new certificate.
After migration and a verified renewal path, remove obsolete authorisations when appropriate. Keep the old provider's role in mind if any subdomains still use it. A company-wide CAA cleanup should begin with a service inventory, not with deleting every issuer except the one used by the main website.
Keep rollback practical. Reauthorising an issuer can take time to propagate, and the old certificate may expire during a poorly timed migration. Start well before the deadline and preserve the evidence of a successful renewal, including the requested names and issuing service.
Handle flags and reporting properties deliberately
The issuer-critical flag affects how an issuer handles an unrecognised property. A record with a critical property that the issuer cannot process can prevent issuance. Do not copy flag values from an example without understanding which property is being marked and whether your issuer supports it.
An iodef value identifies a reporting destination under the CAA specification. It does not guarantee that you will receive a report for every rejected or suspicious attempt. If you publish an address or endpoint, ensure it is monitored and that the receiving workflow can handle useful incident information.
Keep reporting contacts current when teams change. A syntactically valid mail address that nobody reads provides little operational benefit. Test ownership and routing without generating unnecessary certificate requests, and document who handles any resulting reports.
Separate CAA refusal from other issuance errors
An order can fail because domain validation failed, a rate limit applied, DNS was unavailable or account configuration was wrong. Preserve the certificate authority's actual error message. The presence of a CAA record does not mean CAA caused every renewal failure.
Check DNS resolution from the issuer's likely perspective, including authoritative consistency. A resolver failure is different from a successfully retrieved policy that denies the issuer. If DNSSEC is misconfigured, repair the chain rather than assuming an ordinary A record proves all required DNS lookups are healthy.
After fixing the cause, repeat the exact order through the normal automation and verify deployment. Manually issuing a certificate once can hide an unchanged scheduled-renewal problem. The final success criterion is a working renewal path with monitoring before the next expiry window.
Review all names in a certificate order
A certificate order can include the apex, a www name and a wildcard, each requiring the applicable CAA evaluation. Keep the complete requested name list with the renewal evidence. If only one name fails authorisation, the order may still fail as a whole. Test the exact production order rather than a reduced sample that omits the problematic hostname. This is especially useful when a provider quietly adds an alternate name to its managed certificate configuration.
Frequently asked questions
Does adding CAA invalidate my current certificate?
No. CAA governs issuance checks; it does not revoke an existing certificate. If you need revocation, use the issuer's revocation process and address the reason for it. Still plan CAA changes carefully because a policy that permits today's certificate may block its next renewal.
What happens if I publish no CAA records?
Absence of an applicable CAA restriction does not itself prohibit issuance. Certificate authorities still apply domain validation and other requirements. CAA adds a way to restrict issuers; it is not the mechanism that proves you control the requested domain.
Can I authorise two issuers?
Yes, multiple appropriate issue records can authorise multiple issuers. This can support migrations or services with different certificate providers. Keep each authorisation justified by an active workflow and review it when the service is retired, rather than allowing the record set to accumulate indefinitely.
Does issuewild replace issue for all certificates?
It addresses wildcard issuance. Ordinary certificates still need evaluation under the relevant issue policy. Review both tags when the same automation obtains wildcard and non-wildcard names. A test of only the main hostname may miss the wildcard path used by another service.
Can the analyzer prove the issuer will accept my policy?
No. It reviews the supplied text. Effective DNS lookup, issuer-specific parameters, validation and account state still matter. Confirm the live records and run an appropriate issuance test through your provider before relying on the configuration for an approaching renewal.
Why did a CDN migration change the required issuer?
The CDN may manage its own edge certificate lifecycle through a different authority. Your origin certificate and the certificate presented to visitors can be separate assets. Inventory both and follow the CDN's documented CAA requirements so an origin-only policy does not block the edge.
Should I remove CAA during an outage?
First identify the exact refusal and the intended authorisation. A targeted correction is easier to review than an unexplained policy removal. If an incident procedure temporarily changes policy, record the reason, verify the result and restore the intended restriction after the renewal path is working.