Certificate Authority Authorisation (CAA) records let you specify which Certificate Authorities (CA) are allowed to issue SSL certificates for your domain. The record can help make the SSL certificate for your domain more trustworthy.
SSL certificates, like much of the internet, depend on trust. When you buy something online you trust that the website is genuine and not a fake website that is trying to steal your credit card details. Similarly, when you buy an SSL certificate for your domain you trust that the CA is trustworthy. In reality, the internet is a messy place. There are hundreds of certificate authorities, and not all of them are trustworthy. For instance, would you trust a CA run by an authoritarian government? Probably not.
CAs can also be sloppy. The most famous example is Symantec. In 2017, browser vendors decided SSL certificates issued by the authority – at the time one of the largest in the business – could no longer be trusted because of a long list with issues.
And certificate authorities can also be compromised. An example is DigiNotar, a Dutch root CA that suffered a security breach in 2011. The CA had issued malicious SSL certificates for, among many others, the domain google.com. The attacker used the SSL certificate to target Iranian Gmail users. Users wouldn’t see anything wrong with the fake Gmail website, and the attack only came to light because the Google Chrome browser has an extra check for domains owned by Google. There is an excellent post mortem of the compromise on slate.com. And if you want to learn more about root certificates and the chain of trust, we got an article about root and intermediate certificates that explains how it all works.
For most website owners these type of attacks are unlikely, but they do happen. CAA records can help prevent an attacker issues an SSL certificate for your domain, as the record only allows specific providers to issue a certificate. If your CAA record specifies that only Let’s Encrypt can issue SSL certificates for your domain then it doesn’t matter if ExampleCA has been compromised. They won’t be able to issue an ExampleCA SSL certificate for your domain, as they are not Let’s Encrypt.
CAA records have a flag, tag and value. In the below example the flag is “0”, the tag is “issue” and the value is “letsencrypt.org”:
example.com. CAA 0 issue "letsencrypt.org"
The last part is the easiest to understand. Each CA has its own CAA value. If you have a Let’s Encrypt SSL certificate then you can add “letsencrypt.org”. For other CAs you may need to do an online search (it is typically the providers domain name).
The flag can be an integer between 0 and 255, though currently only 0 and 128 are used:
The three most command tags are issue, issuewild and iodef:
You can have multiple CAA records. For instance, it is fine to create a CAA record for more than one CA. Similarly, if you want to be notified of CAA check failures then you can add a CAA record with the iodef flag. So, it is perfectly fine to have records like these:
example.com. CAA 1 issue "digicert.com" dev.example.com. CAA 1 issue "letsencrypt.org" example.com. CAA 0 iodef "mailto:firstname.lastname@example.org"
You can easily add one or more CAA records via cPanel’s Zone Editor – the record type is one of the options in the Add Record drop-down menu.
Image: adding a CAA record via cPanel’s Zone Editor.
The record itself includes the flag, tag and value fields described above. Here, I am adding a CAA record for letsencrypt.org.
Image: the flag, tag and value fields.
And, as mentioned, you can add multiple CAA records. For instance, here I got a second record using the iodef tag. Any CAA check failures will be reported to the specified email address.
Image: my two CAA records. The second record uses the iodef tag.
Finally, it is always a good idea to double-check the records. Here, I check the records using dig:
$ dig @ns5.catalyst2.net example.com CAA +short 0 issue "letsencrypt.org" 0 iodef "mailto:email@example.com"