CAA

What CAA is

CAA (Certificate Authority Authorization) is a DNS resource record type, defined originally in RFC 6844 and refreshed in RFC 8659. A CAA record lives in the authoritative DNS zone for a domain and names the CAs that are allowed to issue certificates for that domain.

Every publicly trusted CA is required by the CA/Browser Forum's Baseline Requirements to check CAA before issuing a certificate. If the CAA policy for the target domain prohibits issuance by that CA, the CA must refuse to issue.

The record format

text
1example.com.    CAA   0 issue "letsencrypt.org"
2example.com.    CAA   0 issue "digicert.com"
3example.com.    CAA   0 issuewild "letsencrypt.org"
4example.com.    CAA   0 iodef "mailto:[email protected]"

Breakdown:

• 0 is the flags byte. 0 = advisory/standard; 128 = critical (CAs must refuse if they don't understand the tag).
• issue is the tag. Other valid tags: issuewild (restricts wildcard issuance specifically), iodef (contact for incident reports).
• "letsencrypt.org" is the property value — the name of the authorised CA, matched case-insensitively against the CA's declared CAA identity. Each CA publishes its CAA identity in its CPS.

What CAA does well

• Reduces unauthorised issuance. If an attacker compromises some validation path for a specific CA, the CAA record prevents that CA from issuing for your domain. Without CAA, any CA on the WebPKI can issue for any domain.
• DNS-native. No new protocol, no new infrastructure — just a TXT-shaped record in the zone.
• Globally cheap. CAs check CAA before every issuance; operators update records on terms of their DNS change cadence.

What CAA does not do

• Does not stop a compromised CA from issuing. CAs are required to honour CAA, but a compromised or non-compliant CA can simply ignore it. CAA is a policy fence, not a cryptographic control. See the eMudhra incident for an example where CAA was effectively irrelevant — the compromised intermediates issued whatever they wanted until browser root programs blocked them.
• Does not apply to private PKI. CAA is a WebPKI mechanism. Private CAs issuing to internal workloads don't check CAA (though they may use similar policy constructs internally).
• Does not retroactively invalidate certificates. Changing a CAA record doesn't revoke previously-issued certificates. It only affects new issuance.

Common operational mistakes

No CAA record at all

By far the most common state. Any CA can issue for the domain. Fix: add CAA records to every zone.

CAA set but doesn't include the CA you actually use

The second most common state. Teams set CAA to letsencrypt.org and then purchase an EV cert from Sectigo — which refuses to issue because the CAA policy excludes it. Fix: enumerate every CA you actually use (public + private cross-signed) and list them all.

CAA set on the apex but not on subdomains

CAA is inherited by default — a record on example.com applies to api.example.com. But if you explicitly set a CAA record on api.example.com, that record overrides the apex. Fix: audit per-subdomain CAA where you've set them explicitly.

No iodef contact

When a CA receives a request to issue for your domain that violates your CAA policy, the iodef contact gets notified. Without it, violations are silent.

MPIC and CAA

Multi-Perspective Issuance Corroboration (MPIC) is a related CA/B Forum policy that requires CAs to validate domain control from multiple network perspectives. CAA checking is also now expected to happen from multiple perspectives, to defend against DNS hijack attacks that would spoof a CAA record from a single network vantage point.

When to update CAA

• Before adding a new CA to your issuance mix
• When retiring a CA (remove the entry)
• When changing the organisation-wide security policy around issuance
• Quarterly review as part of a certificate-governance cadence

Related reading

• RFC 8659 — DNS Certification Authority Authorization
• CA/Browser Forum Baseline Requirements §3.2.2.8