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
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"
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
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…
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 type
dig example.com type257
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.