Let's Encrypt's Post-Quantum Future: Merkle Tree Certificates

Let's Encrypt's Post-Quantum Future: Merkle Tree Certificates

In June 2026 Let's Encrypt announced its post-quantum Web PKI roadmap: Merkle Tree Certificates (MTC) as the path forward, with a staging environment that issues MTCs targeted for late 2026 and a production-ready environment in 2027. For site owners, existing certificate issuance and renewal is completely unaffected, and post-quantum certificates will arrive the way the service always has: free, automated, and open to anyone with an ACME client.

Why the Timeline Is Accelerating

For years the post-quantum conversation centered on encryption against harvest-now-decrypt-later attacks, while authentication was seen as less urgent. That comfort is eroding:

• The NSA's CNSA 2.0 has steered national security systems toward post-quantum algorithms since 2022, on a 2030-2035 schedule.
• NIST's draft transition guidance would deprecate RSA-2048 and P-256 after 2030 and disallow them after 2035.
• The EU roadmap targets high-risk systems by end of 2030 and broad migration by 2035.
• In 2026 the timeline shortened further: Google and Cloudflare both committed to migrating their services by 2029, and Go 1.27 added ML-DSA, a NIST-standardized post-quantum signature scheme, to the standard library.

The Web PKI's Unique Problem: Size

Post-quantum signatures are hard to deploy in the Web PKI for one reason: size. ML-DSA-44, one of the smaller NIST schemes, has signatures around 2,420 bytes, versus 256 bytes for RSA-2048 and 64 bytes for ECDSA-P256. A typical handshake carries five signatures and two public keys; replacing them with ML-DSA would push a single TLS handshake past 10 kilobytes. Cloudflare's research shows that at that scale, a meaningful share of TLS connections fail on real-world networks, and the rest get slower.

Signatures differ by two orders of magnitude, which is exactly why "just swap algorithms" does not work and the certificate structure itself must be redesigned. It also explains why the authentication side of post-quantum migration is slower than encryption: X25519MLKEM768 adds only a bounded amount to the key exchange, while certificates would balloon in size.

How Merkle Tree Certificates Work

MTCs issue certificates in batches, with a single signature covering an entire batch. Browsers keep up to date on those batch signatures (called landmarks) separately from the TLS handshake. In the common case, the entire authentication path is one signature, one public key, and one inclusion proof, smaller than today's Web PKI handshake even when using post-quantum algorithms. The "standalone" form is a slightly larger fallback when a client's landmark is out of date.

MTCs also make transparency a property of issuance itself: a certificate cannot exist outside the Merkle tree. Let's Encrypt has operated Certificate Transparency logs since 2019, the same core data structure MTCs build on. Cloudflare and Chrome are already running a feasibility experiment with MTCs against real traffic, the IETF's PLANTS working group is standardizing the design, and Chrome has announced MTCs as its preferred path for adding post-quantum certificates to the public web.

What You Should Do Now

For most sites, nothing changes today. The highest-leverage action is to ensure your server supports hybrid post-quantum key exchange (X25519MLKEM768) — major browsers and operating systems already do, and enabling it at the server protects against harvest-now-decrypt-later.

With Nginx on OpenSSL 3.5+, add the group to the config:

ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;
ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

Reload with nginx -t && nginx -s reload, then verify the negotiated group contains X25519MLKEM768 via openssl s_client -connect your-domain:443 -groups, or simply run curl --tlsv1.3 --curves X25519MLKEM768 -I https://your-domain and see whether the handshake succeeds. Caddy and most popular reverse proxies already include the group in their defaults, so in most cases upgrading the software is all it takes. Once enabled, even if a future quantum computer cracks classic public keys, previously harvested traffic cannot be decrypted. For certificate automation and lifecycle, see Let's Encrypt SSL setup and Certbot auto-renewal, with selection guidance in the SSL certificate guide. More content is in the Security/SSL category.

Frequently Asked Questions

Will it affect performance or compatibility? Hybrid key exchange adds only a few bytes during the handshake, and older clients fall back to classic curves automatically, so existing compatibility is preserved.

Will my current certificates expire early? No. MTC is an additive evolution; existing certificates are issued and renewed on their normal schedule. When renewal comes due, continue as usual — see ACME ARI renewal for smarter renewal timing.

Who needs to act early? Self-managed TLS termination, API gateways, and long-lived key infrastructure should follow CA and browser progress closely; ordinary sites just keep their ACME client updated. For certificate types and selection see SSL certificate types, and for automation see Certbot automation.

Reference: NIST Post-Quantum Cryptography project https://csrc.nist.gov/Projects/post-quantum-cryptography; FIPS 204 (ML-DSA) https://csrc.nist.gov/pubs/fips/204/final; source https://letsencrypt.org/2026/06/03/pq-certs