Intermediate
Lesson 2 of 11 · ~8 min

CAA records: who can issue certificates

A small DNS change with a delayed, expensive failure mode. Never publish a CAA without checking what currently issues.

CAA records are uncommon enough that many techs go their first year without touching one, then meet them during a security audit or a Cloudflare onboarding. The reason CAA matters for helpdesk work is the failure mode: a wrong CAA causes cert renewals to fail silently a few weeks or months later, after the tech who made the change has forgotten about it. The site goes offline when the cert expires.

CAA is a record where small change, big delayed impact is the norm.

What CAA does

A CAA (Certification Authority Authorization) record at a domain tells certificate authorities whether they’re allowed to issue certificates for that domain. Before issuing, a CA queries CAA. If a CAA exists and doesn’t authorise the CA, the issuance fails.

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

The value has three components:

  • Flag (0 or 128). Mostly 0. 128 means “critical”: CAs that don’t understand a tag must refuse issuance.
  • Tag (issue, issuewild, or iodef). issue permits regular certs; issuewild permits wildcards; iodef is an email/URL the CA reports violations to.
  • Value. The CA’s identifier or the iodef URL.

The default and the failure mode

Adding CAA implicitly forbids every CA you don't list

If a domain has no CAA records, any CA can issue (the universal default).

When you add a CAA, you’re constraining issuance: only the named CAs can issue. Any CA not named is implicitly forbidden.

The failure pattern: a domain has been quietly issuing certs from a CA for years (Let’s Encrypt via the hosting provider, say). A security audit recommends adding CAA. The tech adds 0 issue "digicert.com" because the client recently bought a DigiCert wildcard. The Let’s Encrypt renewal three weeks later fails because Let’s Encrypt isn’t listed. The site keeps working until the existing cert expires, then it goes dark.

How to check what currently issues

Before publishing CAA, find out what’s currently issuing. Two paths:

  1. Look at the live certificate. Open the site in a browser; the cert’s issuer field names the CA. For multi-host setups (CDNs, load balancers), check each public endpoint.
  2. Query Certificate Transparency logs. Every cert issued for a domain is logged in public CT logs. Services like crt.sh let you search a domain and see every cert issued in the last few years, including from CAs you didn’t know were involved (sub-CAs, vendor-managed certs, hosting-provider auto-issuance).

CT search reveals surprises. A hosting provider’s certificate-management subsystem issues from a CA the client never knew was in their stack; a subdomain delegates somewhere that issues from a different CA. Before publishing CAA, account for all of them.

What this is NOT

  • “CAA controls which CA the client can buy from.” No. CAA controls which CA is technically permitted to issue. The client can buy from anyone; the issuance fails at the technical step if CAA doesn’t allow it.
  • “No CAA means any cert is automatically issued, so the domain is insecure.” No. Any CA can issue doesn’t mean any cert is automatic. Each CA still does its own validation (domain control, ownership). CAA is an additional gate, not the primary one.
  • “Adding CAA is always safer.” Adding the wrong CAA is actively dangerous because it silently breaks future renewals. Adding the right CAA is a small improvement. The risk cuts both ways.

Decision walkthrough

What CAA do you publish?
A client's security consultant emails: 'your domain example.com doesn't have CAA records. Best practice is to add CAA 0 issue digicert.com since that's the CA you bought your wildcard from.' You check the website's cert in the browser: DigiCert wildcard, as expected. CT logs (`crt.sh/?q=example.com`) show three issuers in the last two years: DigiCert (the wildcard, intentional), Let's Encrypt (issued weekly by the client's hosting platform's auto-SSL — the client didn't know), and Sectigo (one cert from a security scanner the client trialled and dropped).
Three current issuers: DigiCert, Let's Encrypt, Sectigo (trial, ended). What goes in CAA?

If you’re not sure what currently issues, don’t add CAA. The default (no CAA) is safe; an incomplete CAA is not. Monitor renewals for 60–90 days after publishing to catch any missed CA.

Next lesson →