The Post-Quantum Future for Let's Encrypt: What Web Developers Need to Know

1. The Quantum Clock Is Ticking

On June 3, 2026, Let's Encrypt announced plans to adopt Merkle Tree Certificates (MTCs) — a fundamentally new approach to TLS authentication designed for the post-quantum era. This isn't just another protocol upgrade; it's the first major redesign of how the Web PKI works since HTTPS became universal.

Let's Encrypt serves approximately 300 million active certificates — it's the largest Certificate Authority in the world. When they change how certificates work, every developer running a web server pays attention.

The announcement signals that post-quantum readiness has moved from "maybe one day" to "we're building it now." This article breaks down what's happening, why it matters, and what you need to do as a developer.

2. Why Now? The Accelerating Post-Quantum Timeline

For years, the conventional wisdom was that post-quantum encryption was urgent (thanks to harvest-now-decrypt-later attacks), but post-quantum authentication (digital signatures) could wait — a quantum computer would need to forge a signature in real time. That calculus has changed.

2.1 Government mandates are setting hard deadlines

The timeline has compressed dramatically:

• NSA CNSA 2.0 suite (2022) — directed national security systems toward post-quantum algorithms on a 2030–2035 schedule
• NIST draft guidance — would deprecate RSA-2048 and P-256 after 2030, disallow after 2035
• EU Quantum-Safe Cryptography Roadmap — targets high-risk systems by end of 2030, broad migration by 2035
• Google — announced 2029 migration target for its own services, citing tightening CRQC arrival estimates
• Cloudflare — followed with a parallel 2029 commitment
• Go 1.27 — added ML-DSA (NIST-standardized post-quantum signature scheme) directly to the standard library

2.2 The real urgency: long-lived keys

Root CA keys, code-signing keys, and identity systems have multi-year lifespans. An attacker who harvests a root CA signature today could forge sub-CAs for years. Standards take years to finalize. Browsers, libraries, and ACME clients need updates. Infrastructure changes at scale take 2–3 years minimum. The work has to start now.

3. The Size Problem: Why Post-Quantum Signatures Don't Fit Today's Web PKI

3.1 The numbers don't lie

A typical TLS handshake today carries 5 signatures + 2 public keys. Naively replacing existing algorithms with ML-DSA would push a single handshake past 10 KB.

3.2 What Cloudflare's testing revealed

Cloudflare's research showed that at those sizes:

• A meaningful share of TLS connections fail on real-world networks
• Remaining connections are measurably slower
• The cost is paid by every TLS connection
• The impact is especially severe for constrained environments (mobile, IoT, developing regions)

The bottom line: A naive ML-DSA swap would degrade user experience across the entire web. That's why a new approach is needed — and that's where Merkle Tree Certificates come in.

4. Merkle Tree Certificates: A Different Approach

4.1 How traditional X.509 works today

Today, each certificate is individually signed by the CA. Certificate Transparency (CT) is bolted on as a separate step: issue the certificate, log it separately, then add extra SCT signatures to every TLS handshake. Every signature in the chain must be transmitted during the handshake.

4.2 How MTCs change the game

MTCs flip this model on its head:

Batch signing: CAs issue certificates in batches. A single post-quantum signature (called a "landmark") covers the entire batch. Browsers stay up to date on landmarks via a separate channel — not during the TLS handshake.

Two operating modes:

• Common case (optimistic): Handshake carries 1 signature + 1 public key + 1 inclusion proof. Smaller than today's Web PKI handshake despite using post-quantum algorithms.
• Standalone (fallback): Slightly larger handshake for clients with outdated landmarks.

4.3 Built-in Certificate Transparency

Because every certificate is part of a published Merkle tree:

• A certificate cannot exist outside the tree — CT is inherent, not bolted on
• This eliminates a complex part of today's CT ecosystem (SCT validation, gossiping, inclusion proofs)
• Let's Encrypt has operated CT logs since 2019 — they have production experience with Merkle trees at scale

4.4 Current status

• Cloudflare + Chrome are already running a feasibility experiment with MTCs against real internet traffic
• IETF PLANTS WG (PKI, Logs, And Tree Signatures) is standardizing the design
• Chrome has announced MTCs as its preferred path for adding post-quantum certificates to the public web

5. Let's Encrypt's Implementation Roadmap

5.1 Timeline

