How CAA Can Block Certificate Renewal
An ACME client can prove control of a hostname yet still fail to obtain a certificate because the relevant CAA policy does not authorize the selected issuer. For example, an applicable issuewild record may allow only another CA, even though issue allows Let’s Encrypt for normal names. Check authorization separately from challenge validation so a renewal error leads to a change in the correct layer.
This guide covers CAA for public website TLS certificates: selecting the relevant DNS record set, separating normal and wildcard permissions, using optional IODEF reports, and coordinating Let’s Encrypt and ZeroSSL with ACME automation. The record sets below are alternative policies. Inspect the existing complete set before choosing one; adding every example together changes its meaning.
What CAA Controls
Certification Authority Authorization publishes a DNS policy for certificate issuance. A compliant CA evaluates the relevant set for every requested hostname and wildcard identifier. If no applicable issuance restriction exists, CAA imposes no issuer limit; domain validation and the CA’s other requirements still apply. Authorization does not prove that the ACME client chose the intended provider, and changing CAA does not revoke certificates already issued.
Maintain a separate inventory of certificate names, issuing accounts and deployment targets. A single certificate containing example.com and *.example.com requires the chosen CA to be authorized for both identifiers. A correct CAA answer is only one prerequisite: successful renewal must also create an acceptable certificate and deploy it at the actual TLS terminator, which may be a CDN or load balancer rather than the origin server.
CAA Syntax: issue, issuewild and iodef
A zone-file record includes its owner name, TTL, class, CAA type, numeric flags, property tag and quoted value. DNS control panels often present these as separate fields. Each issue or issuewild value names one issuer, with any supported parameters after semicolons. Multiple issuer permissions use separate records. The examples use flags 0 and an explicit one-hour TTL; adapt the owner and panel syntax carefully.
issue governs issuance for normal names and also governs wildcard issuance when no issuewild properties appear in the relevant set. The identifier letsencrypt.org authorizes Let’s Encrypt. Permissions within the selected property type are additive: one valid authorization can allow that issuer. An additional empty issuer does not override it, and a separate unrestricted permission can bypass a constraint placed on another record.
issuewild applies specifically to wildcard identifiers such as *.example.com. When present, it replaces issue for wildcard authorization; it is ignored for normal names. When absent, issue applies to wildcards too. Remove the leading *. to determine where the relevant CAA lookup starts. You need distinct issuewild entries only when expressing a separate wildcard policy or making the same permission explicit.
iodef supplies a contact for policy-violation reports, if the CA implements reporting. It provides neither an issuance permission nor a guarantee of alerts. The defined report format is IODEF. Email and HTTPS have specified transport behavior; an arbitrary JSON webhook is not automatically a compatible receiver. Continue monitoring ACME failures and certificate expiry regardless of whether any report arrives.
accounturi can limit a supporting CA’s individual authorization to a particular ACME account. Let’s Encrypt also supports validationmethods with http-01, dns-01 and tls-alpn-01. These constraints belong to their specific permission; an unrestricted permission for the same CA remains another way to authorize it. Verify current provider support instead of copying parameters to a different CA and assuming enforcement.
The following complete alternative authorizes Let’s Encrypt and the Sectigo identifier used by ZeroSSL for both normal and wildcard names. The mailto report contact is optional. No empty-issuer “deny layer” is needed: it would not cancel the explicit permissions. Having two authorizations also does not create automatic failover; the ACME workflow needs accounts, validation and a deliberate provider-selection policy.
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issue "sectigo.com"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "sectigo.com"
example.com. 3600 IN CAA 0 iodef "mailto:cert-notify@example.com"
If a hostname is a CNAME to a vendor, an ordinary CAA query follows the alias and may return the target’s CAA set. Once a nonempty set is found, it is selected without merging your apex permissions. CAA cannot coexist with CNAME at the same owner name. Coordinate the vendor’s supported TLS product and policy instead of attempting to add CAA beside the alias.
Let’s Encrypt and ZeroSSL Authorization Patterns
A different policy can allow Let’s Encrypt for normal names and ZeroSSL/Sectigo only for wildcards. The following replaces the earlier alternative; it is not an addition to it. Under this set, neither CA can issue one combined certificate for example.com and *.example.com, because each lacks authorization for one identifier. Use separate orders or authorize the selected CA for both scopes.
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "sectigo.com"
For a Let’s Encrypt-only policy restricted to your account and DNS-01, use the following separate alternative. Replace the sample account number 12345678 with the actual production account URI reported by your client. Both issue and issuewild are constrained. Remove competing unrestricted permissions when adopting this policy; appending these lines to an unrestricted set does not lock that set to your account.
example.com. 3600 IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678; validationmethods=dns-01"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678; validationmethods=dns-01"
ZeroSSL’s official “Invalid CAA Records” help page specifies sectigo.com, not zerossl.com, as its authorization identifier. Sectigo’s current CAA documentation states that additional restrictive parameters are not supported, so do not transfer the Let’s Encrypt account or method constraints to its permission. Let’s Encrypt’s CAA guidance and RFC 8659 explain the corresponding provider behavior and standard selection rules. A syntactically valid zone alone cannot prove a CA will enforce an unsupported constraint.
Pair the intended CAA policy with an explicitly configured ACME workflow. Select a primary provider, define which failures can trigger an alternative, and bound retries so DNS or account failures do not become repeated orders. The acme.sh redundant CA automation guide covers the client side. Confirm the installed client version, provider accounts and deployment path before relying on it during renewal.
Wildcard Rules and Empty Issuer Values
Omitting issuewild does not inherently block a wildcard order. If issuewild is absent, apply issue; if issuewild is present, evaluate those permissions instead. A mixed SAN order needs authorization for every name, not merely the wildcard. Also distinguish CAA permission from challenge support: Let’s Encrypt requires DNS-01 for wildcard issuance, while another product’s validation requirements must be checked separately.
To prohibit wildcard issuance while allowing normal names, an alternative relevant set can contain issue "letsencrypt.org" and issuewild ";", with no wildcard allow. To prohibit both kinds, use the standalone set below with no authorizing issue or issuewild entries. Adding these empty values after allows does not create a veto. This affects new issuance under the selected set, not certificates already issued or a different set selected for another name.
example.com. 3600 IN CAA 0 issue ";"
example.com. 3600 IN CAA 0 issuewild ";"
CAA does not accumulate policy across an alias chain and all ancestor domains. Each candidate name is queried using ordinary DNS alias processing; a nonempty CAA result stops the search. If the result is empty, remove the leftmost label of that original candidate and repeat. Do not automatically walk the alias target’s parent hierarchy as a separate source of policy. The exact algorithm matters when a vendor target has no CAA records.
IODEF Reporting and Its Limits
IODEF describes machine-readable incident reports. A mailto contact requests delivery as a MIME email attachment, normally with a brief explanatory message. An HTTPS contact refers to the web-service transport specified by RFC 6546. Whether a CA produces a report, and under which conditions, depends on its implementation and policy. Lack of a report does not establish that issuance succeeded or that no unexpected request occurred.
Choose contacts that your team can operate and whose protocol matches the CA’s reporting support. For HTTPS, deploy a compatible receiver instead of assuming an internal JSON webhook will work. Assign ownership for examining incoming reports and handling failures. Correlate reports with ACME logs and certificate inventory; Certificate Transparency monitoring is a separate observation channel and does not itself stop issuance or prove deployment.
example.com. 3600 IN CAA 0 iodef "mailto:cert-notify@example.com"
example.com. 3600 IN CAA 0 iodef "https://caa.example.com/report"
The two report contacts above are optional properties to include within the intended complete policy. A selected set containing only iodef has no normal issuance restriction; it does not inherit an ancestor’s issue entries after selection. Cloudflare’s CAA reference also explains that Universal SSL may add CAA authorizations automatically without showing all of them as user-created dashboard records. Inspect actual DNS answers and the chosen certificate product before assuming a strict account-only policy is effective.
Planning Multi-CA Renewal
A multi-CA plan needs the relevant permissions, active provider accounts, supported validation and a working deployment mechanism for each path. Check any EAB or product requirements and retain the account state needed for renewal. The client must deliberately prefer one provider and change only under defined conditions. CAA is authorization, not an instruction to switch providers, and a provider change cannot guarantee uninterrupted operation.
An alternative CA may help with a provider-specific outage or issuance limitation. It may not help with a shared DNS outage, an invalid CAA set or a challenge path both providers need. Operating additional accounts, keys, chains and quota controls has a cost. Choose redundancy where that cost fits the recovery requirement, and avoid authorizing providers that the organization has no reason or process to use.
Version the intended DNS policy alongside a record of the certificate workflows that depend on it, with suitable access control for changes. Test both necessary issuance paths before relying on failover, without deploying untrusted staging certificates. Verify key matching, SAN coverage and chain compatibility, then check fresh connections at the actual TLS endpoint. Obtaining a certificate file is not proof that an edge service has loaded it.
Schedule policy changes with time for both authoritative publication and cached answers to change. Previously cached positive answers can retain their old TTL; negative answers have separate SOA-based caching rules. Lowering a TTL now does not clear answers already held by resolvers. Allow recovery time before expiry and use the actual certificate lifetime or supported renewal guidance rather than assuming a fixed universal renewal interval.
Implementation and Verification
Choose the Relevant Record Set
An apex policy can cover descendants when no closer relevant CAA set is found. A nonempty descendant set replaces that inherited policy; it does not add to it. Even an iodef-only descendant set can therefore remove inherited issuance restrictions. Review every special hostname and alias, and coordinate external providers where CNAME prevents a same-owner CAA record. Audit the selected policy rather than just counting records in the dashboard.
Make Wildcard Policy Explicit
Decide whether wildcard permission should match normal names, differ by issuer, or be prohibited. If you add issuewild, it becomes the wildcard policy regardless of issue. A wildcard permission does not authorize the apex identifier in a combined order. For Let’s Encrypt DNS-01, maintain the correct challenge owner, restricted DNS credentials, propagation handling and cleanup that preserves other active TXT values. CAA does not create those challenge records.
Apply Account Constraints Consistently
Use the exact account URI and account environment that will request issuance. Account migration can require a CAA policy change; loss of the old account key does not make a new account match the old URI. If both issue and issuewild are present, constrain both as needed, and inspect every alternative authorization. The decimal critical flag 128 requires support for a property tag; it is not a universal mechanism to force support for any parameter.
Follow the CNAME and Parent Algorithm
For app.example.com pointing to a vendor target, first query CAA for app.example.com using ordinary alias resolution. If that yields a nonempty set, use it. If empty, the next candidate is example.com, not automatically the parent of the vendor target. Continue by removing one label from the current candidate until a set is found or before reaching the DNS root. Do not treat a DNS error such as SERVFAIL as an empty successful response.
Allow for Positive and Negative Caches
Inspect both authoritative and recursive answers during a transition. All authoritative servers should publish the intended data, while recursive resolvers can still have older responses. Negative cache timing may differ from the CAA record’s positive TTL. Prepare lower TTLs in advance where useful and wait out prior values; do not promise that one fixed delay makes every CA see the new policy. Investigate persistent failures instead of continuously retrying issuance.
Inspect DNS and Test the Issuance Path
Use dig to inspect the response status and answer section. Substitute your actual apex and requested hostname; these commands only read DNS. A single CAA query is not the complete RFC 8659 ancestor search, and a short answer alone can hide useful error context. Follow alias results and inspect the appropriate next candidate when the CAA result is empty.
dig +noall +answer +comments CAA example.com
# Query a particular hostname
dig +noall +answer +comments CAA app.example.com
After checking DNS, use a test environment where the chosen CA and client provide one. Do not assume every provider offers staging or that staging shares the production account URI, quotas or exact policy. Client logs may show the CA error without exposing all of its internal DNS queries. Production readiness still requires the real account and deployment checks; keep test certificates separate from the live TLS service.
Consult Let’s Encrypt’s CAA guidance for supported identifiers, parameters and errors, and RFC 8659 for record selection and property semantics. Record the tested hostname, timestamp, CA endpoint, account identifier and DNS result without including private keys or DNS API secrets. A zone parser checks record syntax; it does not replace validating the selected policy against the actual issuance workflow.
DNSSEC and CAA Integrity
DNSSEC and CAA solve different problems. A correctly validated DNSSEC chain protects the origin and integrity of DNS data; CAA expresses issuance authorization. CAA does not itself sign DNS answers, and DNSSEC does not select the allowed CA. Broken signatures or DS configuration can prevent reliable CAA evaluation and block issuance. Maintain both mechanisms deliberately, including during DNS-provider migrations, rather than assuming adding either makes renewal automatically reliable.
Maintain the Policy with the Renewal Workflow
A completed CAA change should have a documented issuer policy, matching ACME accounts and methods, verified DNS answers, and an observed certificate deployment. Include every SAN and actual TLS endpoint in the check. If issuance fails, distinguish authorization, DNS lookup, challenge validation, account and deployment errors before changing the policy. A narrowly diagnosed correction is easier to validate than broadly removing restrictions.
Keep only the authorizations required by the chosen workflow. Revisit them when CA support, accounts, domain routing or managed TLS products change. Use iodef as optional reporting alongside independent renewal and expiry monitoring. For key compromise, replacing a CAA record is insufficient: use a fresh key, replace affected certificates, arrange revocation and verify deployment. CAA neither invalidates the exposed key nor revokes the previous certificate.
The acme.sh redundant CA automation guide complements these DNS rules with a client workflow. Before adopting it, confirm the current provider requirements and test the primary and necessary alternative path. Preserve enough time before expiry for diagnosis and controlled recovery, and record which endpoint actually serves the replacement certificate. That evidence establishes whether the renewal plan works.
