Google Chrome Moves to Merkle Tree Certificates for Quantum‑Safe HTTPS

Google Chrome is shifting to Merkle Tree Certificates (MTCs) as its main way to protect HTTPS against future quantum‑computing threats. Instead of stuffing every TLS handshake with large post‑quantum signatures, Chrome is adopting a compact tree‑based model that keeps encryption fast, scalable, and still secure. This change is part of a broader effort with the IETF’s “PKI, Logs, and Tree Signatures” (PLANTS) working group and aims to modernize the web’s trust infrastructure before quantum computers can realistically break classical cryptography.

For most users, the change will be invisible. The padlock icon stays. Pages load normally. The difference is underneath: Chrome will rely on small Merkle Tree proofs that show a site’s certificate belongs to a large, cryptographically signed tree of identities, rather than shipping long chains of X.509‑style certificates.

Why Chrome Is Not Using Standard X.509 Post‑Quantum Certs

Many organizations are testing traditional post‑quantum X.509 certificates. But Google has decided not to make those the default in the Chrome Root Store because of performance and bandwidth issues.

Standard X.509 chains are already large. When you replace those signatures with post‑quantum algorithms, the size grows sharply. That extra data must travel over every TLS handshake, which can slow down page loads, especially on mobile networks and high‑latency links. Merkle Tree Certificates decouple cryptographic strength from message size, so the browser still gets strong security but without the usual overhead.

How Merkle Tree Certificates Work

At the core of the system is a Merkle tree. A certification authority signs a single “Tree Head” that represents many certificates at once. Each individual certificate is not a full chain, but a compact proof that it is included in that tree.

This design has two main benefits:

• Smaller TLS messages: the browser receives a short inclusion proof instead of a long chain of signatures.
• Built‑in transparency: every MTC must be recorded in a public tree, so hidden or rogue certificates are far harder to add without detection.

In effect, the transparency properties of Certificate Transparency (CT) become part of the protocol itself, not something bolted on in a separate layer.

What Changes for Security and Performance

MTCs make it practical to use strong post‑quantum cryptography without degrading page speed. The cryptographic strength comes from the tree‑wide signatures and the structure of the Merkle proof, not from repeatedly sending large keys in every TLS exchange.

For end users and site owners, the visible change is minimal. The padlock still appears, trusted certificates still validate, and no new warnings show up. Behind the scenes, the system becomes:

• Faster to verify, because there is less data to receive and process.
• More transparent by default, because each certificate must be logged in a public tree.
• Easier to scale for millions of domains, including short‑lived or automated‑generation certificates.

This combination is especially useful for mobile users, high‑traffic CDNs, and regions where every extra kilobyte adds noticeable delay.

Chrome’s Three‑Phase Rollout Plan

Google has laid out a three‑phase plan for bringing MTCs into everyday use. The approach is gradual, so it avoids breaking existing sites while giving the ecosystem time to adapt.

Phase	Timeline	Main Activities
Phase 1	Underway (2025–2026)	Feasibility tests with real traffic using large CDN‑style providers, backed by existing X.509 roots for stability.
Phase 2	Q1 2027	CT log operators start publishing public MTCs so logs can support the new tree‑based format.
Phase 3	Q3 2027	Launch of the Chrome Quantum‑resistant Root Store (CQRS), supporting MTCs alongside the current Chrome Root Program, with optional quantum‑only certificates.

During this period, Chrome is also planning several technical upgrades:

• Full shift to ACME‑only workflows for certificate issuance, which simplifies automation and reduces manual steps.
• Replacement of legacy CRLs with modern, efficient revocation‑status mechanisms.
• Exploration of reproducible Domain Control Validation (DCV) so that certificate issuance can be independently audited.

How Certification Authorities Will Change

The new model reshapes how certification authorities (CAs) fit into the Chrome ecosystem. Google is moving toward a CA‑inclusion framework that emphasizes reliability, transparency, and operational maturity.

New CAs that want to join the quantum‑resistant root store will need to:

• Act as Mirroring Cosigners, helping to cross‑verify tree data and backups.
• Serve as DCV Monitors, validating domain control in a reproducible way.
• Demonstrate strong security practices, solid uptime, and clear audit trails.

This approach reduces reliance on legacy processes and makes the root system more resilient to both technical failures and targeted attacks. It also sets a higher bar for CAs that want to participate in the next generation of web trust.

What This Means for Developers and Site Owners

Most websites will not need to change their code to work with MTCs. The browser handles the tree proofs internally, and the traditional trust model still applies. However, a few practical steps can help during the transition.

• Keep TLS stacks updated to support modern TLS versions and efficient revocation checks.
• Prefer CAs that announce support for MTCs and ACME‑driven workflows, especially if you run large or automated sites.
• Monitor TLS‑handshake performance and round‑trip times, particularly on mobile or constrained networks, as the new model rolls out.
• Be ready to migrate to MTCs or post‑quantum‑aware certificate offerings once those are clearly recommended by your CA and by Chrome policy documents.

For organizations with internal PKI, large CDN footprints, or custom certificate‑management tooling, the move to MTCs will also shape how logging, auditing, and revocation‑pipeline design evolve.

FAQ