CAA records: choose which CAs may issue certificates for your domain

What CAA is for

Browsers trust dozens of certificate authorities (CAs), and each of them can issue a valid certificate for your domain. A single CA that gets fooled is enough for a rogue certificate.

A CAA record (Certification Authority Authorization, RFC 8659) shrinks that list. It names the CAs allowed to issue for your domain. Since 8 September 2017 the CA/Browser Forum's Baseline Requirements have obliged every public CA to look it up before issuing. If the record names someone else, the CA turns the request down.

What CAA does not do

Browsers never look at CAA. RFC 8659 explicitly forbids using it when validating a certificate, so a certificate issued in breach of your record still works. Existing certificates are not affected either. A new record only takes effect at the next issuance or renewal.

To see what has actually been issued for your domain, search the Certificate Transparency logs, for example on crt.sh. The certificate itself is covered in the article on TLS.

Record format

A CAA record consists of flags, a tag and a value:

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

Tag	Meaning
issue	This CA may issue certificates. Several issue records add up.
issuewild	Applies to wildcard certificates (*.example.com) only and takes precedence over issue for them
iodef	Address (mailto: or https:) for reports of requests that violate the record

The flag is almost always 0. Setting it to 128 marks the record as critical, and a CA that does not understand the tag must then refuse to issue at all. A value of ";" with no CA name forbids issuance. Without an issuewild record, wildcards fall back to the issue records. A set with neither issue nor issuewild restricts nothing. Don't count on anyone sending reports to the iodef address.

Which level applies

The CA starts with the exact name in the request and climbs up the tree. For shop.example.com it queries shop.example.com, then example.com, then com. The first name with CAA records wins. A record at example.com therefore covers every subdomain without one of its own. Once shop publishes its own record, the parent's record no longer counts for shop.

If www is a CNAME pointing to your hosting provider, the CA sees the CAA records of that target. Where the target has none, the search carries on at example.com.

CA identifiers

Each CA decides which name it expects in the record:

CA	Value for issue
Let's Encrypt	letsencrypt.org
Sectigo	sectigo.com
DigiCert (including RapidSSL, GeoTrust, Thawte)	digicert.com
Google Trust Services	pki.goog
AWS Certificate Manager	amazon.com, amazontrust.com, awstrust.com or amazonaws.com
GlobalSign	globalsign.com
SSL.com	ssl.com

Let's Encrypt also supports the parameters from RFC 8657. accounturi ties the permission to one ACME account and validationmethods to particular validation methods such as dns-01. If you later move to a new server with a new account, renewals will fail until you update the record. With a CA that ignores these parameters, they restrict nothing.

Common mistakes

• The CDN's or hosting provider's CA is missing. Cloudflare obtains Universal SSL certificates from Let's Encrypt, Google Trust Services and SSL.com, and backup certificates from Sectigo. If Cloudflare runs your DNS, it adds these CAs itself as soon as you create a CAA record, though they don't show up in the dashboard.
• An issuewild ";" copied from a template while a wildcard certificate is in use somewhere. Nobody notices until the next renewal, which may be months away.
• The record sits at the wrong level. A forgotten record at www overrides the new one at the parent domain.
• The DNS provider cannot handle CAA. Some control panels simply don't offer the type. Worse are name servers that answer CAA queries with an error or not at all, because Let's Encrypt then refuses to issue even though no record exists.

Without DNSSEC, an attacker who forges DNS answers to a CA can make the CAA record disappear. If your zone is signed, the CA can spot the forgery, and the record becomes something you can rely on.

Adding the record

First check the Certificate Transparency logs to see which CAs have issued for your domain so far. Include the mail server and any subdomain a service provider runs for you. In a zone file the result might look like this:

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

Here Let's Encrypt and Google Trust Services may issue ordinary certificates, but only Let's Encrypt may issue wildcards.

Web-based DNS editors usually have three fields for flags, tag and value. Some expect quotation marks around the value, others add them for you. Run dig example.com CAA afterwards to see what the DNS really returns.

Checking CAA

Once you enter your address at ZwoWebCheck, the report tells you whether a CAA record applies to your host and whether it permits the CA behind your current certificate, along with the DNSSEC status of your zone. If no record exists and we recognise your CA, you also get a ready-made suggestion.