A CAA Record Missing the Renewal CA Silently Blocks Certificate Issuance

Symptom

A certificate renewal or reissue request fails with an authorization or CAA-related error from the certificate authority (CA), even though the domain previously had a valid certificate issued without incident. The failure appears only when switching ACME clients, adding a backup CA, or moving from a manual CA workflow to automated issuance. DNS resolution, domain ownership and the ACME challenge (HTTP-01 or DNS-01) all succeed; only the final issuance step is rejected.

Operators report the domain as “correctly configured” because the zone has an existing CAA record and the previous certificate issued without issue.

False Assumption

The team assumes that because a CAA record already exists in the zone and a certificate was issued successfully in the past, the domain is authorised for certificate issuance from any CA the organisation intends to use. In reality, CAA authorisation is scoped strictly to the issuer domain names listed in the record at the time of the issuance request; a prior successful issuance only proves the record permitted that specific CA, not any CA the organisation may add later.

Root Cause

RFC 8659 defines the CAA (Certification Authority Authorization) DNS record type to let a domain owner specify which CAs may issue certificates for that name. A CAA record’s issue or issuewild property names exactly one CA per record; any CA not listed, and not covered by a wildcard-permissive absence of records, must decline to issue. When a domain migrates to a new CA, adds a backup or secondary CA for redundancy, or begins using an ACME account tied to a different issuer, the existing CAA record still authorises only the original CA. CAA validation is mandatory under the CA/Browser Forum Baseline Requirements, so a conforming CA will refuse to issue rather than override an unmatching CAA record. Because CAA lookups also check parent domains under the tree-climbing algorithm in RFC 8659, a permissive record on a parent zone can mask the problem for some subdomains while blocking others, producing inconsistent, misleading failure patterns across a single organisation’s estate.

Impact

Certificate renewal automation fails at the least convenient moment, typically shortly before expiry, because the failure is invisible until an actual issuance attempt is made against the new or additional CA. Multi-CA resilience strategies silently do not provide the intended redundancy: if the primary CA has an outage, the configured backup CA will also be rejected by CAA, and the organisation loses the intended failover capability without any warning until it is needed. Expired certificates cause service outages, browser trust warnings and, for automated systems relying on mutual TLS or API certificate pinning, hard connection failures.

Diagnosis

Confirm the presence and scope of CAA records using read-only DNS queries before making any change.

dig +short CAA example.com
dig +short CAA www.example.com
dig +short CAA _acme-challenge.example.com

Expected evidence: the output lists zero or more issue/issuewild lines, each naming exactly one CA domain (for example 0 issue "letsencrypt.org"). If the CA you intend to use, or its ACME account issuer domain, is not present in this output for the exact hostname requesting the certificate, and no permissive record exists at that name or a parent name, issuance for that CA will be refused. Cross-check the failing CA’s exact issuer domain string against your ACME provider’s published documentation, since some CAs use a different CAA identifier than their brand name (for example, some providers require the account-URI or validation-methods parameters defined in RFC 8657 for stricter scoping).

Also check parent zones, since CAA lookup climbs the DNS tree until a record is found:

dig +short CAA com
dig +short CAA example.com

Correction

Update the CAA record set to explicitly authorise every CA the organisation actually uses, including backup or secondary CAs, rather than relying on a single legacy entry. This is a state-changing DNS zone edit and must be validated in a non-production or delegated test zone first where practicable.

# Example additive record set (apply via your DNS provider's zone editor or API)
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "digicert.com"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:security@example.com"

Add records incrementally, one CA at a time, and confirm propagation before removing any existing record, so that no window exists where the active issuing CA is unauthorised. Do not delete the original CAA record until the replacement set has been confirmed live via authoritative lookup.

Validation

Validate the change by querying the authoritative nameservers directly and by performing a real ACME dry-run or staging issuance against every CA that must be authorised.

• Action: query the authoritative nameserver directly rather than a caching resolver, using dig @ns1.example-dns-provider.net CAA example.com; expected evidence: the response includes an issue entry for each CA in use; pass condition: every CA the organisation currently uses, or plans to use for failover, appears in the authoritative response.
• Action: run the ACME client’s staging or dry-run issuance flow (for example the Let’s Encrypt staging environment) for the specific hostname and CA combination being added; expected evidence: staging issuance succeeds without a CAA-related error; pass condition: staging issuance completes for each authorised CA in turn.
• Action: confirm TTL-appropriate propagation time has elapsed since the change, using repeated dig queries against multiple public resolvers; expected evidence: consistent CAA output across resolvers; pass condition: no resolver still returns the pre-change record set after the TTL window has passed.

Rollback

If the corrected record set causes an unexpected issuance failure for a CA that was previously working, revert by re-adding the original single-CA CAA record alongside the new entries rather than removing the new entries outright, preserving all previously working authorisations while investigation continues.

1. Re-confirm the exact original record value from your DNS provider’s change history or zone backup before editing.
2. Re-add the original issue record for the previously working CA through the provider’s zone editor or API, as an additive change, not a destructive replace.
3. Re-query authoritative nameservers with dig @ns1.example-dns-provider.net CAA example.com to confirm the original entry is present again alongside any entries you intend to keep.
4. Re-run the affected CA’s staging issuance flow to confirm the rollback restored working authorisation before resuming normal operations.

Stop condition: if authoritative lookups do not reflect the intended record set within twice the zone’s configured TTL, halt further edits and escalate to whoever holds DNS zone administration access, since repeated conflicting edits can produce inconsistent results across resolvers.

Prevention

Treat CAA records as a change-controlled artefact tied explicitly to the list of CAs an organisation is authorised and intends to use, reviewed whenever a new CA, ACME account or certificate automation tool is introduced. Add CAA monitoring to certificate lifecycle automation so that a planned CA change or failover CA is validated against CAA authorisation before it is relied upon in production, not discovered during an actual outage. Where multiple teams manage different subdomains, document CAA scope explicitly per zone, since the tree-climbing lookup behaviour means a permissive or restrictive parent-zone record can silently override subdomain expectations.