Let’s Encrypt Chooses Merkle Tree Certificates for PQC
Let’s Encrypt has presented a concrete roadmap for post-quantum-safe certificates in the Public Web PKI. The certificate authority plans to use so-called Merkle Tree Certificates in the future. This points to a possible migration path for public TLS certificates that combines post-quantum cryptography with lean TLS handshakes. The announcement is particularly relevant because Let’s Encrypt is one of the world’s most important Public CAs for automatically issued TLS certificates. Changes in this environment often have a signaling effect for browsers, ACME clients, cryptographic libraries, and other components of the Web PKI ecosystem. A staging environment for Merkle Tree Certificates is planned for late 2026, with a production-ready offering expected in 2027.
Why Post-Quantum Signatures Are a Challenge for TLS Handshakes
For a long time, the discussion around post-quantum cryptography focused primarily on key exchange. This is where a concrete long-term risk already exists today: encrypted traffic can be intercepted and stored, even if decryption would only become possible later with a powerful quantum computer. This scenario is often referred to as “harvest now, decrypt later.” The decisive factor is the required protection period: the longer data must remain confidential, the more relevant this risk becomes today.
For certificates and digital signatures, the situation is different. An attacker would have to forge a signature during the live communication. Nevertheless, authentication is also moving further into focus as standards bodies, browser vendors, and infrastructure operators prepare their migration paths for the coming years.
The technical challenge is mainly that post-quantum-safe signatures require significantly more bytes than ECDSA or RSA. If existing X.509 certificates and certificate chains were simply migrated to post-quantum signatures with higher data volumes, TLS handshakes could grow noticeably. This would affect performance, bandwidth, and connection stability.
Merkle Tree Certificates as an Alternative Approach
Merkle Tree Certificates, or MTCs, therefore take a different approach. The certificate authority no longer signs each certificate individually in the traditional X.509 model. Instead, many certificates are grouped together in a Merkle tree structure. A signature refers to the root of this tree. In the MTC approach, clients use a compact proof to verify that a specific certificate is part of this structure.
In the common case, the authentication data in the TLS handshake consists of one signature, one public key, and a so-called inclusion proof. This significantly reduces the additional overhead caused by post-quantum signatures.
The approach has another dimension: Certificate Transparency becomes more closely integrated with the certificate model. CT logs already use Merkle trees today, but as a separate transparency system alongside the actual certificate issuance process. Today, a CA issues a certificate and logs it separately in Certificate Transparency logs. With Merkle Tree Certificates, each certificate is part of a published Merkle tree. Issuance and transparency therefore move closer together.
Importance for the Public Web PKI
For the Public Web PKI, this approach could become an important building block in the post-quantum migration. Cloudflare and Chrome are already testing Merkle Tree Certificates with real internet traffic. Chrome has described MTCs as its preferred path for post-quantum-safe certificates on the public web.
However, broad adoption will still require considerable work. Standardization is underway, including in the IETF PLANTS working group. In addition, the ACME protocol, browsers, cryptographic libraries, ACME clients, and root programs will need to support the new methods. For Let’s Encrypt users, nothing changes in the short term: existing certificates will continue to be issued and renewed as usual.
Private PKIs Require a Separate Assessment
For Private PKIs, no general migration path can currently be derived from this development. Unlike the public Web PKI, internal PKI environments often follow different requirements. While Let’s Encrypt uses MTCs primarily to address the scalability and performance requirements of public TLS certificates, organizations need to assess their internal trust infrastructures separately.
This includes creating an inventory of existing cryptographic methods, prioritizing particularly relevant systems, and determining how new algorithms can be integrated into existing PKI environments in a controlled manner. We will take a closer look at the role Merkle Tree Certificates may play in Private PKIs in a future article.
Further developments will show how this migration path becomes established in the public Web PKI ecosystem. At the same time, organizations still need to determine which requirements the post-quantum migration creates for their own trust infrastructures. Private PKIs therefore need to be evaluated in their own operational and technical context.