Cloudflare Builds Post-Quantum Certificate Authority With Merkle Tree Certificates
Cloudflare is building a certificate authority designed to support Merkle Tree Certificates, a post-quantum approach intended to reduce the size and scaling costs of Web PKI while making certificate transparency part of the issuance process.
Xcademia Team

Cloudflare is building a new certificate authority (CA) with support for Merkle Tree Certificates (MTCs) as part of its effort to prepare the Web Public Key Infrastructure (Web PKI) for the post-quantum era.
The company says the transition to post-quantum cryptography cannot simply rely on replacing today's cryptographic signatures with larger post-quantum alternatives. At Internet scale, larger signatures could create significant overhead for browsers, certificate authorities, transparency logs and monitoring systems.
Cloudflare's approach is to combine certificate issuance and transparency through MTCs.
MTCs use a Merkle tree to batch certificates into an append-only structure. Instead of signing every certificate individually with a large post-quantum signature, a CA can sign the tree and provide a compact cryptographic inclusion proof showing that a certificate is part of that tree.
Cloudflare says its new CA will support MTC issuance, with a target of early 2027 for inclusion in Google's Chrome Quantum-resistant Root Store. The CA must still apply to the root store and undergo the required evaluation process before it can be trusted by browsers.
Cloudflare also says it plans to provide standard MTC issuance at no cost.
Why the Web PKI Needs a Post-Quantum Approach
The Web PKI provides the trust infrastructure that helps browsers determine whether they are connecting to the intended website.
Certificate authorities validate control over domains and issue certificates that bind domain names to public keys.
Browsers, meanwhile, maintain root programs that define the policies CAs must follow to remain trusted.
Certificate Transparency (CT) adds another layer by making certificate issuance publicly auditable.
Today, certificates are submitted to public CT logs when issued. Domain owners and security teams can then monitor those logs for certificates they did not expect.
Cloudflare has operated its Nimbus family of CT logs since 2016 and is also launching Raio, a new family of static CT logs.
The company says CT monitoring will become particularly important as organizations transition to post-quantum authentication.
If a domain has moved to post-quantum authentication, unexpected issuance of a legacy certificate could potentially provide a downgrade path for clients that still support classical authentication.
The Scaling Problem With Larger Post-Quantum Signatures
The challenge comes from the size of post-quantum signatures.
Cloudflare says that the Web PKI must authenticate roughly one billion TLS servers without requiring every client to preload every server's public key.
Traditional certificate chains distribute this trust through a hierarchy of certificates and signatures.
However, additional mechanisms such as revocation checks and Certificate Transparency have added further cryptographic material to the authentication process.
Cloudflare notes that a typical TLS handshake can involve five signatures and two keys.
According to Cloudflare's estimates, post-quantum signatures are roughly 40 times larger than classical signatures.
The company also estimates that this could increase the amount of data CT logs need to store by 40 times.
These are Cloudflare's estimates, rather than independent measurements presented in the article.
At Internet scale, the resulting overhead would affect multiple parts of the ecosystem, including clients, CAs, transparency logs and monitoring infrastructure.
That creates a need for a different architecture rather than simply replacing one cryptographic algorithm with another.
How Merkle Tree Certificates Work
Merkle Tree Certificates are designed to address this scaling problem by combining issuance and transparency.
The architecture is based on a draft specification being developed by the IETF PLANTS working group.
Instead of creating an individually signed certificate for every entry, a CA places certificate information into an append-only Merkle tree.
The CA can then sign the tree's root or tree head.
A client does not need to validate a large signature attached directly to every certificate. Instead, it can verify a compact inclusion proof, consisting of cryptographic hashes, showing that the certificate exists within the signed tree.
Cloudflare describes the core design principle as:
"don't log what you issue, issue by logging."
The result is that transparency becomes part of the certificate issuance architecture rather than a separate process added afterward.

Cloudflare's New Certificate Authority
Cloudflare says it is building MTC support alongside the infrastructure required for a traditional certificate authority.
That includes certificate issuance systems, facilities, operations and compliance functions.
The company says its approach allows the MTC architecture to be incorporated into the CA from the beginning rather than added later.
The basic responsibilities of the CA remain similar.
It must:
Validate control of a domain
Bind the domain to a public key
Issue certificates
The difference is how transparency and trust are structured.
In the MTC model described by Cloudflare, the CA maintains an issuance log backed by a Merkle tree. The inclusion proof that connects a certificate to the tree becomes an important part of the trust mechanism.
Cloudflare also plans to operate mirroring cosigners.
These systems maintain copies of issuance logs, verify that new log states remain append-only and consistent, and help ensure that the logs remain available to monitors and other participants.
How Cloudflare's MTC Issuance Process Works
Cloudflare plans to use the Automatic Certificate Management Environment (ACME) protocol for certificate requests and issuance workflows.
Its ACME infrastructure will be based on a fork of Boulder, the open-source ACME software used by Let's Encrypt.
Let's Encrypt is also developing MTC support in Boulder, and Cloudflare says it plans to maintain its own fork while contributing upstream changes where possible.
The MTC issuance process described by Cloudflare works as follows.
1. A Website Requests a Certificate
A website requests a certificate through ACME.
The CA verifies that the requester controls the relevant domain.
2. The Certificate Data Enters the Issuance Log
After successful validation, the CA serializes the certificate information and adds it to an append-only issuance log.
3. The CA Updates the Merkle Tree
The CA calculates the updated state of the log and generates a checkpoint representing that state.
The checkpoint effectively attests to the entries included in the Merkle tree up to that point.
4. A Mirroring Cosigner Verifies the Log
The CA sends the updated state and checkpoint to a trusted mirroring cosigner.
The cosigner maintains a durable copy and checks that the new state is correctly formed and consistent with previous states.
5. The Certificate Receives the Required Proofs
After receiving the required cosignature, the CA constructs the MTC containing the certificate information, public key, inclusion proof and relevant cosignatures.
The resulting certificate can then be used by the website for TLS.

