CAA Record Errors: Why Certificate Issuance Fails and What to Check

When requesting or renewing an SSL/TLS certificate through Let's Encrypt, DigiCert, Sectigo, or AWS Certificate Manager (ACM), certificate issuance can suddenly abort with an error like CAA record prevents issuance or DNS error checking CAA records. Standardized under RFC 8659 (which superseded RFC 6844), Certification Authority Authorization (CAA) records provide cryptographic domain owners with authoritative control over which certificate authorities are permitted to issue certificates for their hostnames.

The mandatory CAA validation rule for public CAs

Since September 8, 2017, the CA/Browser Forum has mandated that every publicly trusted Certificate Authority MUST check CAA records in DNS before issuing any TLS certificate. If your domain publishes a CAA record that permits DigiCert (issue "digicert.com"), and an automated Let's Encrypt Certbot script attempts to renew a certificate, Let's Encrypt must immediately abort issuance by law.

Crucially, a CAA failure does not only happen when an unauthorized CA is blocked. A DNS lookup failure during CAA evaluation is also treated as a fatal error. If the CA's validation servers receive a SERVFAIL or timeout when querying your domain's CAA records (often caused by broken DNSSEC signatures or misconfigured firewalls blocking DNS type 257), the CA must refuse to issue the certificate to prevent unauthorized issuance during network manipulation.

Understanding CAA record tags: issue, issuewild, and iodef

A CAA record consists of three elements: a flag byte, a property tag, and a property value. Here are the three standardized tags you need to understand:

• issue: Authorizes a specific Certificate Authority to issue single-domain, multi-domain, and wildcard certificates for the host, unless an issuewild tag is explicitly defined.
• issuewild: Specifically controls wildcard certificate issuance (e.g., *.example.com). If an issuewild tag is present, it strictly overrides any issue tags for wildcard requests. Setting issuewild ";" prohibits all wildcard issuance.
• iodef: (Incident Object Description Exchange Format) Specifies a contact URL or mailto address where CAs should send automated violation reports if an unauthorized party attempts to request a certificate for your domain.

; Authorize Let's Encrypt and DigiCert for standard certificates
example.com.    IN    CAA    0 issue "letsencrypt.org"
example.com.    IN    CAA    0 issue "digicert.com"

; Restrict wildcard certificates exclusively to DigiCert
example.com.    IN    CAA    0 issuewild "digicert.com"

; Receive automated security reports on unauthorized attempts
example.com.    IN    CAA    0 iodef "mailto:security-alerts@example.com"

The CAA tree-climbing algorithm: How CAs search parent zones

One of the most confusing aspects of CAA troubleshooting is the tree-climbing algorithm mandated by RFC 8659. When a CA validates a certificate for a subdomain (e.g., api.staging.example.com), it performs lookups in the following hierarchical order until it finds a CAA record set:

1. 1. Query CAA for api.staging.example.com. If records exist, evaluation stops and these records are enforced.
2. 2. If no CAA record exists at api.staging.example.com, query parent: staging.example.com.
3. 3. If no CAA record exists, query: example.com.
4. 4. If no CAA record exists at the zone apex, check if any CNAME alias was traversed and climb the canonical target's tree.
5. 5. If no CAA records exist at any level up to the public suffix (TLD), the CA assumes no restrictions exist and issuance proceeds.

This means that if you add a restrictive CAA record at your root domain (example.com), it automatically cascades down to every single subdomain (blog.example.com, app.example.com, cdn.example.com) unless that subdomain publishes its own overriding CAA record.

Step-by-step troubleshooting checklist for CAA errors

1. Check the CA identifier: Verify that the issuer string matches the CA's official registered identifier. For Let's Encrypt it is letsencrypt.org, for Amazon ACM it is amazon.com, for DigiCert it is digicert.com, and for Sectigo it is sectigo.com.
2. Inspect wildcard rules: If requesting a wildcard certificate (*.domain.com), inspect whether an issuewild ";" record is blocking you. If issuewild is missing, the standard issue records apply.
3. Test with dig: Query your CAA records using dig +trace example.com CAA to confirm authoritative servers return the records consistently without timeouts.
4. Audit DNSSEC validation: Run dig +sigchase example.com CAA or check your domain with a DNSSEC debugger. If an authoritative nameserver returns an invalid RRSIG or broken NSEC/NSEC3 proof of non-existence, recursive resolvers will return SERVFAIL, causing the CA to reject the certificate request.
5. Account for multi-SAN certificates: If your certificate covers 10 different domain names, the CA must evaluate CAA records independently for all 10 domains. A single restrictive CAA record on any one domain will cause the entire multi-domain certificate issuance to fail.

# Query the exact apex CAA record
dig example.com CAA +short

# Query the subdomain to test for overriding policies
dig api.example.com CAA +short

# Test with DNSSEC validation enabled (+dnssec)
dig example.com CAA +dnssec

Advanced RFC 8657 extensions: accounturi and validationmethods

Modern certificate automation under RFC 8657 allows domain owners to pin certificate issuance not just to an entire CA brand, but to a specific ACME account ID or validation challenge type. This prevents an attacker who controls another account at the same CA from requesting certificates for your domain.

; Pin issuance to a specific ACME account URL and require DNS-01 challenge
example.com.    IN    CAA    0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/98765432; validationmethods=dns-01"

; Critical flag (128) instructs compliant CAs to abort if they do not recognize the parameter
example.com.    IN    CAA    128 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/98765432"

The flag byte in CAA records defines strict compliance behavior. When set to 0 (non-critical), a CA can ignore unrecognized tags and evaluate the remainder of the record. When bit 0 is set (decimal 128, the 'critical' flag according to RFC 8659 Section 3), any CA that encounters an unknown tag or unparseable extension MUST refuse issuance entirely. Misconfiguring flag 128 with custom tags is a common reason why automated ACME agents fail with unexpected issuance errors.

How to safely fix or remove CAA restrictions

To permit a new certificate authority without revoking access for existing systems, simply append an additional issue record to your DNS zone. For example, to allow both Amazon Web Services and Let's Encrypt simultaneously:

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

After publishing changes in your DNS provider, allow the record's Time to Live (TTL) to expire before clicking 'Retry' in your certificate portal. Most CAs cache CAA lookup failures for up to 8 hours to prevent DNS server overload.

Verification and tools

Use the DNS lookup tool to query live CAA records across global nameservers. If your CA reports DNS resolution failures during validation, review the DNS timeout vs SERVFAIL guide to resolve underlying authoritative DNS and DNSSEC issues.