ACME CAA Extensions to Become Mandatory | Feisty Duck

Error: JavaScript appears to be disabled

This web site will not operate correctly without JavaScript. Apologies for the inconvenience.

Cryptography & Security Newsletter

137

ACME CAA Extensions to Become Mandatory

28 May 2026

Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news<br>surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest<br>developments in this space. Enjoyed every month by more than 50,000 subscribers.<br>Written by Ivan Ristić.

The CA/Browser Forum has voted to make ACME CAA extensions mandatory starting in March 2027. This<br>change is one of the last remaining pieces needed to support strong, cryptographically-validated<br>domain validation in Web PKI. In this article, we discuss why Web PKI doesn't provide enough<br>assurance for high-profile websites, and how DNSSEC, ACME, and CAA can be combined to achieve strong<br>cryptographic validation of certificate issuance.

This article was originally published on the Red Sift blog. It's part of my bigger work on High-Assurance Certificate Transparency Monitoring, which monitors our progress towards strong cryptographic domain<br>validation. We're nearly there!

Convergence of DNSSEC and Web PKI

Not everyone likes DNSSEC, but it provides important security functionality that we can't get<br>anywhere else. Companies that enable it on their domain names achieve integrity of DNS resolution.<br>Some people argue that Web PKI works just fine, and it does, but only for the common use case:<br>protecting websites that are not under serious threat. High-profile websites need better<br>security.

For a long time, proponents of DNSSEC argued that it could replace Web PKI. Their thinking was that<br>once you achieve integrity of DNS resolution, you get a security property you can build on to make<br>X.509 certificates work without CAs. This is true, but only in theory. In practice, DNSSEC has a<br>variety of design and operational issues that make wide adoption difficult. As a result, after many<br>years, support for it is nowhere near where it needs to be, but Web PKI and CAs are here to<br>stay.

Still, organizations that need robust public X.509 security have no option but to deploy DNSSEC for<br>its unique capabilities.

In 2025, the CA/Browser Forum, the body that governs certificate issuance, decided to incorporate<br>DNSSEC validation into the domain validation process. The requirement became mandatory in March<br>2026 and, for the first time, enabled strong cryptographic validation of certificate issuance.

Weaknesses at the Root of Web PKI

Web PKI is the most strictly managed public PKI, with elaborate rules and controls. It's an ecosystem<br>we've spent decades improving. However, at the core, it has two significant problems. They are<br>making the system easier to use, but we pay for that with relaxed security requirements.

First, there is no authentication of the certificate requester . Anyone in the world can<br>request a certificate for any domain name; if the validation process succeeds, the certificate<br>will be issued to the requester, even if the domain owner does not authorize them.

Second, when a certificate is requested, the CA performs domain validation over unsecured<br>BGP, DNS, and network traffic . Anyone who can interfere with any of these three can break<br>the domain validation.

If we add DNSSEC to this mix, that helps to secure the DNS, but the remaining two aspects (BPG and<br>plaintext network traffic) remain insecure. To secure this setup, we need a way to ensure our domain<br>validation relies only on the secure parts.

Certification Authority Authorization

The weaknesses in Web PKI can be addressed by using a standard called Certification Authority<br>Authorization (CAA), defined in RFC<br>8659. CAA is designed to enable domain owners to publish their certificate-issuance policies.

The baseline version of CAA has been mandatory since September 2017, but it's insufficient for our<br>needs. There is another document (RFC 8657)<br>that bridges the ACME protocol for automated certificate issuance and CAA, adding support for<br>fine-grained permissions.

With ACME CAA extensions, we can solve both problems we outlined earlier, with the help of a single<br>CAA resource record in our DNS that looks something like this:

example.com. CAA 0 issue "letsencrypt.org;<br>accounturi=https://acme-v02.api.<br>letsencrypt.org/acme/acct/1726001367;<br>validationmethods=dns-01"

What Does This Do?

On the left, we see the domain name for which we want to control certificate issuance, in this case,<br>example.com. On the right, we have three controls:

The first is the identity of a CA that's allowed to issue certificates for the domain name, in<br>this case, letsencrypt.org.

The second control is the accounturi instruction, which locks down issuance only to<br>the named ACME account. Because ACME always uses encryption and strong cryptographic<br>authentication, this section...