On February 28, 2026, Google’s Chrome team announced that the future of HTTPS authentication won’t look like the X.509 certificate chains we’ve relied on for decades. Instead, Chrome is moving toward Merkle Tree Certificates (MTCs)—a fundamentally new architecture where a certificate authority signs a single “tree head” representing millions of certificates, and browsers receive only a compact proof of inclusion. The IETF’s new PLANTS (PKI, Logs, And Tree Signatures) working group is standardizing the spec, Cloudflare is already running live experiments with Chrome, and Google has laid out a three-phase roadmap targeting a quantum-resistant root store by Q3 2027.

At DigiCert, we’ve been watching this unfold from the inside—participating in the IETF PLANTS working group and investing in post-quantum readiness for years.

But specs and blog posts only get you so far. We wanted to build something you could actually run, inspect, and break apart. Today, we’re open-sourcing MTC Playground(mtc-bridge): a standalone Go service that implements a substantial portion of draft-ietf-plants-merkle-tree-certs-01 and lets anyone experience what the post-quantum PKI transition actually looks like in practice.

Why this matters right now

The driving problem is straightforward: Post-quantum algorithms like ML-DSA produce signatures and keys roughly forty times larger than today’s elliptic curve equivalents—around 2.5 kilobytes versus 64 bytes. Multiply that across a full certificate chain, and every TLS handshake on the internet carries a significant bandwidth penalty, especially on mobile and high-latency networks.

MTCs solve this by decoupling cryptographic strength from the data transmitted during connection setup. Instead of shipping individually signed certificate chains, the CA signs one tree head, and the browser verifies a compact Merkle inclusion proof—a handful of SHA-256 hashes—regardless of the algorithm used. Post-quantum authentication, delivered in roughly the same bandwidth footprint as today. 

But the architectural shift goes deeper. With MTCs, transparency is built into issuance itself. A certificate cannot exist without being included in the tree—there’s no gap between issuance and public logging. This eliminates the bolt-on overhead that Certificate Transparency (CT) adds to today’s handshakes. 

Google’s timeline makes this urgent:

• Phase 1 (underway) is a live experiment with Cloudflare.

• Phase 2 (Q1 2027) bootstraps public MTC infrastructure with existing CT log operators.

• Phase 3 (Q3 2027) establishes the Chrome Quantum-resistant Root Store (CQRS), supporting only MTCs. 

Chrome has explicitly stated it has no immediate plan to add post-quantum X.509 certificates to the current Chrome Root Store. MTCs are the path forward.

What MTC Playground does

MTC Playground is an experimental implementation that lets you see this technology in action rather than just read about it. It’s designed for exploration and testing—not hardened for production—but it implements the real spec and provides the infrastructure to run a full ACME-to-MTC pipeline. Here’s what’s inside:

• Spec-compliant MTC certificates: The primary mode produces certificates where signatureAlgorithm = id-alg-mtcProof (OID 1.3.6.1.4.1.44363.47.0) and the signatureValue field carries the binary MTCProof—not a traditional cryptographic signature, but a Merkle inclusion proof with optional cosigner signatures. This is the format described in the IETF draft, and it represents a fundamentally different trust model: The certificate’s authenticity is established by its verifiable position in a transparent, append-only tree.

• Post-quantum cosigning with ML-DSA: The system supports multi-cosigner subtree signing using both Ed25519 (classical) and ML-DSA-44/65/87 (post-quantum) via Cloudflare’s circl library. This demonstrates the hybrid signing model where tree heads are authenticated by both classical and post-quantum algorithms simultaneously, providing defense-in-depth during the transition period.

• Full ACME server (RFC 8555): A standalone ACME endpoint runs on a separate port and implements the complete certificate order lifecycle: account creation with JWS verification (ES256 + RS256), order management, http-01 challenge validation, CSR finalization, and certificate download with the MTC assertion bundle attached. This is the ACME-only workflow that Google envisions as the standard issuance path for the MTC ecosystem.

• DigiCert Private CA integration: When connected to a DigiCert ONE Private CA instance, the system watches the CA’s MariaDB database for new certificate issuances and revocations, appending each to the Merkle tree automatically. This models how an existing CA can extend its infrastructure to support MTC transparency without disrupting its current issuance pipeline. 

• Standalone local CA mode: For those who want to experiment without a DigiCert license, the local CA mode generates spec-compliant MTC certificates entirely on its own. A single make demo-mtc command runs the complete flow: key generation, CSR creation, TBSCertificateLogEntry construction with SHA-256 hashed SPKI, Merkle tree building, inclusion proof computation, MTC certificate assembly, and end-to-end verification.

• C2SP tlog-tiles HTTP API: The Merkle tree is served over the standard tlog-tiles protocol—the same format used by Go’s sumdb and the Sigstore ecosystem. Clients can fetch checkpoints (signed with Ed25519 in C2SP signed-note format), hash tiles at any level, entry bundle tiles, inclusion proofs, and consistency proofs. This isn’t a proprietary API; it’s the interoperable transparency log format. 

• Revocation tracking: Revocation is handled via a bitfield indexed by tree position, polled from the CA database. This aligns with the MTC spec’s revocation model, which focuses on key-compromise events rather than the legacy CRL/OCSP infrastructure.

  
  

  The MTC Bridge dashboard showing live log statistics, assertion issuer metrics, recent
  checkpoints, and consistency proofs.

Under the hood: How the Merkle tree works

