CA/Browser Forum: ACME CAA Extensions (RFC 8657) To Become Mandatory

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

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

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

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

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

Web PKI is the most strictly managed public PKI, with elaborate rules and controls. It's an ecosystem we've spent decades improving. However, at the core, it has two significant problems. They are 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 request a certificate for any domain name; if the validation process succeeds, the certificate 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 BGP, DNS, and network traffic. Anyone who can interfere with any of these three can break the domain validation.

If we add DNSSEC to this mix, that helps to secure the DNS, but the remaining two aspects (BPG and plaintext network traffic) remain insecure. We need to pull off a trick here: make the key decisions via DNSSEC and prevent the use of anything else.

The weaknesses in Web PKI can be addressed by using a standard called Certification Authority Authorization (CAA), defined in RFC 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 needs. There is another document (RFC 8657) that bridges the ACME protocol for automated certificate issuance and CAA, adding support for fine-grained permissions.

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

On the left, we see the domain name for which we want to control certificate issuance, in this case, 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 this case, letsencrypt.org.

The second control is the accounturi instruction, which locks down issuance to the named ACME account only. Because ACME always uses encryption and strong cryptographic authentication for ACME accounts, this section ensures that only authorized users can request certificates for this domain name.

The third control is the validationmethods instruction, which locks down issuance to use only one DNS-based domain validation method. When DNSSEC is enabled for a domain name, this section ensures that all domain validation operations are cryptographically secure. With this, we no longer care about other insecure methods; the CA won't ever accept them in the first place.

ACME CAA extensions have been around since 2019, and some CAs (e.g., Let's Encrypt, Google Trust Services, and others) already support them. So, in theory, you could have had stronger issuance controls since March 2026, when DNSSEC became mandatory for domain validation. In practice, until a feature is embedded in Baseline Requirements, there is always hesitance from CAs to commit fully. That's because every feature increases their workload and makes their job more complex. A failure to follow a written policy could lead to certificate issuance.

The Chrome team has been a long-time proponent of automation. Support for automation has been a central part of their Root Program Policy and, within it, requirements for ACME and ACME CAA extensions. In February 2026, the policy was changed to require support for ACME CAA for all CAs to support ACME.

In May 2026, CA/Browser Forum voted (in Ballot SC-098v2) to formally extend the support for CAA and make the ACME CAA extensions (RFC 8657) mandatory for all CAs, starting from March 2027.

You can use the ACME CAA extensions today if you work with CAs that support it. From next year, this feature will be widely supported, and you will have a choice of CAs to work with.