CAA Records Explained: Control Which CAs Can Issue Your Certificates

One month from today, on September 8th, a new rule takes effect across the certificate industry: every publicly trusted certificate authority must check your domain's CAA records before issuing a certificate for it, and must refuse if the records don't permit them. The requirement comes from Ballot 187 of the CA/Browser Forum, the body whose Baseline Requirements every publicly trusted CA has to follow, passed earlier this year.

That turns CAA from an obscure, voluntarily honored DNS record into something enforceable. It's one of the cheapest security wins available for a domain you care about: a few DNS records and ten minutes of work. It's also easy to get subtly wrong if a service issues certificates on your behalf and you haven't thought of it that way.

What a CAA record is

CAA (Certification Authority Authorization, defined in RFC 6844 in 2013) is a DNS record type that answers one question: which certificate authorities are allowed to issue certificates for this domain?

Today, any of the dozens of publicly trusted CAs can issue a certificate for your domain, provided someone passes that CA's validation checks. Your relationship with your chosen CA doesn't restrict the others. That's a wide attack surface: a validation weakness at any CA, including one you've never heard of, can be used against your domain.

A CAA record narrows that surface to the CAs you actually use. It's an allowlist published in DNS, and from September 8th checking it becomes a hard requirement of issuance.

The syntax: issue, issuewild, iodef

A CAA record has three parts: a flags byte, a tag and a value. In practice you'll use three tags. A realistic zone looks like this:

example.com.    IN CAA 0 issue "letsencrypt.org"
example.com.    IN CAA 0 issue "digicert.com"
example.com.    IN CAA 0 issuewild ";"
example.com.    IN CAA 0 iodef "mailto:security@example.com"

Line by line:

• issue names a CA permitted to issue certificates for this domain. Multiple issue records mean "any of these". The value is the CA's designated domain string; check your CA's documentation for the exact one, since it isn't always guessable.
• issuewild controls wildcard certificates separately. The special value ";" means nobody, so the example above allows normal certificates from two CAs but forbids wildcards. If you omit issuewild, the issue records govern wildcards too.
• iodef gives CAs a place to report violations, as a mailto: or https: URL. If someone requests a certificate your records forbid, a CA can tell you. It costs nothing, so set it.
• The leading 0 is the flags byte. 128 marks a record critical, meaning a CA that doesn't understand the tag must refuse to issue. For the standard tags above, 0 is what you want.

CAA lookups also climb the tree. When a CA checks shop.example.com, it looks for CAA records there first, and if there are none it walks up to example.com. Records at your apex therefore cover every subdomain that doesn't override them.

What CAA protects against, and what it doesn't

CAA is often oversold or undersold, so it's worth being precise:

• It protects against mis-issuance by CAs that follow the rules. An attacker who can trick some CA's validation process, but doesn't control your DNS, now hits a wall: the CA must check CAA and refuse. That's most of the realistic mis-issuance risk.
• It doesn't stop a compromised or rogue CA. A CA willing to ignore the rules will ignore your DNS records too, though it will be violating an auditable requirement, which is how CAs end up distrusted.
• It doesn't affect existing certificates. CAA is checked at issuance only. Adding records today doesn't invalidate anything already issued.
• Browsers don't check it. CAA is between you and the CAs, enforced at issuance. Your visitors' browsers aren't involved.
• It's only as strong as your DNS. An attacker who controls your DNS can change your CAA records before requesting a certificate. CAA raises the bar; it doesn't replace securing your DNS provider account (DNSSEC, if you're ready for it, hardens this further).

Rolling it out without breaking issuance

The one real risk of CAA is self-inflicted: publish records that leave out a legitimate issuer, and a future renewal fails. Order matters:

1. Inventory who issues for you. Your main CA is easy. The subtle ones are services that get certificates on your behalf: CDNs that terminate TLS for your domain, load balancers with managed certificates, your host's one-click SSL. Each of those has a CA behind it, and that CA needs to be in your issue list.
2. Check that your DNS provider supports the record type. CAA is new enough that some providers can't publish it yet. If yours can't, you're no worse off than today: no CAA record means any CA may issue, as before. Nothing changes on September 8th for domains without records.
3. Publish, then verify from outside:

dig CAA example.com +short

4. Add iodef so attempted violations reach a mailbox someone reads.
5. Watch your next renewal. The first renewal after publishing CAA is when a forgotten issuer shows up. Better to catch it with weeks of certificate lifetime left than with hours.

Ten minutes now, or a confusing outage later

CAA has almost no downside: it's free, invisible to visitors and, from next month, enforced industry-wide. The failure mode is forgetting about it: publishing records, switching CDN or CA two years later, and wondering why renewal fails.

That's what monitoring is for. CompleteStatus watches your SSL certificates from outside and alerts you well before expiry, so a renewal that failed against your CAA policy shows up as an email weeks ahead rather than a browser warning your customers find first. It's the same attention to shared infrastructure we argued for after Cloudbleed, applied to your certificates. Create a free account, add your domains, and then spend the ten minutes publishing your CAA records before September 8th.