For those who want to dig into the cryptography, MTC Playground implements RFC 9162-compliant Merkle tree construction. Leaves are hashed as SHA-256(0x00 ∥ data) and interior nodes as SHA-256(0x01 ∥ left ∥ right) —the domain-separated hashing that prevents second preimage attacks on the tree structure. 

Each certificate enters the tree as a <MerkleTreeCertEntry encoded in the TLS presentation language: a 1-byte type tag, 3-byte length prefix, and the DER-encoded TBSCertificateLogEntry. The log entry itself contains a SHA-256 hash of the Subject Public Key Info rather than the full public key—a design choice in the spec that keeps log entries compact while still binding the certificate to its key.

The MTCProof embedded in the certificate’s signatureValue field carries a uint64 subtree start and end range, a length-prefixed inclusion proof (the sibling hashes needed to walk from the leaf to the subtree root), and zero or more MTCSignature entries from cosigners. In signatureless mode—which is the most efficient deployment model—the proof is verified against a known landmark (a tree_size → root_hash mapping that browsers receive out-of-band), and no cosigner signatures are needed at all. 

The system also supports consistency proofs (RFC 9162 §2.1.4), which allow an auditor to verify that the tree is genuinely append-only: a new tree of size N is a strict extension of a previous tree of size M, with no entries modified or removed. This is the cryptographic guarantee that makes the transparency log trustworthy.

The visualization dashboard

One of the most useful features for understanding MTCs is the admin dashboard and visualization explorer at /admin/. Rather than just exposing API endpoints, MTC Playground provides interactive visual tools for exploring the tree structure: 

Sunburst and treemap views render the Merkle tree hierarchy, letting you see how certificates are organized into tiles and how the tree grows over time. A proof explorer visualizes inclusion proofs—showing the path from a specific leaf through the interior nodes up to the root, with the sibling hashes highlighted at each level. A certificate browser provides search by serial number, status badges (active/revoked), and detail pages showing parsed X.509 metadata alongside the MTC assertion bundle. Four color modes make it easier to distinguish between different certificate types, revocation states, and proof paths.

The sunburst visualization showing 8,430 certificates across three CAs, with revocation highlighting and assertion coverage metrics.

The dashboard uses HTMX for live polling, so metrics like tree size, checkpoint count, assertion issuer progress, and revocation status update in real time. It’s built to be a teaching tool as much as a debugging interface.

The proof explorer visualizing a Merkle inclusion proof for leave #8321—showing the 9-hash path from leave to root with
each sibling hash at every level.

Running the full flow

Getting started is straightforward. The project provides Docker Compose for reproducible deployment:

The demo-mtc command runs an end-to-end MTC certificate demo in seconds: It generates an ECDSA P-256 key pair, builds the TBSCertificateLogEntry, wraps it in a MerkleTreeCertEntry, constructs a Merkle tree, computes the inclusion proof, assembles the final certificate with signatureAlgorithm = id-alg-mtcProof, and verifies everything. You get a spec-compliant MTC certificate you can inspect with openssl x509 -text and verify offline with the included mtc-verify-cert CLI.

For the full ACME flow with Docker:

cp .env.example .env          # Configure credentials 
./gen-demo-cert.sh             # Generate TLS certs for ACME server 
docker compose up -d           # Start all services 

Then hit http://localhost:8080/admin/ to watch the Merkle tree grow as certificates are issued, or run the 29-test conformance suite with make conformance to validate the complete pipeline: ACME account creation → order → challenge → CSR finalize → Merkle tree ingestion → assertion proof generation → certificate download with MTC proof attached.

TLS assertion stapling

MTC Playground also demonstrates how MTC proofs travel in a real TLS handshake. The mtc-tls-server binary staples the Merkle inclusion proof to every connection via the SignedCertificateTimestamps extension (repurposing the existing CT mechanism in Go’s crypto/tls), and mtc-tls-verify connects, extracts the proof, and cryptographically verifies it against the bridge’s checkpoint. This is a working prototype of what the browser-side verification will eventually look like.

What’s next

MTC Playground implements a substantial portion of the IETF draft, but some things are still out of scope: the external cosigner protocol (which requires distributed coordination infrastructure), TLS 1.3 custom extensions (Go’s crypto/tls doesn’t support them, so we use the SCT field as a carrier), and browser relying-party logic. These are areas where the ecosystem needs to mature, and where we expect the IETF PLANTS working group to continue refining the spec.

To be clear: MTC Playground is a learning tool, not a production system. It hasn’t been hardened, audited, or optimized for the demands of real-world PKI infrastructure. We’re sharing it because we believe the best way to prepare for a major ecosystem shift is to let people experiment with the technology early. Stay tuned—we’ll have more to share about production-grade, cryptographically scalable MTC solutions as the spec matures and the ecosystem takes shape.

The project is licensed under AGPL v3 for open-source use, with a commercial license available from DigiCert for organizations that want to integrate it into proprietary products.

The transition to post-quantum web authentication is not a distant scenario—it’s happening now, with real code, real traffic, and real timelines. MTC Playground is our contribution to making that transition tangible: something you can clone, run, and explore today, rather than waiting for it to arrive in a browser update sometime in 2027.

If you’re a CA operator, a security engineer, or just someone who wants to understand what the next generation of HTTPS looks like, clone the repo and start experimenting. The Merkle tree is waiting.

MTC Playground is available at github.com/digicert/ca-extension-mtc-playground. For questions about DigiCert’s post-quantum readiness, visit digicert.com/blog/google-merkle-tree-certificates. For questions about evaluating DigiCert Private CA, contact us at sales@digicert.com.