If you had to guess how many Certificate Authorities are authorized to issue a TLS certificate for your domain right now, what would you say? One? Two? The actual answer, unless you've configured CAA records, is all of them.
There are hundreds of publicly trusted Certificate Authorities worldwide. Without CAA (Certification Authority Authorization) records in your DNS, any one of them can issue a certificate for your domain. An attacker who can demonstrate domain control, even temporarily through a DNS hijack, a BGP route leak, or a compromised email address, can obtain a valid, browser-trusted certificate for your domain from any CA on the planet.
CAA records are a DNS-based security control that restricts which CAs are allowed to issue certificates for your domain. They've been mandatory for CAs to check since September 2017 (per the CA/Browser Forum Ballot 187), meaning every CA is required to look up your CAA records before issuing a certificate and refuse to issue if they're not on the authorized list.
Despite this, the majority of domains still don't have CAA records. It's one of the simplest and most effective DNS security controls available, and it takes about two minutes to configure.
What CAA Records Do
A CAA record tells the world which Certificate Authorities are authorized to issue certificates for your domain. When a CA receives a certificate request for your domain, it's required to check your CAA records first. If the CA isn't listed, it must refuse the request.
Here's what a typical CAA configuration looks like:
yourcompany.com. 3600 IN CAA 0 issue "letsencrypt.org"
yourcompany.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
yourcompany.com. 3600 IN CAA 0 iodef "mailto:security@yourcompany.com"The Three Tag Types
issue — Authorizes a CA to issue standard (non-wildcard) certificates for the domain. Only CAs listed in issue records can issue certificates like yourcompany.com or www.yourcompany.com.
issuewild — Authorizes a CA to issue wildcard certificates (*.yourcompany.com). If no issuewild record exists, the issue records are used for wildcard authorization too. If you want to allow standard certificates from one CA and wildcard certificates from a different CA (or no wildcard certificates at all), use separate issue and issuewild records.
iodef — Specifies where to send violation reports when a CA rejects a certificate request based on your CAA policy. This can be a mailto: address or an HTTPS URL. Not all CAs support violation reporting, but configuring it means you'll know when someone tries to get a certificate from an unauthorized CA.
The Flag Field
The 0 in the record is the flag field. A value of 0 means the record is non-critical. A value of 128 means the record is critical — if the CA doesn't understand the tag type, it must refuse to issue. In practice, 0 is standard for the three defined tag types.
How CAs Check CAA
When a CA receives a certificate request for www.yourcompany.com, it walks up the DNS tree looking for CAA records:
- Check
www.yourcompany.comfor CAA records - If none found, check
yourcompany.com - If none found, check
com.(the TLD) - If no CAA records exist anywhere in the chain, the CA is authorized by default
This tree-walking behavior means you only need CAA records on the parent domain to cover all subdomains. But it also means that subdomains can override the parent's policy with their own CAA records if needed.
Why CAA Records Matter
Limiting the Blast Radius of DNS Compromise
If an attacker temporarily gains control of your DNS (through a compromised provider account, a registrar exploit, or a BGP hijack), one of the first things they can do is obtain a TLS certificate for your domain. With a valid certificate, they can run a convincing phishing site or man-in-the-middle proxy that browsers trust completely.
Without CAA records, the attacker can use any CA — including CAs with minimal validation requirements or automated issuance (like Let's Encrypt's HTTP-01 challenge, which only requires serving a file at a specific URL). CAA records restrict this: even if the attacker controls DNS, they can only obtain a certificate from your authorized CAs, which they may not have accounts with or may have stricter validation processes.
Preventing Unauthorized Internal Issuance
In larger organizations, different teams may independently request certificates from different CAs. This creates certificate sprawl and makes it harder to track what certificates exist for your domain. CAA records enforce a centralized policy: only the approved CA(s) can issue, regardless of which team makes the request.
Compliance and Audit
Some security frameworks and compliance standards reference CAA as a recommended or required control. Having CAA records demonstrates that your organization has taken a deliberate step to restrict certificate issuance, which auditors view favorably.
Protecting Against Misissued Certificates
Certificate misissuance, where a CA issues a certificate they shouldn't have, is a real problem. CAs have been caught issuing certificates without proper validation, sometimes due to software bugs, sometimes due to process failures. CAA records add a defense layer: even if a CA's validation process fails, the CAA check provides a separate gate that must pass before issuance.
Common CAA Configurations
Single CA (Most Common)
If you use one CA for all certificates (e.g., Let's Encrypt for automated renewals):
yourcompany.com. CAA 0 issue "letsencrypt.org"
yourcompany.com. CAA 0 issuewild "letsencrypt.org"
yourcompany.com. CAA 0 iodef "mailto:security@yourcompany.com"Multiple CAs
If you use Let's Encrypt for automated certificates and DigiCert for EV/OV certificates:
yourcompany.com. CAA 0 issue "letsencrypt.org"
yourcompany.com. CAA 0 issue "digicert.com"
yourcompany.com. CAA 0 issuewild "letsencrypt.org"
yourcompany.com. CAA 0 iodef "mailto:security@yourcompany.com"No Wildcard Certificates
If you want to allow standard certificates but block wildcard issuance entirely:
yourcompany.com. CAA 0 issue "letsencrypt.org"
yourcompany.com. CAA 0 issuewild ";"
yourcompany.com. CAA 0 iodef "mailto:security@yourcompany.com"The ";" value explicitly denies all CAs for that tag type.
Block All Issuance
For domains that should never have certificates issued (parked domains, internal domains with no web presence):
parked-domain.com. CAA 0 issue ";"
parked-domain.com. CAA 0 issuewild ";"Subdomain-Specific Override
If a specific subdomain needs a different CA than the parent domain:
yourcompany.com. CAA 0 issue "letsencrypt.org"
api.yourcompany.com. CAA 0 issue "digicert.com"The api subdomain overrides the parent policy and allows only DigiCert.
Common CA Identifier Values
Here are the CAA identifier strings for major Certificate Authorities:
-
Let's Encrypt:
letsencrypt.org -
DigiCert:
digicert.com -
Sectigo (formerly Comodo):
sectigo.com -
GlobalSign:
globalsign.com -
GoDaddy:
godaddy.com -
Amazon (ACM):
amazon.com -
Google Trust Services:
pki.goog -
Cloudflare:
digicert.com,letsencrypt.org, orpki.goog(Cloudflare uses multiple CAs; check their documentation for current issuers) -
ZeroSSL:
sectigo.com
If you're not sure which CA issues your current certificates, check your TLS certificate details in your browser (click the padlock icon) and look for the "Issued by" field.
Mistakes to Avoid
Forgetting Your CDN's CA
If you use a CDN like Cloudflare that provisions certificates on your behalf, your CAA records must authorize the CA(s) that the CDN uses. If Cloudflare tries to issue a certificate for your domain using Google Trust Services but your CAA only allows letsencrypt.org, the issuance will fail and your site will show certificate errors.
Before adding CAA records, check what CA your CDN currently uses and include it.
Forgetting Wildcard Authorization
If you use wildcard certificates, you need an issuewild record. If you only have issue records, wildcard issuance falls back to the issue policy, which is fine. But if you explicitly set issuewild ";" (deny all wildcards) while relying on a wildcard certificate, your next renewal will fail.
Not Monitoring CAA Changes
CAA records are a security control. If an attacker can modify your CAA records (through DNS provider access), they can add their preferred CA and then issue a certificate. The CAA change is the first step of the attack — detecting it quickly is the difference between prevention and compromise.
Assuming CAA Protects Against All Certificate Attacks
CAA is a policy control, not a technical enforcement mechanism. It depends on CAs checking CAA records before issuance and refusing when unauthorized. A rogue or compromised CA could ignore CAA records. CAA is one layer of defense, not a complete solution. It works best in combination with Certificate Transparency (CT) log monitoring.
How to Check Your CAA Configuration
Use the DNS lookup tool at dnsassistant.com/tools to query your domain's CAA records. If no records are returned, your domain has no CA restrictions — any CA can issue certificates for it.
For a broader view of your DNS security posture including CAA, email authentication, and TLS configuration, run a Free Domain Risk Report.
How DNS Assistant Monitors CAA
DNS Assistant tracks CAA records across all your monitored domains and alerts when they change. This matters for two reasons:
Detecting unauthorized modifications: If an attacker modifies your CAA records to authorize a CA they control, DNS Assistant alerts you immediately. The CAA change is the precursor to an unauthorized certificate issuance — catching it early prevents the attacker from completing the attack.
Preventing accidental weakening: Well-intentioned changes can accidentally remove or broaden CAA restrictions. A developer adding a new service might modify the CAA record without understanding its security implications. DNS Assistant ensures your team knows about every change to your certificate issuance policy.
Combined with monitoring of A records (to detect DNS hijacking), NS records (to detect delegation changes), and DNSSEC validation (to detect chain-of-trust issues), CAA monitoring completes the certificate security picture.
Set It Up Today
CAA records take two minutes to configure and provide meaningful protection against unauthorized certificate issuance. Here's the process:
- Check your current certificates to identify which CA(s) you use
- Check if your CDN provisions certificates on your behalf and which CA it uses
- Add
issuerecords for each authorized CA - Add
issuewildrecords if you use wildcard certificates (or";"to block them) - Add an
iodefrecord with your security team's email for violation reports - Verify with the DNS lookup tool
- Set up monitoring so you know if anyone changes your CAA policy
For continuous CAA monitoring alongside full DNS record tracking, WHOIS monitoring, and email authentication checks, sign up at dnsassistant.com.
Top comments (0)