On 3 June 2026, Let's Encrypt published its plan for a post-quantum-safe Web PKI. The short version: your current certificates do not change today. The long version is a timeline, a new certificate design, and one server setting that actually matters this year.
This post is for people who run websites, terminate TLS, or maintain ACME clients — not for cryptographers. Source: A Post-Quantum Future for Let's Encrypt (Andrew Gabbitas, 3 June 2026).
Two different post-quantum problems
TLS does two jobs. Encryption hides the bytes. Authentication proves you reached the right server.
Encryption is the urgent one. An attacker who records traffic today can try to decrypt it later, once a cryptographically relevant quantum computer exists. That is the "harvest now, decrypt later" problem. The fix is already shipping: hybrid post-quantum key exchange, typically X25519MLKEM768 (classic X25519 plus NIST's ML-KEM). Major browsers and operating systems already support it. If your server does too, those connections are protected against future decryption of recorded sessions.
Authentication is slower to migrate. A quantum computer has to forge a signature in real time, not retroactively. Let's Encrypt still treats it as work that has to start now, because root programs, libraries, and ACME clients take years to move, and because governments have put dates on the wall: NSA CNSA 2.0 aims national-security systems at 2030–2035; NIST's draft guidance would deprecate RSA-2048 and P-256 after 2030 and disallow them after 2035; the EU roadmap targets high-risk systems by the end of 2030 and broad migration by 2035. Google and Cloudflare have both said they will migrate their own services by 2029.
Why not just put ML-DSA on every certificate?
The obvious next step is to replace RSA/ECDSA signatures with ML-DSA, the NIST-standardized post-quantum signature scheme. Size kills that as a default for the public web.
ML-DSA-44 signatures are about 2,420 bytes. RSA-2048 signatures are 256 bytes; ECDSA P-256 signatures are 64 bytes. Public keys grow as well. A typical Web PKI handshake today carries five signatures and two public keys. Swap those for ML-DSA and one handshake can exceed 10 kilobytes. Cloudflare's measurements show a meaningful share of real-world TLS connections fail at that size; the rest get slower. Let's Encrypt will not flip that on as the default.
They are tracking ML-DSA in X.509 (RFC 9881) and in TLS, and Go 1.27 adding ML-DSA to the standard library. Those pieces still matter. They are not the issuance path Let's Encrypt is betting on for web scale.
Merkle Tree Certificates instead
The path they announced is Merkle Tree Certificates (MTCs).
A conventional CA signs each certificate individually. An MTC CA issues certificates in batches. One signature covers the batch. Browsers keep a separately updated "landmark" of those batch signatures. In the common case, the TLS handshake then carries one signature, one public key, and one inclusion proof — smaller than today's handshake, even with post-quantum algorithms. If a client's landmark is stale, a larger "standalone" form is the fallback.
Transparency is not bolted on after issuance. The certificate only exists as a leaf in a published Merkle tree. Let's Encrypt has run Certificate Transparency logs (append-only Merkle trees) in production since 2019, so the data structure is not new to them.
Chrome has said MTCs are its preferred path for post-quantum certificates on the public web. Cloudflare and Chrome are already running a feasibility experiment against live traffic. The IETF PLANTS working group is standardizing the design.
The dates
Let's Encrypt's own targets, as of the 3 June 2026 post:
- Late 2026 — staging environment that issues MTCs - 2027 — production-ready environment
That is infrastructure readiness, not "every site on earth is post-quantum authenticated." Browsers, root programs, libraries, and ACME clients still have to land support. Let's Encrypt is in the PLANTS and ACME working groups while those standards settle.
What you should do now
If you operate a website or TLS terminator
1. Keep renewing Let's Encrypt certificates the way you do today. Issuance and renewal do not change.
2. Turn on hybrid post-quantum key exchange: X25519MLKEM768. This is the highest-leverage change in 2026. It does not require a new certificate. It does protect recorded traffic against later decryption.
3. Do not wait for post-quantum certificates before doing (2). Encryption and authentication are on different clocks.
If you maintain an ACME client or a certificate pipeline
Start tracking the PLANTS working group and the mtcs@chromium.org list. Some of the coming issuance changes will need client-side support. Clients that show up ready when staging opens will matter more than another blog post about algorithms.
If you are a security lead writing a 2026–2027 plan
Put "enable hybrid KEX on every public TLS terminator" in this quarter. Put "evaluate MTC / ACME client support" on the 2027 calendar, tied to Let's Encrypt's production target — not to a panic date in 2026. Post-quantum certificates from Let's Encrypt are promised to arrive the usual way: free, automated, ACME.
What not to do
Do not rotate to a paid CA just to "get PQ certs" in 2026. Public post-quantum certificates are not the bottleneck this year; handshake size and ecosystem readiness are. Do not disable classic certificates early. Do not treat a staging CA as production. Do not confuse "my CDN already does PQ key exchange" with "my origin certificate is post-quantum signed" — those are different layers.
A simple timeline
| When | What actually changes for you |
|---|---|
| Now (2026) | Enable X25519MLKEM768 on servers. Certificates stay as they are. |
| Late 2026 | Let's Encrypt staging MTCs. Watch if you run ACME software. Ignore if you only renew certs. |
| 2027 | Let's Encrypt production MTCs, if the ecosystem is ready. Plan ACME client upgrades. |
| ~2029–2035 | Broader industry and government deprecation windows for RSA-2048 / P-256. |
The quantum transition is a change to the machinery under TLS, not a reason to stop using Let's Encrypt or to hand-issue certificates. Turn on hybrid key exchange this year. Let the CA, browsers, and ACME clients do the authentication migration on the published staging-then-production track.
This post accompanies our Let's Encrypt / post-quantum TLS notes. Follow the series at amtocbot.com.
No comments:
Post a Comment