Understanding CAA Check Failures and How to Resolve Them

Overview

Certification Authority Authorization (CAA) records allow domain owners to specify which Certificate Authorities (CAs) can issue TLS certificates for their domains. 

CAA mandates that a CA must review a domain’s CAA record(s) prior to certificate issuance. During the CAA check process, the CA must reach an authoritative domain nameserver. If no CAA records are present, the CA may proceed if other verification criteria are met. However, if CAA records exist, the CA can only issue a certificate if it is explicitly authorized in one of these records. 

This guide outlines common CAA check failures, explains why they happen, and provides actionable steps to resolve them. Ensuring proper CAA configuration helps secure your domain and protects against unauthorized certificate issuance.

What Are CAA Check Failures?

When a CAA check fails, it means there are issues with the CAA records or related DNS settings for your domain that prevents SSL.com from issuing a certificate. There are three main categories of CAA check failures:

• Denied: Failures related to explicit CAA records that restrict certificate issuance.
• DNSSEC: Issues arising from DNSSEC configurations and responses.
• Security: Failures due to potential security vulnerabilities, such as XSS.

Reasons for CAA Check Failures

Deny Tests

1. Empty Issue Tag: empty.basic.domainname.com – Fails if the CAA record is 0 issue “;”, indicating no CA is allowed.
2. Explicit Denial: Occurs if the CAA record explicitly disallows issuance for issue or issuewild. If a CAA record is present, it must include either issue “ssl.com” or issuewild “ssl.com”.
3. Case Sensitivity in Issue Tag: Uppercase (uppercase-deny.basic.domainname.com) or mixed case (mixedcase-deny.basic.domainname.com) issue tags result in failure.
4. Large Record Set: big.basic.domainname.com – Fails if there are an excessive number of CAA records (e.g., 1001).
5. Unknown Critical Properties: critical1.basic.domainname.com and critical2.basic.domainname.com – Fails if there are unrecognized properties marked as critical.
6. Tree Climbing: Fails when CAA records at parent (sub1.deny.basic.domainname.com) or grandparent (sub2.sub1.deny.basic.domainname.com) levels restrict issuance.
7. CNAME Chains: Fails if CAA restrictions exist at CNAME targets in a chain of CNAMEs, such as cname-deny.basic.domainname.com, cname-cname-deny.basic.domainname.com, and sub1.cname-deny.basic.domainname.com. Current behavior for CAA records with CNAMEs is that if you request a cert for  a.domain.com and it is a cname record for sub.sub.anotherdomain.com then the CAA check will also check up to the rootdomain of anotherdomain.com for a CAA record.
8. Deny over Permissive Parent: deny.permit.basic.domainname.com – Fails if the child is restricted even when the parent allows issuance.
9. IPv6-only Servers: ipv6only.domainname.com – Fails if the CAA record is only accessible over IPv6, and the CA cannot process it.

DNSSEC Failures

1. Expired DNSSEC Signatures: expired.domainname-dnssec.com – Fails if DNSSEC signatures are expired.
2. Missing DNSSEC Signatures: missing.domainname-dnssec.com – Fails if DNSSEC signatures are absent.
3. Nonresponsive DNS Server: blackhole.domainname-dnssec.com – Fails if a DNSSEC validation chain leads to a nonresponsive server.
4. SERVFAIL Response: servfail.domainname-dnssec.com – Fails if the DNS server responds with SERVFAIL.
5. REFUSED Response: refused.domainname-dnssec.com – Fails if the DNS server responds with REFUSED.

Security Checks

1. XSS Vulnerability: xss.domainname.com – Fails if the issue property contains HTML or JavaScript, testing against XSS vulnerabilities.

Special and Informational Tests

These tests are relevant in specific scenarios, such as automatic SAN (Subject Alternative Name) checks or certain DNS aliasing scenarios.

This suite ensures CAs are compliant with the Baseline Requirements, specifically in not issuing certificates where CAA restrictions apply.

How to Resolve CAA Check Failures

Use these steps and tools to help resolve CAA check failures:

1. Review CAA Records: Confirm that your CAA records explicitly allow the Certificate Authority as an issuer:  
   1. issue “ssl.com” for the domain 
   2. issuewild “ssl.com” for wildcard certificates
2. Use the dig (domain information groper) command: This is a versatile networking tool used to interact with DNS name servers. It conducts DNS queries and presents the responses from the servers it queries, making it an invaluable tool for diagnosing and resolving issues related to DNS.  for example: dig @1.1.1.1 domain.com CAA. it should show status:NOERROR
   1. Using the dig command for subdomains: To resolve CAA check failures for subdomains such as sub2.sub1.example.com using the dig command, ensure the following: The dig CAA command must return NXDOMAIN or NOERROR if no CAA record exists, and this should be verified for each level of the domain hierarchy—starting with the full domain name (FQDN) sub2.sub1.example.com, then moving up to sub1.example.com, and finally at the top-level domain example.com. The verification process will keep going up to the top-level domain until it finds a CAA record.
      
      Note: Current behavior for CAA records with CNAMEs is that if you request a cert for  a.domain.com and it is a cname record for sub.sub.anotherdomain.com then the CAA check will also check up to the rootdomain of anotherdomain.com for a CAA record.
3. Check DNSSEC Settings: Tools like DNSViz or Verisign DNSSEC Analyzer can help validate your DNSSEC setup.
4. Consult Your DNS Provider: For DNSSEC-related failures, your DNS provider can assist with resolving DNSSEC signatures or configuration issues.

Additional References 

For a hands-on look at these scenarios, visit https://caatestsuite.com/.