I’d set up a new domain name for use as a simple peer-to-peer video streaming service (more on that in a future update) but repeatedly ran into issues with Let’s Encrypt’s domain authorization tests. Here is how I locked myself out of minting my new domain a TLS certificate.
, I wrote about a then recently introduced method for preventing misissuance of TLS certificates called Certification Authority Authorization (CAA) records. CAA is a type of DNS record that let domain owners declare which certificate authorities (CA) can issue a certificate for their domain.
Certificates for this website are issued by Let’s Encrypt, the free certificate authority. I’ve used the following DNS records to prevent any other certificate authorities from issuing certificates for my domain:
ctrl.blog. IN CAA 0 issue "letsencrypt.org" ctrl.blog. IN CAA 0 iodef "mailto:security@ctrl.blog"
The first entry declares the unique domain name of the CA that can issue certificates for my domain.
The second entry declares an email address that certificate authorities may use to contact me to notify me about any attempts that may have been made to issue certificates from a non-allow-listed CA. This is intended both to help you debug and identify any issues with certificate issuance caused by your CAA records, and to give you a heads up if anyone is attempting to create forged certificates for your domains.
You may also notice that my domain, ctrl.blog, ends with a dot; making it an absolute domain, also known as a fully qualified domain name (FQDN). For most DNS records, you specify external domains as an absolute domains anchored in the DNS root servers (as denoted by a dot followed by nothing). Here’s a mail exchange (MX) record that tells other email servers to deliver emails addressed to this domain to FastMail:
ctrl.blog. 0 IN MX 20 smtp.fastmail.com.
CAA records don’t use absolute domains, however. The trailing dot denoting the DNS root server is implied. By now you’ve probably guessed at how I managed to block myself from obtaining any new certificates from Let’s Encrypt: I’d added the customary dot to the end of the domain name. There are a few interesting takeaways from this simple mistake.
The first takeaway being that CAA issue records apparently must be exact matches for certificate authorities to be willing to issue a certificate for that domain. While this is in fact the desired effect of using CAA records, I’d also expect a trailing dot not to cause any issues given the history of the trailing dot in DNS.
The second takeaway is that Let’s Encrypt haven’t implemented support for the CAA iodef records. In other words, Let’s Encrypt didn’t send me any email notifications about the issues even though the CAA records were the root cause behind my authentication issues with them.
I wrongly assumed my CAA records weren’t the cause of my failed authorization requests as I’d also assumed that I’d receive an email notification if that were the case. iodef support is an optional feature of RFC 6844, and not mandatory as I thought it was. I did consider that my CAA records might be the issue, but I dismissed it as I believed I’d receive email notifications if that was indeed the root cause.
Lessons learned: double-check the configuration of an explicit blocking mechanism when you find yourself blocked by some unknown factor.
Thanks to BunnyCDN and Let’s Debug for helping me troubleshoot this issue.