Managing certificate issuers for your domain using CAA

Ever since I started my blog, I’ve been using HTTPS to serve its content using encrypted connections. At first I used TLS certificates issued by Namecheap but when Let’s Encrypt entered the arena it didn’t take long for me to switch. More than the pricing aspect, it was just so much easier to manage the configuration of my webserver. Every once in a while I use ssllabs.com to get a rough feeling for the quality of my TLS setup. When I ran the check last week, I saw something I didn’t notice before. Part of the result was a line in orange that said:

DNS CAA: No (more info)

I’m not a sysadmin and I’m no expert with regards to TLS/SSL so I was curious: What is CAA and why is it useful?

TLS in a nutshell

As I said above, initially I was using Namecheap to get a certificate and I switched to Let’s Encrypt later. Both Namecheap and Let’s Encrypt are examples for certificate authorities (CA). Many of them exist and your browser knows about them – either directly (root certificates) or indirectly through a chain. Once a domain’s certificate is signed by a CA, your browser knows that the certificate can be trusted. It will then use the public key associated with your certificate to encrypt the connection with the webserver serving the domain. In order to get a certificate for your domain you have to proof the ownership with the issueing CA.
Each certificate authority can issue certificates for all existing domains. This means that as soon as one CA is compromised, every domain is in danger of having a certificate issued. There’s a funny issue on the Mozilla bugtracker where someone highlights this problem by requesting to add a certificate to the Mozilla trusted CAs (Honest Ahmed). But there have also been real problems with CAs issuing certificates for domains without properly validating ownership (Google to distrust Symantec).

Certification Authority Authorization (CAA)

Certification Authority Authorization(CAA) is implemented as a new type of DNS resource record. It provides a way to communicate to a certificate authority if it is authorized to issue a certificate for a given domain. The record looks like this:

example.com. IN CAA 0 issue "letsencrypt.org"

example.com. IN CAA 0 issue "letsencrypt.org"

Since September 2017 CAs are required to check for CAA DNS records, the standard itself is available since 2013. If you configure CAA for your domain, you’re making sure that a certificate authority doesn’t issue a certificate for your domain in case it is compromised by a bug – as long as CAA itself is properly implemented, that is. It will not help against a malicious CA. For the latter, it’s necessary to think about adopting HTTP public key pinning (HPKP). In contrast to enabling CAA, deploying HPKP is riskier as it actively prohibits HTTPS connections for unknown public keys. You’ll need to be careful managing your own certificates. But that’s a different topic…

Enabling CAA

In order to activate CAA for your domain, the DNS server software that is used for your domain needs to support it. Here’s a list of DNS software and providers that you can check. In order to generate the correct DNS entry, you can have a look at this page – it will generate the appropriate CAA record for your page.
My domain hoster provides a custom DNS configuration interface that doesn’t support configuring CAA, yet. Manual configuration through the customer support was possible, however.

One more thing: As with any DNS change, enabling CAA for your domain will take some time to propagate. Even after some waiting time, I couldn’t see the new CAA resource record when querying my domain. It turns out, that not all tools fully support CAA, yet. If you use dig to query a domain server, you need to explicitly query the resource record type257:

dig example.com type257

Conclusion

Enabling CAA will prevent non-authorized certificate authorities to create certificates for your domain and help prevent men-in-the-middle attacks on your users. As it’s painless and quick to set up I don’t see a reason not to enable it. I hope that in the future it will become even easier with more hosters providing a way to configure it through their DNS tools.