Let’s Encrypt plans Merkle Tree Certificates to prepare HTTPS for quantum threats

Let’s Encrypt is preparing a major change to web certificates as the industry gets ready for a post-quantum internet. The nonprofit certificate authority says it plans to support Merkle Tree Certificates, a new approach designed to make HTTPS authentication resistant to future quantum attacks without making TLS handshakes much larger.

The plan, outlined in a Let’s Encrypt roadmap, does not change anything for current users today. Existing Let’s Encrypt certificates will continue to be issued and renewed through ACME as usual.

The organization is targeting a staging environment for Merkle Tree Certificates, also known as MTCs, in late 2026. A production-ready environment is planned for 2027, depending on standards work, browser support, ACME client changes, and wider ecosystem readiness.

Why HTTPS certificates need a post-quantum plan

Most post-quantum security discussions have focused on encryption because attackers can record encrypted traffic today and decrypt it later if a powerful quantum computer becomes available. That risk is often called harvest now, decrypt later.

Certificate authentication faces a different risk. An attacker would need a cryptographically relevant quantum computer to forge a certificate signature in real time, not years later. Even so, the web cannot wait until that risk arrives because certificate systems, browser trust stores, and server software take years to change.

NIST transition guidance says the United States should complete migration to post-quantum cryptography across federal systems by 2035. The same draft guidance points to deprecation and disallowance timelines for several classical public-key algorithms, including RSA and ECDSA.

The problem with normal post-quantum certificates

Moving today’s Web PKI directly to post-quantum signatures would create a major size problem. Post-quantum signatures and public keys are much larger than the ECDSA and RSA data commonly used in TLS certificate chains today.

The Let’s Encrypt announcement says ML-DSA-44 signatures are about 2,420 bytes, compared with 64 bytes for ECDSA-P256. A typical Web PKI handshake today carries multiple signatures and public keys, so replacing them with post-quantum equivalents could push a single TLS handshake beyond 10 KB.

That extra data matters because TLS handshakes happen constantly across the web. Larger certificate chains can increase latency, create bandwidth costs, and break connections on networks or middleboxes that do not handle larger handshakes well.

Certificate approach	How it works	Main tradeoff
Traditional X.509 with classical signatures	Each certificate chain carries smaller RSA or ECDSA signatures.	Efficient today, but vulnerable to future quantum attacks.
Traditional X.509 with post-quantum signatures	Each certificate chain carries larger post-quantum signatures and keys.	Quantum-resistant, but TLS handshakes become much larger.
Merkle Tree Certificates	A CA signs a tree covering batches of certificates, while servers send compact inclusion proofs.	Requires new browser, CA, server, and standards support.

How Merkle Tree Certificates work

Merkle Tree Certificates change how certificate authentication data gets delivered. Instead of signing every certificate individually in a way that adds large signatures to every handshake, a certificate authority can issue certificates in batches and sign a tree that covers that batch.

Google’s Chrome team describes MTCs as an evolution of HTTPS certificates. In this model, the browser can validate a compact proof showing that a certificate belongs inside a signed Merkle tree.

In the common case, the TLS handshake needs one signature, one public key, and one inclusion proof. Let’s Encrypt says that can be smaller than today’s Web PKI handshake even while using post-quantum algorithms.

Chrome and Cloudflare are already testing the idea

Google has said Chrome does not currently plan to add traditional X.509 certificates with post-quantum cryptography to the Chrome Root Store. Instead, Chrome is working with partners on MTCs through the IETF PLANTS working group.

Cloudflare is also running an experiment with Chrome to test MTCs against real internet traffic. The experiment uses existing trusted X.509 certificates as a safety layer while researchers measure how the new design behaves in practice.

The goal is to learn what breaks, how clients handle landmarks, how much latency improves or changes, and how often fallback certificate paths are needed. That type of testing matters because TLS changes often uncover issues with middleboxes, older clients, and network assumptions.

Certificate Transparency becomes part of issuance

Merkle Tree Certificates also change how transparency works. In today’s Web PKI, Certificate Transparency operates as a separate logging system after certificate issuance.

With MTCs, every certificate must exist inside a public Merkle tree. That makes transparency a built-in property of the certificate model, rather than an additional system layered on top of normal issuance.

Chrome’s post-quantum HTTPS plan says this approach can include the security properties of today’s Certificate Transparency ecosystem without adding extra overhead to the TLS handshake.

What changes for Let’s Encrypt users now

Nothing changes immediately for website owners using Let’s Encrypt. Certificates will continue to work, renew, and validate in the same way they do now.

The long-term change will matter more for ACME client developers, hosting providers, CDNs, browser vendors, and certificate automation platforms. Let’s Encrypt says client-side support will eventually become necessary as standards and implementation details mature.

The change will also require updates across issuance infrastructure, revocation tooling, transparency systems, server deployment logic, and certificate automation workflows. This is why the rollout will take years rather than months.

• Current Let’s Encrypt certificates continue to work as before.
• No immediate server change is required for MTC support.
• ACME client maintainers should track the IETF PLANTS work.
• Hosting platforms should prepare for future certificate pipeline changes.
• Server operators should prioritize post-quantum key exchange first.

Post-quantum key exchange remains the urgent step

Let’s Encrypt says post-quantum encryption is the more urgent issue for the broader internet because encrypted traffic can be harvested today and decrypted later. That is why server operators should focus first on hybrid post-quantum key exchange.

Cloudflare’s PQC support documentation tracks support for X25519MLKEM768, a hybrid key agreement that protects TLS traffic against harvest-now-decrypt-later attacks while retaining classical security.

Browser and server support has been moving quickly. Cloudflare lists Chrome 131 and newer, Edge 131 and newer, Firefox 132 and newer on desktop, and Safari 26 and newer as supporting post-quantum key agreement in their respective environments.

The wider timeline is now taking shape

Quantum-safe web security will not arrive through one switch. It involves encryption, certificate authentication, libraries, browsers, certificate authorities, server software, and operational tooling.

NIST’s draft transition plan frames 2035 as the main migration goal for federal systems, while high-risk and long-lived systems may need earlier action. That timeline is already influencing browser and infrastructure decisions across the public web.

Cloudflare’s MTC experiment shows why early deployment testing matters. The web has to move toward post-quantum authentication without slowing down everyday browsing or breaking certificate validation for normal users.

What website operators should do

Website owners do not need to replace their Let’s Encrypt setup today because MTCs are not yet a production requirement. The smarter move is to keep certificate automation current and make sure servers can support modern TLS features.

Operators should also check whether their CDN, load balancer, hosting platform, or web server supports hybrid post-quantum key exchange. This step addresses the more immediate harvest-now-decrypt-later concern while the certificate authentication ecosystem continues to mature.

Cloudflare’s compatibility list can help teams understand current support across browsers, libraries, and servers. Larger organizations should also begin inventorying systems that rely on long-lived certificates, internal CAs, code signing, device identity, and automated certificate issuance.

Let’s Encrypt’s plan does not mean today’s HTTPS is broken. It means the public web is beginning the next migration before quantum computers force a rushed one.

FAQ