ACME CAA Extensions to Become Mandatory

Issuance Policy
1

I got this from Feisty Duck's Cryptography & Security Newsletter:

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:

 example.com. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1726001367; 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, 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 only to the named ACME account. Because ACME always uses encryption and strong cryptographic authentication, 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 accept them in the first place.

So I Decided to Put It to the Test

I have tested issuance with updated CAA records:

CAA 128 issue "letsencrypt.org; accounturi=...223017260; validationmethods=dns-01"
CAA 128 issuewild "letsencrypt.org; accounturi=...223017260; validationmethods=dns-01"

[Fri May 29 11:45:02 PDT 2026] Your cert is in: /tmp/acme/riptidetech.io/riptidetech.io/riptidetech.io.cer
[Fri May 29 11:45:02 PDT 2026] Your cert key is in: /tmp/acme/riptidetech.io/riptidetech.io/riptidetech.io.key
[Fri May 29 11:45:02 PDT 2026] The intermediate CA cert is in: /tmp/acme/riptidetech.io/riptidetech.io/ca.cer
[Fri May 29 11:45:02 PDT 2026] And the full-chain cert is in: /tmp/acme/riptidetech.io/riptidetech.io/fullchain.cer
[Fri May 29 11:45:02 PDT 2026] Your pre-generated key for future cert key changes is in: /tmp/acme/riptidetech.io/riptidetech.io/riptidetech.io.key.next
[Fri May 29 11:45:03 PDT 2026] Running reload cmd: /tmp/acme/riptidetech.io/reloadcmd.sh

IMPORT CERT riptidetech.io, /tmp/acme/riptidetech.io/riptidetech.io/riptidetech.io.key, /tmp/acme/riptidetech.io/riptidetech.io/riptidetech.io.cer
update cert![Fri May 29 11:45:03 PDT 2026] Reload successful

What I can not yet prove is whether Let's Encrypt will actually enforce accounturi and validationmethods, or merely ignore them and proceed because the base issue "letsencrypt.org" authorization matches. :face_with_monocle:

Guess we'll have to wait until March 2027.

As a heads up, Worked fine. No errors.

;@)

2

Let's Encrypt has implemented this and enabled it on production:

Wait until March 2027? Surely you could've tested it by putting different values in accountur/validationmethods and seeing if it triggers and error?

3

See relevant announcements:

4

@MikeMcQ sent me this link:

@Bruce5051 sent this one:

5

That's a fair point.

When I wrote that, I hadn't yet found Let's Encrypt's 2018 staging announcement or the 2022 production rollout announcement for ACME CAA Account and Method Binding.

My test only verified the "allowed" path: I published accounturi and validationmethods=dns-01, then successfully renewed a certificate using the matching ACME account and DNS-01 validation.

What I haven't personally tested is the "denied" path. For example:

  • Using a different ACME account than the one specified in accounturi.
  • Attempting HTTP-01 or TLS-ALPN-01 when only dns-01 is authorized.

Based on the documentation, Let's Encrypt already enforces these restrictions in production. I simply haven't performed a negative test case myself to observe the failure behavior firsthand.

6

Follow-up: I performed a negative test using a different Let's Encrypt ACME account and attempted issuance for banger.riptidetech.io while the parent domain's CAA policy restricted issuance to account 223017260. Let's Encrypt rejected the request with:

CAA record for riptidetech.io prevents issuance

This demonstrates that accounturi is actively enforced, not merely parsed or ignored.

7

@Rip Where's the whole "mandatory" part from the thread title exactly?

8

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

9

Thnx.

So the relevant CA/B Forum ballot seems to be Ballot SC098v2: Process RFC 8657 CAA Parameters | CA/Browser Forum (that Feisty Duck has a lot of words but for me the only interesting and relevant piece was the ballot :stuck_out_tongue:)

So in essence this is just a mandatory requirement for CAs. There is NO need for users to do anything if they wish to NOT use CAA or NOT use the CAA parameters.

That's all I wanted to know.

10

That is also important to know. Thanks.

11

Yup, it's just that CAs need to check for them.

12

I suppose I am being anal regarding RFC 8657 and it's implications.

The Feisty Duck Newsletter raised my awareness that "the vote" had just happened to require all CA's to enforce the RFC... When LE made it's announcement in 2022.

But my underlying interest is how normal "operators", or SA's (if you like) would respond, if at all, to the configuration possibilities. Would they just keep using a simple CAA or none at all? ... Or would they implement a CAA the fully restricts issuance to "Only this CA, using this account, with this validation method, while DNSSEC remains valid."

When "Webmasters" begin experimenting with RFC 8657, many of them are likely to discover issuance failures they never knew existed. The failures were already there; the stricter CAA policy simply exposed them.

OP's coming here for help, especially those who lack experience with DNS, etc.. will most likely brick their CAA records which will also break issuance. We will hear about it.

They will begin taxing our volunteers for tutorials and or "cut and paste" solutions.

I have to say my experiments and testing process has sold me on a complete lock down of all my CAA records. Every domain should its own account to prevent obvious correlation or connections in the DNS database. (A minimal CAA record doesn't reveal the account at all).

When I locked down yachats-gardens.com it became a canary on the internet.
With a short-lived certificate:
DNSSEC breaks → renewal fails.
DNS delegation breaks → renewal fails.
ACME account changes → renewal fails.
RFC 8657 mismatch → renewal fails.
DNS provider replication issues → renewal fails.

Most domains only test those paths every 60–90 days. The "short-lived" deployment tests them constantly.

dig @192.168.1.1 +dnssec CAA yachats-gardens.com

; <<>> DiG 9.18.39-0ubuntu0.24.04.5-Ubuntu <<>> @192.168.1.1 +dnssec CAA yachats-gardens.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61454
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1432
;; QUESTION SECTION:
;yachats-gardens.com.           IN      CAA

;; ANSWER SECTION:
yachats-gardens.com.    86400   IN      CAA     128 issuewild "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/3387148306; validationmethods=dns-01"
yachats-gardens.com.    86400   IN      CAA     128 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/3387148306; validationmethods=dns-01"
yachats-gardens.com.    86400   IN      RRSIG   CAA 13 2 86400 20260629203622 20260530203622 40279 yachats-gardens.com. cEJPCRYLTXJGWiXXtM6v7UdDEfvvaHxm03dXaGC/bDL856EZsRDL7Gko usmPiM4bwFlSQHCt0T+e+tKm2j/ycg==

;; Query time: 32 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Sun May 31 08:15:36 PDT 2026
;; MSG SIZE  rcvd: 427

Yachats Gardens is only a test site with little to no content. I created it specifically to test short-lived certificates.

13

My guess is yes. Most operators only care about doing the minimum work necessary to get a cert.

The requirement for all ACME CAs to support this is good because it means LE won't be the only choice of CA to use for the security conscious. But I doubt it's going to change actual usage much.