As of September 2017, every Certificate Authority is obligated to check the CAA DNS records for a domain it is about to issue a certificate to. This gives more control to the domain owner and can limit which Certificate Authorities are allowed to issue certificates.
This change had been announced a long time ago and is, as of today, in effect.
What are CAA records?
CAA stands for “Certificate Authority Authorization” and is a special type of DNS record that tells which Certificate Authorities can issue certificates for your domain and subdomains. It also has a method of sending alerts whenever a Certificate Authority receives a request for a new certificate that is forbidden as per your CAA records.
Here’s what the CAA records look like for our own domain, dnsspy.io.
$ dig +short +noshort dnsspy.io CAA dnsspy.io. 3600 IN CAA 0 issue "letsencrypt.org" dnsspy.io. 3600 IN CAA 0 iodef "mailto:[email protected]"
There are 3 different types of CAA records: issue
, issuewild
and iodef
. For more details on these records, the official CAA RFC is worth a read. If you’re looking for a more abbreviated explanation, this blogpost on CAA DNS records covers it pretty well.
Our CAA records tell the world that;
- We only accept certificates issued by Let’s Encrypt
- If another CA receives a request for our domain, it should report the violation via e-mail to our support address, [email protected].
This gives us more visibility whenever someone tries to get certificates for our domain(s).
Can I still get certificates even if I don’t have CAA records?
Yes.
A Certificate Authority has to query for CAA Records and if it finds them, it needs to honor what is mentioned in them. However, if there are no CAA records it’s the same as saying “any Certificate Authority can issue certificates for my domain”. Of course, that CA still needs to perform all the validation before it actually issues a certificate.
Who has CAA records today?
That’s actually a very short list, because there aren’t many DNS providers out there that support them. Many of the big players have their CAA records already;
$ dig +short +noshort google.com CAA google.com. 86400 IN CAA 0 issue "symantec.com" google.com. 86400 IN CAA 0 issue "pki.goog"
Google allows only certificates from Symantec and their own CA, https://pki.goog/.
$ dig +short +noshort services.mozilla.com CAA services.mozilla.com. 300 IN CAA 0 issue "digicert.com"
Mozilla has CAA records only on their subdomain for now, and only allows certificates from digicert.com.
Many only publish issue
records and no iodef
records, indicating they don’t want a notification anyone someone tries to get a certificate for their domain.
CAA vs. Certificate Transparency
Are the new CAA records even relevant with the upcoming of Certificate Transparency?
We absolutely believe it is. With CAA records, you limit who is allowed to issue certificates in the first place. With Certificate Transparency, where all issued certificates are published to public logs, you know which certificates got issued. There are great upcoming tools like Oh Dear! that allow you to monitor Certificate Transparency (+ HTTPS in general) if that’s what you’re looking for.
CAA records prevent unwanted CA’s from creating certificates, Certificate Transparency monitors which CA’s actually issued them.
How can I know my CAA records are configured OK?
We’re glad you asked.
We built a CAA record validator a while back, so you can test your DNS records. There are quite a few interesting cases about CAA records, when they apply and when they don’t (especially around DNSSEC, subdomains, CNAME’s etc.).
If you’re looking for assistance in building CAA records, the SSLMate CAA Record Generator is a great start. They also set up an interesting CAA test suite website that further explains when CAA applies and when it doesn’t.
Support for CAA records has been available in DNS Spy from the early days. If your domain has CAA records, we can monitor & alert on its changes. Make sure to sign up & monitor your DNS for unexpected changes!