[Acme] RFC 8555 Last Call Draft Change Request

["Fabian V. Thobe" <[e-mail]>]

Dear RFC8555 Committee,

In cc: Alexis Hancock from EFF as some content involves also Certbot

*TL;DR *
A mechanism for authorization invalidation independent of the account key
appears necessary to ensure that domain ownership, and not a historical
authorization state, remains the ultimate source of trust.

*Background*
While working on improvements to the DNS Route53 plugin for Certbot (Certbot
PR #10729 <https://github.com/certbot/certbot/pull/10729>) to better meet
the security requirements of a European government entity, we identified a
potentially critical issue related to cached DNS-01 authorizations.
Specifically,
we observed during the PR related manual testing that certificate issuance
remained possible even after the certbot DNS credentials had been revoked
upon credential change. While we initially suspected a regression related
to previously used AWS credentials, further investigation revealed that the
root cause lies in RFC8555 mandated procedures handling of DNS
authorizations.

*Relevant Sections of RFC 8555*

*7.5.2. Deactivating an Authorization*
The server must verify that deactivation requests are signed by the account
key corresponding to the authorization.

*7.3.6. Account Deactivation*
Similarly, account deactivation requires a valid signature from the account
key.

*In both cases, the ability to revoke or deactivate authorizations is
strictly tied to possession of the account key.*

*Threat Analysis*

*High-Level Concern*

The current model creates a situation in which DNS-01 authorizations may
remain valid even when DNS credentials are revoked and the account key is
no longer accessible for a lack of re-authorization. If a legitimate owner
loses control of the account key, whether through compromise or operational
loss, there is no reliable mechanism to invalidate existing authorizations.

This creates a scenario where a malicious actor in possession of the
account key can continue issuing certificates without the knowledge or
consent of the legitimate domain owner.
Hereby the fact that Let's Encrypt clearly democratized encryption with
valid certificates is of high importance: systems in subpar environments or
environments subject to financial constraints regarding the procurement are
much more vulnerable than large enterprises or organizations. Especially in
the highly open source dependent political NGO sector I see significant
risks as the infrastructure owner might be a malicious actor allowing
various "men in the middle" scenarios.

A mechanism for authorization invalidation independent of the account key
appears necessary *to ensure that domain ownership, and not historical
authorization state, remains the ultimate source of trust*.

*Observed Risk Scenarios*

Several already observed risk scenarios emerged:

   - Lack of recoverable or uncompromised physical infrastructure after
   ransomware incidents makes the account keys irrecoverable;
   - Preference for full system rebuilds over restoration due to
   uncertainty about compromise timelines;
   - Missing or incomplete secret management practices;
   - Operational pressure leading to deviations from established recovery
   procedures

In these scenarios, loss of the ACME account key is a realistic and, maybe
even already a  recurring outcome.

*Expanded Risk Considerations*

Additional risks arise in environments where DNS infrastructure itself may
be compromised or controlled by malicious actors, including:

   - Man-in-the-middle attacks via compromised DNS resolution chains
   - Centralized or state-controlled infrastructure introducing systemic
   risks
   - Limited infrastructure diversity in certain regions

In such cases, cached authorizations amplify the attack surface by allowing
continued certificate issuance independent of current DNS control.

*Proposed Mitigations*

   1. *Lightweight Option: No-Cache Mechanism for DNS-01*
   Introduce a mechanism to explicitly disable authorization caching for
   DNS-01 challenges.
   (Reference: https://github.com/letsencrypt/boulder/issues/8870)
   2.

   *Break-Glass Recovery via Proof of Ownership*
   Introduce a recovery mechanism allowing domain owners to invalidate all
   existing authorizations (not the account) through a fresh
   proof-of-ownership challenge (e.g., DNS-based).

   This would:
   - Provide a recovery path in case of account key loss
      - Prioritize domain ownership verification over authorization
      persistence
      - Align with the core purpose of certificates: authentication, not
      just encryption


*Additional notes regarding awareness*

In discussions with peers across banking, healthcare, public sector, and
commercial environments (many operating under ISO 27001 or similar
frameworks), a lack of awareness regarding cached issues become apparent
(despite all of us using Let's Encrypt in private or professional
settings). Notably, none of the professionals consulted were aware that
DNS-01 authorizations are cached in a way that allows continued certificate
issuance after DNS credentials are revoked. There is also no clear
indication of this behavior in common tooling.

As a result all of us assumed that:

   - Revoking DNS credentials is widely assumed to fully mitigate risk
   - No standard procedures were required for responding to account key loss

Given that the tooling does not surface or warn about cached
authorizations, there might also be a problem regarding the value of
account keys. To be honest among 9 people, two of us even had a false risk
assessment in the ISO 27001 assessments, in one case fully audited by a
market leading entity. There might be a disconnect between what's
documented at Let's Encrypt and what effectively reaches the community as
literally there's no section neither about risks nor backup in the Certbot
documentation, the discovery of the non-ephemeral nature of authorizations
requires research, this is also reflected in the answers of AI agents (see
below), all major AIs apart from Claude responded wrongly. An issue and
offering to fix at least some oddities of certbot behaviour was not
favourably received (https://github.com/certbot/certbot/issues/10731)

As outlined above, the current ACME model prioritizes usability and
automation but does not fully address scenarios involving loss of account
keys. Given the widespread adoption of ACME and the increasing reliance on
short-lived certificates, this gap presents a meaningful security risk
undermining the efforts to shorten certificate lifetime for security as any
effort is undermined by the malicious can simply order a new certificate
with obtained account keys.

I would be happy to provide a more detailed proposal, including draft
specification language and an expanded threat analysis, if that would be
helpful.
Attachments

*Boulder Issue:*
Feature Request: Add an opt-in mechanism to disable DNS-01 authorization
reuse (--no-cache) for one Time DNS-01 Challenge Usage
 #8870
https://github.com/letsencrypt/boulder/issues/8870

*Certbot PR *
dns-route53: cerbot credentials.ini file support + fix duplicate TXT record
on apex/wildcard
#10729
https://github.com/certbot/certbot/pull/10729


*Certbot Issue *[Bug]: Invalid / Revoked credentials allow renewal due to
lack of revalidation of credentials and continued use of DNS-01 Auth
 #10731
https://github.com/certbot/certbot/issues/10731

*Example Observation*

A Certbot renewal executed with invalid DNS credentials still succeeded,
without indicating that cached authorizations were used:

(venv) zeus@mi-certbot-staging:~/certbot$ sudo venv/bin/certbot certonly \
--dns-cloudflare -d "*.domain.com" --dns-cloudflare-credentials \
~/cfinvalid --staging
[...]
Renewing an existing certificate for *.domain.com
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/domain.com/fullchain.pem


*Generative AI answers to the question:are dns challenges on certbot remade
on every renewal?*


   1. *Gemini*
   Unconditional Yes
   Yes, DNS challenges are remade on every single renewal. Every time
   Certbot attempts to renew a certificate, it initiates a fresh "order" with
   the Certificate Authority (such as Let's Encrypt). This order generates a
   brand-new, completely randomized token.

   2. *Co-Pilot *
   Unconditional Yes
   "Yes — DNS‑01 challenges are recreated every time Certbot renews your
   certificate, unless your DNS plugin/provider supports persistent TXT
   records (almost none do). Certbot must prove domain control again at each
   renewal, so it generates a new TXT value for _
   acme-challenge.yourdomain.com every time."

   3. *ChatGPT*
   Unconditional Yes
   "Yes. If you're using a DNS-01 challenge with Certbot, the challenge is
   generated fresh for every certificate issuance and every renewal."

   4. *Claude*
   Correct Answer
   Not automatically, no — it depends on the ACME server's authorization
   caching, not on certbot itself.


Fabian V. Thobe

[phone] / [e-mail]

Via Filippo Corridoni 68, 56125 Pisa