Let’s Encrypt Merkle Tree Certificates Secure Let’s Unveils
Let’s Encrypt has announced its roadmap for post-quantum Web PKI, unveiling a novel approach: Merkle Tree Certificates (MTCs). This innovative design promises quantum-resistant authentication,...
Let’s Encrypt has announced its roadmap for post-quantum Web PKI, unveiling a novel approach: Merkle Tree Certificates (MTCs). This innovative design promises quantum-resistant authentication, crucially without bloating TLS handshakes or compromising the web’s performance expectations.
Traditional X.509 certificate chains require significant bandwidth, which would increase substantially with the adoption of robust post-quantum algorithms. MTCs solve this by replacing the heavy, serialized chain of signatures with compact Merkle Tree proofs.
Earlier this year, Google unveiled Merkle Tree Certificates to Shield HTTPS Against Quantum Threats, as Chrome is spearheading the transition to Merkle Tree Certificates (MTCs).
For years, post-quantum cryptography discussions prioritized encryption over authentication. The logic was sound: “harvest now, decrypt later” attacks make encrypted traffic immediately vulnerable, while forging authentication signatures requires a live Cryptographically Relevant Quantum Computer (CRQC). That window is closing fast.
The NSA’s CNSA 2.0 suite mandates that national security systems migrate to post-quantum algorithms by 2030–2035. NIST’s draft transition guidance (IR 8547) would deprecate RSA-2048 and P-256 after 2030 and disallow them after 2035.
The EU’s post-quantum roadmap targets high-risk systems by the end of 2030. Most significantly, Google announced a 2029 migration deadline for its services, and Cloudflare issued a parallel commitment.
Go 1.27 also added ML-DSA, a NIST-standardized post-quantum signature scheme, directly to its standard library, signaling infrastructure readiness.
The Web PKI’s scale makes naive post-quantum migration painful. ML-DSA-44, one of NIST’s smaller standardized schemes, produces signatures of ~2,420 bytes, nearly 38× larger than ECDSA-P256’s 64 bytes.
A typical TLS handshake carries five signatures and two public keys. Swapping these with ML-DSA equivalents pushes a single handshake well beyond 10 KB.
Cloudflare’s research confirms the consequence: at that scale, a meaningful share of real-world TLS connections fail outright, and the rest slow down. Degrading every TLS connection globally is too steep a tradeoff for a threat that hasn’t yet materialized.
Let’s Encrypt Unveils Merkle Tree Certificates
MTCs reframe how certificates are issued and verified. Instead of signing each certificate individually, a CA issues certificates in batches, with a single post-quantum signature covering the entire batch. Clients (browsers) maintain these batch signatures, called landmarks, independently of the TLS handshake.
The result: an MTC handshake carries just one signature, one public key, and one inclusion proof smaller than today’s Web PKI handshake, even while using post-quantum algorithms.
MTCs also bake in Certificate Transparency by design. Every certificate exists as part of a published Merkle tree, making transparency intrinsic to issuance rather than bolted on afterward. Let’s Encrypt has operated CT logs built on Merkle trees since 2019, giving it direct operational experience with the core data structure.
The MTC ecosystem is already mobilizing:
- Cloudflare and Chrome are running a live MTC feasibility experiment against real internet traffic
- The IETF’s PLANTS working group is actively standardizing the design
- Chrome has declared MTCs its preferred path for post-quantum certificates on the public web
Let’s Encrypt is targeting a staging MTC environment in late 2026 and a production-ready environment in 2027. The rollout requires big changes across issuance infrastructure, the ACME protocol (RFC 9881), revocation tooling, and CT log infrastructure.
For existing subscribers, nothing changes today. Certificates will continue to be issued via ACME exactly as before. ACME client maintainers, however, should begin tracking the PLANTS working group and the [email protected] mailing list now, as client-side changes will be required.
For server operators, the most urgent action today remains enabling hybrid post-quantum key exchange (X25519MLKEM768) the primary 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.



No Comment! Be the first one.