What's holding up the rollout of persistent domain validation for ACME? | TurboLight Solutions<br>There is a new ACME validation method, dns-persist-01, being standardized at the IETF, and it has even been rolled out to Let’s Encrypt’s staging environment. However, an unresolved security concern is blocking progress on the standard and the roll-out in production for Let’s Encrypt.<br>dns-persist-01: DNS propagation delays begone!<br>While ACME has had a DNS-based validation method (dns-01) since the very beginning 1, it requires real-time updates to DNS for every validation attempt. This creates two issues:<br>The ACME client needs to have an API key to update the zone, or communicate with a third party service (such as acme-dns) to create the record. This means that credentials that can be used to update DNS zones are scattered across web servers.<br>DNS updates need to propagate and be widely visible on the Internet before the ACME server gives up on trying to validate the domain. The possibility of validation failures was only amplified when Multi-perspective issuance corroboration was made mandatory last year.<br>To resolve these issues, a new method named dns-persist-01 was proposed. Let’s Encrypt’s blog post covers the details of how the method works, so I won’t repeat them here. Suffice it to say that the new method avoids the two issues listed above as well as opens up the opportunity for the ACME server to automatically validate domains without the ACME server and client executing the challenge/response flow for every certificate request.<br>The original Let’s Encrypt plan<br>Let’s Encrypt announced their implementation in the blog post linked above in February. At that point, support already existed in Pebble (a “miniature” version of Let’s Encrypt’s production ACME server that is designed specifically for testing). Additionally, several implementers of ACME clients had integrated experimental support for dns-persist-01. With testing infrastructure in place and client support being prepared, it appeared that the published timeline in the February blog post calling for staging roll-out in late Q1 2026 and a production roll-out targeted for Q2 2026 would be met.<br>However, that schedule has since slipped. In early April, a discussion started on the IETF ACME working group’s mailing list concerning the relatively weak security guarantees of dns-persist-01 compared to the other ACME validation methods. The discussion spun out into a GitHub issue, where several participants in the ACME working group discussed changes to the specification to address the security issue. In a community thread on deployment status, a Let’s Encrypt engineer noted in May 2026 that the specification was still evolving and that shipping could land in Q3 if consensus on certain open issues at the IETF didn’t resolve quickly. By late June, the position had hardened into a blocker: another Let’s Encrypt engineer stated that Let’s Encrypt will not deploy dns-persist-01 until the open GitHub issue is resolved.<br>The big open issue: proxy ACME servers run by attackers<br>The problem is that the dns-persist-01 record, as originally specified, contains only information supplied by the ACME server. Specifically, the issuer-domain-name and the account URI are sourced from the CA operating the ACME server. Nothing in the record is independently supplied by the client and verified by the ACME server. The lack of client-supplied information in the dns-persist-01 record enables this attack:<br>The attacker stands up a malicious ACME server.<br>The attacker gets a victim to configure the malicious server’s directory URL in their ACME client. For example, this could be done through a typosquatted directory URL (e.g., https://acme-v02.api.letsencyrpt.org/) that closely resembles a real one.<br>When the victim registers an ACME account with the malicious server, the attacker simultaneously registers their own account at a “real” CA, and then hands the victim back that account’s URI verbatim in the response payload for the “register account” ACME request.<br>The victim publishes a dns-persist-01 record containing what they believe is their account URI. In reality, it authorizes the attacker’s account at the real CA. This enables the attacker to obtain certificates for the victim’s domain.<br>This sort of attack was anticipated when the original ACME specification, RFC 8555 was published. Preventing this sort of MitM (“Machine in the Middle”) attack is the motivation why all other ACME validation methods include some form of the ACME account’s public key to appear in the challenge response. The inclusion of the public key thwarts this sort of attack by having the ACME server compare the expected public key value for the account and the public key value presented in the challenge response. When the attacker tries to issue for...