Let’s Encrypt Rolls Out Post-Quantum Cryptography Certificates

Key Takeaways

• Let’s Encrypt has unveiled its strategy for post-quantum Web Public Key Infrastructure (PKI), introducing Merkle Tree Certificates (MTCs).
• MTCs aim to provide quantum-resistant authentication without significantly increasing the size of TLS handshakes or degrading web performance.
• This new approach addresses the challenge of large signature sizes inherent in current post-quantum algorithms, which would otherwise slow down or break web connections.
• The initiative involves collaboration with major players like Google Chrome and Cloudflare, with a staging environment targeted for late 2026 and production readiness in 2027.
• Existing Let’s Encrypt subscribers will see no immediate changes, but ACME client developers should monitor ongoing standardization efforts.

Let’s Encrypt Forges Path to Quantum-Resistant Web with Merkle Tree Certificates

Let’s Encrypt has announced a significant advancement in its roadmap toward post-quantum cryptography for the Web PKI, introducing an innovative solution called Merkle Tree Certificates (MTCs). This new design promises to deliver quantum-resistant authentication, critically avoiding the performance bottlenecks and increased data overhead typically associated with transitioning to more robust cryptographic algorithms.

The current X.509 certificate chains, fundamental to secure web communication, already demand substantial bandwidth. Implementing post-quantum algorithms with their inherently larger signature sizes would drastically inflate this requirement. MTCs circumvent this issue by replacing the bulky, serialized chain of digital signatures with highly compact Merkle Tree proofs.

Earlier this year, Google first revealed the concept of Merkle Tree Certificates to Shield HTTPS Against Quantum Threats, with Chrome leading the charge in adopting MTCs as a crucial component of future web security.

For many years, discussions surrounding post-quantum cryptography primarily focused on encryption rather than authentication. The prevailing logic was that “harvest now, decrypt later” attacks posed an immediate threat to encrypted data, while forging authentication signatures would only become feasible with the advent of a live Cryptographically Relevant Quantum Computer (CRQC). However, the timeline for this quantum threat is rapidly approaching.

The Looming Quantum Deadline

Government and industry bodies are setting clear deadlines for the migration to post-quantum algorithms. The NSA’s CNSA 2.0 suite mandates that all national security systems transition to post-quantum algorithms between 2030 and 2035. Concurrently, NIST’s draft transition guidance (IR 8547) proposes deprecating RSA-2048 and P-256 after 2030 and prohibiting their use altogether after 2035.

Internationally, the EU’s post-quantum roadmap aims for high-risk systems to adopt these new algorithms by the end of 2030. Significantly, Google has announced a 2029 migration deadline for its own services, a commitment echoed by Cloudflare with its parallel roadmap.

Further demonstrating infrastructure readiness, Go 1.27 has integrated ML-DSA, a NIST-standardized post-quantum signature scheme, directly into its standard library.

Addressing the Performance Challenge

The sheer scale of the Web PKI presents a formidable challenge for a straightforward post-quantum migration. For instance, ML-DSA-44, one of NIST’s more compact standardized schemes, generates signatures approximately 2,420 bytes in size. This is nearly 38 times larger than the 64-byte signatures produced by ECDSA-P256, which is widely used today.

A typical TLS handshake involves five signatures and two public keys. Replacing these with their ML-DSA equivalents would push a single handshake’s data volume well beyond 10 KB. Research conducted by Cloudflare has confirmed that such an increase would lead to a significant proportion of real-world TLS connections failing outright, while others would experience considerable slowdowns. This degradation of global TLS connections is deemed an unacceptable trade-off for a threat that has yet to fully materialize.

Let’s Encrypt’s Merkle Tree Certificates: A New Paradigm

MTCs fundamentally redefine the process of certificate issuance and verification. Instead of individually signing each certificate, a Certificate Authority (CA) issues certificates in batches, securing the entire batch with a single post-quantum signature. Client software, such as web browsers, then stores these batch signatures, referred to as landmarks, independently of the TLS handshake.

The result is a streamlined MTC handshake that contains only one signature, one public key, and a single inclusion proof. This structure makes the MTC handshake smaller than current Web PKI handshakes, even when employing advanced post-quantum algorithms.

MTCs also inherently integrate Certificate Transparency (CT). Each certificate is an integral part of a published Merkle tree, making transparency an intrinsic feature of the issuance process rather than an add-on. Let’s Encrypt has extensive experience with this core data structure, having operated CT logs built on Merkle trees since 2019.

Ecosystem Mobilization and Rollout Timeline

The MTC ecosystem is already gaining momentum:

• Cloudflare and Chrome are conducting a live MTC feasibility experiment, testing the technology with actual internet traffic.
• The IETF’s PLANTS working group is actively engaged in standardizing the MTC design.
• Chrome has publicly stated its preference for MTCs as the primary solution for post-quantum certificates on the public web.

Let’s Encrypt is targeting a staging MTC environment for late 2026, with a production-ready environment anticipated in 2027. This ambitious rollout will necessitate significant modifications across various components, including issuance infrastructure, the ACME protocol (RFC 9881), revocation tooling, and CT log infrastructure.

What You Should Do

• For Existing Let’s Encrypt Subscribers: No immediate changes are required for your current certificate issuance or usage. Continue to manage certificates via ACME as before.
• For ACME Client Maintainers: Begin tracking the PLANTS working group and the [email protected] mailing list. Client-side changes will be necessary as MTCs approach production.
• For Server Operators: Prioritize enabling hybrid post-quantum key exchange (specifically X25519MLKEM768). This remains the most critical defense against “harvest-now-decrypt-later” attacks on encrypted traffic.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.