5.2 What needs to change in LE's stack

• Issuance infrastructure — certificate batch creation, landmark signing
• ACME protocol — subscribers need a way to request and obtain MTCs
• Revocation and operational tooling — new mechanisms for batch-level vs certificate-level revocation
• Transparency-log infrastructure — MTCs subsume and extend LE's existing CT log operations

5.3 Standards dependencies

• ML-DSA signatures in X.509 → RFC 9881 (October 2025) — finalized
• ML-DSA signatures in TLS → draft-ietf-tls-mldsa — in progress
• ML-DSA in Go stdlib → Go 1.27 — shipping
• PLANTS WG specifications — in progress

5.4 Impact on developers (today = none)

Let's Encrypt is clear: "Nothing changes today. Your current Let's Encrypt certificates will continue to be issued and renewed exactly as they always have been."

When post-quantum certificates arrive, they'll be:

• Free (same as current certs)
• Automated (same ACME client flow)
• Available to anyone (same constraints as current issuance)

6. What Developers Need to Prepare

6.1 Immediate actions (do this year)

Enable post-quantum key exchange NOW:

• Configure servers to support X25519MLKEM768 (hybrid post-quantum key exchange)
• This protects against harvest-now-decrypt-later attacks — the more urgent threat
• Major browsers already support it; server operators need to flip the switch
• OpenSSL 3.5+ supports it

nginx configuration:

ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1:secp384r1;

Apache configuration:

SSLOpenSSLConfCmd Curves X25519MLKEM768:X25519:prime256v1:secp384r1;

6.2 Medium-term preparation (2026–2027)

• No client-side changes needed yet — backward compatibility is maintained
• Watch the PLANTS WG progress for final MTC specifications
• Monitor certbot, acme.sh, and Caddy for ACME MTC extension support
• CDN operators should test with ML-DSA-sized certificates in staging
• IoT constrained devices may need special attention (firmware updates)
• Review MTU and packet fragmentation on your network path

6.3 Long-term (2028+)

• Expect browsers to deprecate RSA-2048 / P-256 after 2030 per NIST guidance
• Plan full migration of internal PKI (not just Let's Encrypt certificates)
• Code-signing keys, email S/MIME, and document signing will also need post-quantum upgrades

6.4 OpenSSL and library compatibility

• OpenSSL 3.5+ has ML-DSA support in the provider model
• Go 1.27 includes ML-DSA in crypto/mlkem and crypto/mldsa
• Python (cryptography), Node.js, and Java libraries are tracking NIST standards

7. Cross-References: Connecting to Other Security Articles

This article builds on themes from several earlier guides on maximov.by:

Trust in the Web PKI: The BadHost CVE-2026-48710 article covers how certificate mis-issuance compromises trust. MTCs address this by making Certificate Transparency a built-in property — an MTC cannot exist outside its Merkle tree, eliminating a whole class of mis-issuance attacks.

Merkle-tree verification: Just as npm supply-chain attacks require provenance and integrity verification for packages, the Web PKI needs transparent, verifiable issuance for certificates. MTCs apply the same Merkle-tree verification principle to the TLS certificate chain.

Built-in vs bolt-on trust: Our analysis of GitHub Actions cache poisoning shows that building verification into the data structure (rather than bolting it on) removes entire attack surfaces. MTCs do the same for certificates — existence in the tree is synonymous with valid issuance.

8. Key Takeaways

9. FAQ

10. Further Reading

Primary sources

1. Let's Encrypt official announcement (June 3, 2026)
2. Hacker News discussion (313 points)
3. RFC 9881 — ML-DSA Algorithm Identifiers for X.509
4. IETF PLANTS Working Group
5. draft-ietf-tls-mldsa — ML-DSA in TLS (in progress)

Background

6. NIST FIPS 204 (ML-DSA)
7. NIST FIPS 203 (ML-KEM)
8. CNSA 2.0 (NSA, 2022)
9. EU Quantum-Safe Cryptography Roadmap
10. Cloudflare PQ blog archive

Community / implementation

11. Cordon — open-source MTC CA server
12. Soatok's blog post on hybrid post-quantum constructions (April 2026)
13. Let's Encrypt operates Certificate Transparency logs since 2019

Planning a migration or building a new project? Check out my web development services with post-quantum-ready infrastructure for implementation help.