CAA record issues

In February 2018 I wrote about CAA records. CA’s must check and respect these records when a customer orders a certificate. This is a good thing and it can be a good security measure to use to minimize the risk of rogue WebPKI certificates.

But it is also coming with some downsides. Working at a WebPKI reseller I daily see problems with CAA records. Some of them are on the client site and some of them are on the side of the CA. I will address a few here.

Lack of communication at CA’s

When a customer orders a certificate, and it gets blocked because of a CAA issue, this is not visible to the customer or the reseller. And most of the CA’s we work with aren’t very active to send a message about this issue which results in a very large delay.

And when you are contacting the CA about the CAA issue the do not always know what the problem is. If it is more than a wrong CA in a CAA record. When it comes to DNS issues and with DNSSEC problems in particular, they can’t really tell you where it fails most of the time. If you ask the CA for some details about the CAA lookup errors they only tell you the global method, again. There are CA’s that are providing some more information, but it still isn’t transparent.

There are also some differences between CA’s with checking the CAA records and handling doubtful cases. We did a test with a request of a certificate which was rejected at one CA, but accepted by an other CA.

At the end, it comes to clear communication en transparency.

Technical problems

Most of the time, the technical problems are on the client side. CAA check’s are less strict when you do not have DNSSEC enabled on your domains. But when you DO have DNSSEC enabled, you have to ensure that there are totally no errors in your DNS configuration.

Living and working in The Netherlands, where DNSSEC is pushed by SIDN (that is a really good thing by the way) there are many hosting providers that have enabled DNSSEC on their nameservers in a rush because of the financial benefits. SIDN gives registrars a discount on every DNSSEC signed domain. The “rush” to implement DNSSEC was not very good for the quality of the implementation in my opinion.

More then 50% of the .nl domains are signed.

With anomalies on the DNSSEC side and DNS administrators who are using exotic configurations the risk of an error is very high. Beside that, my experience with many system and network administrator is that they one have some basic knowledge of DNS. DNS is a bit the “forgotten” protocol that just is there to use.

In case of an error on a DNSSEC enabled domain, a CA may not issue a certificate for your domain. So you need to solve your DNS problems.

Regional problems?

This maybe is a bit of a hunch, but the CA’s are telling us that there are timeouts while doing the CAA lookup. When a CA has his systems in the US and it needs to resolve many CAA records fast, they need to work with a small timeout periods. When a Dutch hosting provider only have nameservers located in the Netherlands, an initial lookup can be just a bit to long. CA’s are giving the timeout message almost only on domains that are hosted at cheap hosting providers that do not always have a very good performance.


Seeing CAA records multiple times a week I’m wondering if there are usage statistic. But at the moment I only can find the stats on SSL Pulse.


Starting a project

With the CAA “problem” in mind I started a project on Github with a Go library where I test for CAA records and problems. My coding skills are not that good, but I try to make the best of it. And it also is in a concept stage at the moment. The library search for CAA records following the procedure that I explained in another blog post about CAA records.

I’ve also created a test website to test for CAA records. Check for this. It may be a bit buggy at the moment, but I will maintain this site.

Or you can take a look  at some results:


Searching the code of Let’s Encrypt, I came across some good reference about handling CAA records at Let’s Encrypt.

They also have some nice documentation.


Don’t trust all SSL / TLS certificates

Earlier I did a story about CSR checkers from CA’s and their resellers. This was a nice thing to do and an eye opener for some people. I went for the certificate checkers no! I generated my own CA and self-signed certificate and checked some websites with it.

In my FakeCA root certificate and the leaf certificate on it, I set some XSS information. A simple JavaScript alert. You easily can do this with OpenSSL for example. So I setup my test site and went testing. It wasn’t very difficult to find my first vulnerable website.


Read more