Why Mirroring Cosigners Matter
Cloudflare's design gives mirroring cosigners an important role in maintaining confidence in the issuance log.
A cosigner verifies that the CA's log remains append-only and consistent over time.
It also keeps a copy of the issuance log.
This creates another source for monitors and other participants to verify what the CA has issued.
Cloudflare says Chrome's draft Quantum-resistant Root Program policy requires at least two cosignatures:
One from the issuing MTC CA
One from a Chrome-recognized mirroring cosigner operated by a distinct organization
Cloudflare plans to implement its mirroring cosigner in Azul, its open-source Rust-based transparency log, using the c2sp tlog mirror protocol for interoperability.
The company also says it plans to operate mirrors for other pilot CAs.
Landmark-Relative Certificates Reduce TLS Overhead
Cloudflare describes two forms of MTCs:
Standalone MTCs
Landmark-relative MTCs
Standalone MTCs include the relevant cosigned tree head and inclusion proof directly in the certificate.
This makes them self-contained, but the certificate can still carry relatively large post-quantum cryptographic material.
The landmark-relative model is designed to reduce that overhead.
Instead of transmitting the relevant large signatures with every certificate, a CA can designate subtrees covering active certificates as landmarks.
The authenticated landmark information can then be distributed to clients through an out-of-band update mechanism.
During a TLS handshake, the browser verifies that the server's certificate information appears within a trusted subtree.
The inclusion proof connects that certificate to the authenticated landmark.
The server then proves possession of the corresponding private key during the TLS handshake.
This allows the certificate itself to carry a much smaller amount of cryptographic data.
Cloudflare says landmark-relative certificates are particularly important for achieving the efficiency benefits of MTCs at scale.
However, standalone MTCs remain necessary because clients may be newly installed, offline or missing the latest landmark information.
For that reason, Cloudflare says servers should retain a standalone certificate fallback.

