The structural problem with the WebPKI has been the same for two decades: any CA your browser trusts can issue a certificate for any domain. There's no per-domain restriction baked into the trust model. If a CA is compromised, or if an employee at a CA is socially engineered, or if a CA's validation process has a bug, the resulting fraudulent certificate is technically valid and will be accepted by every browser.
DigiNotar, 2011: a Dutch CA was breached. Fraudulent certificates were issued for Google, Yahoo, Mozilla, Tor, WordPress, and others. The fake Google certificate was used to perform man-in-the-middle attacks against Gmail users in Iran. DigiNotar went bankrupt within a month. Symantec, 2017: misissued more than 30,000 certificates across multiple incidents; Google removed Symantec's CA from Chrome's trust store. WoSign, Comodo, TrustWave — every couple of years, a CA does something that retroactively explains why "any of them can issue for you" is a fragile assumption.
What CAA Does
Certification Authority Authorization (RFC 8659) is a DNS resource record type. You publish a CAA record listing which CAs are allowed to issue certificates for your domain. Before issuing, every CA participating in the WebPKI is contractually required (by the CA/Browser Forum Baseline Requirements) to check the CAA record and refuse if their name isn't in it.
A simple CAA record looks like:
example.com. IN CAA 0 issue "letsencrypt.org"
Read as: only Let's Encrypt is authorized to issue certificates for example.com. Any other CA receiving a request for a cert on example.com is required to reject it.
The record has three fields:
- Flags — typically 0; the value 128 (critical) tells CAs that don't understand the tag to refuse issuance rather than ignore it.
- Tag —
issue,issuewild, oriodef. - Value — the CA domain name, or in the case of
iodef, a reporting URL or mailto.
The Tag Set
| Tag | Meaning |
|---|---|
issue |
Authorizes a CA to issue any certificate (single-name or wildcard). |
issuewild |
Authorizes a CA to issue wildcard certificates only. Overrides issue for wildcards if present. |
iodef |
Where CAs should report attempted but unauthorized issuances. URL or email. |
An empty value — 0 issue ";" — forbids all issuance for that domain. Useful for subdomains you never want certificates issued under, like internal-only zones.
A Realistic Deployment
A typical setup for an organization that uses Let's Encrypt for production and Google Trust Services as a backup might look like:
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "pki.goog"
example.com. CAA 0 issuewild ";"
example.com. CAA 0 iodef "mailto:security@example.com"
This says: Let's Encrypt and Google can issue regular certs; nobody can issue wildcards; report attempted unauthorized issuance to the security team.
CAA lookups follow the DNS tree upward. If www.example.com has no CAA record, the CA checks example.com, then the apex. A record at the apex covers everything below it unless overridden. This matters when you delegate subdomains to third parties whose CA preferences differ from yours.
What CAA Doesn't Stop
CAA is a real protection, but it's a compliance protection. It assumes the CA will check it. A few cases where that assumption fails:
- A genuinely compromised CA. If an attacker controls the CA's issuance infrastructure, they can bypass the CAA check. CAA is defensive against bugs and process failures, not against a thoroughly owned CA.
- Pre-CAA certificates. Certificates issued before you published the record are still valid until they expire. CAA only constrains new issuances.
- Non-WebPKI CAs. The CA/Browser Forum requirement binds CAs participating in the public WebPKI. Internal corporate CAs in your enterprise trust store don't have to honor CAA.
- DNS attacks. If an attacker can modify your DNS responses (cache poisoning, registrar compromise), they can serve a CAA record that authorizes them. DNSSEC mitigates this for clients that validate it; CAA itself does not require DNSSEC, though CAs are required to retry over TCP and use authenticated channels where possible.
The combination that actually closes the chain is CAA plus Certificate Transparency monitoring. CAA prevents most accidental and procedural misissuance; CT logs detect anything that gets issued anyway, so you know within hours rather than waiting for an out-of-band tip.
The Account-URI and Validation-Methods Extensions
Two extensions tighten CAA further:
- accounturi — restricts issuance to a specific account at the CA. Useful for ACME deployments where you want only your own automation, not someone else who happens to have a Let's Encrypt account, to issue for your domain.
- validationmethods — restricts which ACME validation methods the CA may accept. For example, allowing only DNS-01 validation prevents anyone who briefly controls your HTTP serving infrastructure from validating via HTTP-01.
Full record using both:
example.com. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345; validationmethods=dns-01"
Adoption of these extensions is still patchy — Let's Encrypt supports both as of 2023; some other CAs lag. The general pattern of CAA + restrictive issuance methods is the closest the public WebPKI gets to "only this account at this CA can issue, and only by proving DNS control."
Should You Deploy It?
For essentially any domain you operate: yes. Adding a CAA record is one DNS change, costs nothing, and reduces your exposure to compromised or misbehaving CAs from the entire WebPKI set to whoever you actually authorize. The deployment risk is essentially the same as any other DNS change, and the worst case if you misconfigure it (refusing all issuance) shows up the next time you try to renew a certificate, with plenty of warning.
If you've never set one up, an open-source tool like caatest.co.uk or internet.nl will check your current state and recommend the records to add. The whole process from "what's CAA" to "deployed for my domain" usually takes about fifteen minutes.
For related layers in the same defense stack, see our pieces on Certificate Transparency logs and certificate pinning.