> ## Content Index > Fetch the complete content index at: https://www.ctrl.blog/llms.txt > Use this file to discover other available public pages before exploring further. # How I blocked myself from obtaining a Let’s Encrypt TLS certificates - URL: https://www.ctrl.blog/entry/letsencrypt-caa-iodef/ - Published: 2018-10-27T14:03:00.000Z - Updated: 2026-08-23T22:13:17.000Z - Description: A misapplied DNS CAA record blocked Certbot from obtaining a Let’s Encrypt certificate for my domain name. Ouch. Have a fallback strategy! - Author: Daniel Aleksandersen - Tags: DNS, Security 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. Last year, I wrote about a then recently introduced [method for preventing misissuance of TLS certificates](https://www.ctrl.blog/entry/dns-caa/) 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*](https://bunny.net/?ref=ctrl.blog) *and* [*Let’s Debug*](https://letsdebug.net/?ref=ctrl.blog) *for helping me troubleshoot this issue.* #### Sources - [Certification Practice Statement](https://letsencrypt.org/documents/isrg-cps-v2.4/?ref=ctrl.blog), version 2.4, 2018-09-20, Let’s Encrypt, Internet Security Research Group - [Certificate Authority Authorization (CAA)](https://letsencrypt.org/docs/caa/?ref=ctrl.blog), 2017-07-27, Let’s Encrypt, Internet Security Research Group - [RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record](https://www.rfc-editor.org/rfc/rfc6844.html?ref=ctrl.blog), 2013-01, Internet Engineering Task Force - [RFC 1035: Domain Names – Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035.html?ref=ctrl.blog), 1987, P. Mockapetris, Information Sciences Institute, Network Working Group, Internet Engineering Task Force