Cloudflare's Chrome Experiment
Cloudflare previously tested MTCs in an experimental deployment with Chrome.
For the experiment, the company operated a bootstrap CA, described as a fake CA that stubbed the issuance pipeline.
The experiment served MTCs backed by a traditional certificate chain for selected Cloudflare domains on the company's free plan.
Cloudflare says the MTCs were served to 50% of Chrome Beta 146.
Over the course of the experiment, the company says it successfully served billions of MTCs.
The experiment provided data on both TLS performance and Certificate Transparency scaling.
For the common case, Cloudflare says a landmark-relative certificate required the TLS handshake to transmit:
One public key
One signature
One inclusion proof of less than 1 KB
When a landmark-relative certificate could not be negotiated, the experiment fell back to a traditional certificate chain.
Cloudflare Reported a 9% Median Improvement
Cloudflare reports that, at the median, using a landmark MTC was 9% faster than a classical signature chain during the experiment.
The company notes that most of this performance benefit came from intermediate elision.
There is an important limitation to this result.
The experiment used classical signatures, not post-quantum signatures.
Cloudflare says it therefore expects the performance difference to be greater when using post-quantum signatures, but that expectation is a company projection rather than a result demonstrated by this experiment.
On the Certificate Transparency side, Cloudflare says MTCs also change the scaling model.
The issuance log carries hashes of public keys rather than per-entry signatures, while the tree-head signature covers the log.
The company says this prevents the same certificate from being repeatedly represented across transparency infrastructure in the way that can occur with traditional certificate logging.
From Experiment to Production CA
Cloudflare says the Chrome experiment was completed in August 2026.
The company describes the experiment as successful and says the results, combined with cross-industry work within the IETF PLANTS working group, encouraged it to move toward operating a real CA capable of issuing MTCs.
The next step is broader ecosystem participation.
Several questions remain open, including:
Whether independent monitors can consume and verify MTC issuance logs at production volume
Whether enough CAs and cosigners will emerge to provide ecosystem diversity
How browsers should balance landmark performance benefits with fallback mechanisms
How the broader Web PKI ecosystem will support the architecture at Internet scale
Cloudflare says MTCs have emerged as the authoritative design for post-quantum authentication, but this is the company's characterization of the current direction of the work.
The company also emphasizes that production deployment requires participation from browser vendors, root programs, CAs, mirroring services, monitors and the wider Internet community.
Cloudflare's Planned Role as a Certificate Authority
Cloudflare's move into certificate authority operations adds another responsibility to its existing role in the Web PKI ecosystem.
The company already operates Certificate Transparency infrastructure and monitoring services.
Its new CA initiative brings certificate issuance into the same broader ecosystem.
Cloudflare says its CA will support both classical certificates and MTCs.
The company intends this dual support to provide a transition path between current Web PKI infrastructure and post-quantum authentication.
The CA is targeting early 2027 for potential inclusion in Chrome's Quantum-resistant Root Store.
However, inclusion is not automatic.
Cloudflare says it will need to apply to Chrome's Quantum-resistant Root Store and undergo a rigorous evaluation before its CA can be trusted by browsers to issue MTCs.
Additional details about the final evaluation outcome were not disclosed in the announcement.
What MTCs Could Mean for Certificate Transparency
The MTC architecture changes more than the size of an individual certificate.
It also changes the relationship between issuance and transparency.
In the traditional model, a CA issues a certificate and then submits it to Certificate Transparency logs.
That creates a separate logging layer that has to process certificates repeatedly across the ecosystem.
MTCs instead make the issuance log part of the certificate's trust structure.
The certificate's inclusion in the CA's Merkle tree provides the evidence that the certificate was issued and recorded.
This can reduce the amount of duplicated certificate data that transparency systems need to process.
For post-quantum PKI, that distinction could become increasingly important because larger cryptographic signatures would otherwise increase the storage and processing requirements of transparency systems.
Cloudflare's architecture therefore treats transparency not simply as an audit mechanism, but as a core part of certificate issuance.
The Road Ahead for Post-Quantum PKI
Cloudflare's announcement reflects a broader effort to prepare the Web PKI for cryptographic changes associated with quantum computing.
The technical challenge is not limited to selecting post-quantum algorithms.
A post-quantum Web PKI must also handle certificate issuance, browser validation, transparency, monitoring, log replication and TLS performance at Internet scale.
Merkle Tree Certificates are designed to address several of these requirements through batching and compact inclusion proofs.
Cloudflare's experiment provides one practical data point showing how the approach can work between browsers and servers.
But the company acknowledges that a production Web PKI requires a much larger ecosystem.
Multiple certificate authorities, independent cosigners, browser vendors, root programs and transparency monitors will all have roles to play.
The transition will therefore depend not only on the cryptographic design, but also on how the broader Internet trust ecosystem adopts and operates the architecture.
What Cloudflare Has Announced
The key elements of Cloudflare's announcement are:
Cloudflare is building a certificate authority with MTC issuance support.
The CA is designed around post-quantum Web PKI requirements.
Cloudflare plans to provide standard MTC issuance at no cost.
The company is targeting early 2027 for inclusion in Chrome's Quantum-resistant Root Store.
Cloudflare plans to operate its own MTC mirroring infrastructure.
The mirroring cosigner will use Azul and the c2sp tlog mirror protocol.
Cloudflare's ACME infrastructure will be based on a fork of Boulder.
Cloudflare previously tested MTCs with Chrome.
The Chrome experiment served MTCs to 50% of Chrome Beta 146.
Cloudflare reports billions of MTCs were successfully served during the experiment.
Cloudflare reports a 9% median performance improvement for landmark MTCs compared with a classical signature chain in that experiment.
The experiment used classical signatures, not post-quantum signatures.
Conclusion
The move toward post-quantum Web PKI involves more than replacing existing cryptographic algorithms.
Larger post-quantum signatures introduce scaling challenges across certificates, TLS connections, transparency logs and monitoring systems.
Cloudflare's proposed answer is to make Merkle Tree Certificates a central part of certificate issuance and transparency.
Instead of attaching large signatures to individual certificates, MTCs organize certificate information into an append-only Merkle tree and use compact inclusion proofs to demonstrate that a certificate belongs to an authenticated issuance log.
Cloudflare's Chrome experiment provided an early production-scale test of the concept, with the company reporting billions of MTCs served and a 9% median performance improvement for landmark MTCs compared with a classical signature chain.
The experiment did not use post-quantum signatures, so the company says the potential performance benefit with PQ signatures remains an expectation rather than an experimentally demonstrated result.
The next stage is broader ecosystem testing.
Cloudflare's planned CA will need to go through Chrome's root-store evaluation process, while the wider Web PKI will need multiple CAs, cosigners, monitors and browser implementations to establish the necessary diversity and resilience.
For Cloudflare, the announcement marks a move from experimenting with MTCs to building certificate authority infrastructure around them.
The broader outcome will depend on how the Internet's trust ecosystem adopts, evaluates and operates the technology at production scale.
Source: Cloudflare Blog
About the Author