Cloudflare Announces Post-Quantum Certificate Authority Powered by Merkle Tree Certificates

Cloudflare Announces Post-Quantum Certificate Authority Powered by Merkle Tree Certificates Cloudflare is launching its own certificate authority to issue Merkle Tree Certificates (MTCs) at no cost, targeting inclusion in Chrome's Quantum-resistant Root Store by early 2027 to solve post-quantum scaling and performance bottlenecks. Post-quantum cryptographic signatures are roughly 40 times larger than classical ones, threatening severe performance degradation and ballooning Certificate Transparency log storage by 40 times. Merkle Tree Certificates integrate issuance and transparency logging by batching certificates into an append-only Merkle tree verified via compact inclusion proofs. MTCs support standalone forms with inline proofs and landmark-relative forms that leverage out-of-band updates to eliminate heavyweight signatures from TLS handshakes. A large-scale trial with Chrome Beta 146 demonstrated that landmark-relative MTCs achieved a 9% faster median handshake compared to traditional classical certificate chains. Cloudflare will deploy an ACME stack forked from Boulder, operate mirroring cosigners via Azul, and offer standard MTC issuance for free. Post-Quantum Scaling Challenges in Web PKI Transitioning the Web PKI to post-quantum (PQ) cryptography is complicated by the size of post-quantum signatures, which are roughly 40 times larger than classical signatures. In a standard TLS handshake, multiple signatures and keys are exchanged across certificate chains and Certificate Transparency (CT) workflows. Directly substituting PQ cryptography into the existing architecture would balloon CT log storage requirements by 40 times, creating prohibitive operational overhead for clients, CAs, logs, and monitors. MTC Architecture and Certificate Formats Merkle Tree Certificates address scaling limits under the principle of issuing certificates by logging them into an append-only Merkle tree. Rather than signing every certificate individually, the CA signs the root of the tree, allowing clients to verify certificates using compact inclusion proofs against signed tree heads. MTCs can be served in standalone format containing cosigned tree heads and hash proofs, or in landmark-relative format. The landmark approach distributes trusted subtree metadata out of band, reducing the handshake transmission to a single public key, signature, and an inclusion proof smaller than 1 kB. Issuance Workflow and Mirroring Cosigners Cloudflare's issuance pipeline will run on an ACME infrastructure forked from Let's Encrypt's Boulder software. After validating domain control, the CA enters the certificate data into an append-only log, computes the updated state, and signs a checkpoint. Chrome's draft policy requires at least two cosignatures—one from the issuing CA and one from an independent mirroring cosigner—to confirm append-only consistency and prevent divergent views. Cloudflare is implementing its mirroring cosigner in Azul, an open-source Rust-based transparency log using the tlog mirror protocol. Trial Results and Ecosystem Roadmap During an experiment with Chrome Beta 146, Cloudflare served billions of MTCs and found that landmark-relative certificates yielded a 9% faster median TLS handshake than classical chains, primarily due to intermediate certificate elision. Cloudflare is targeting early 2027 for inclusion in Chrome's Quantum-resistant Root Store, offering standard MTC issuance for free. Broader adoption will depend on resolving ecosystem questions, such as whether independent monitors can process MTC logs at production volume and how clients will balance landmark benefits with fallback mechanisms.

Cloudflare基于默克尔树证书构建后量子证书颁发机构 为了应对后量子（PQ）密码学签名体积过大给Web PKI带来的扩展挑战，Cloudflare宣布将成为支持默克尔树证书（MTC）签发的证书颁发机构（CA），目标在2027年初纳入Chrome抗量子根证书库，并免费提供标准MTC签发。 传统Web PKI直接引入PQ签名会导致体积扩大约40倍，引发证书透明度（CT）存储与握手性能瓶颈。 MTC将签发与日志绑定，CA通过默克尔树对树根签名，客户端利用轻量级包含证明即可完成验证。 MTC分为独立型与地标相对型（landmark-relative），后者可将包含证明控制在1kB以内，大幅降低握手开销。 Cloudflare与Chrome的实测显示，地标相对型MTC握手较传统证书链中位数提速9%，且其CA基础设施将基于Boulder分叉与开源工具Azul构建。 后量子转型的扩展瓶颈与MTC思路 向后量子密码学迁移预计在2029年前完成，但PQ签名体积大约是传统签名的40倍，会令CT日志数据量剧增并严重拖慢握手性能。由IETF PLANTS工作组推进的MTC架构提出“通过记账来签发”（issue by logging）的核心思想，CA无需逐一签署证书，而是将其批量纳入仅追加的默克尔树，仅对树根进行签名，使透明性成为签发的原生属性。 MTC工作机制与系统架构 MTC保留现有的X.509兼容格式，分为独立型与地标相对型两种。在签发流程中，Cloudflare的ACME基础设施采用Let's Encrypt Boulder的分叉版本，验证域名后将条目写入仅追加日志并签署检查点；随后由基于Rust开源项目Azul构建的镜像联签方（Mirroring Cosigner）验证一致性并联合签名。在日常TLS握手中，客户端通过带外获取的地标子树即可用不足1kB的哈希链完成验证。 测试验证与CA落地规划 Cloudflare曾面向50%的Chrome Beta 146用户开展测试，成功提供数十亿张MTC。结果显示地标型MTC使TLS握手中位数性能提升9%，且在后量子签名下预期提速更显著。Cloudflare计划将自营CA纳入Chrome抗量子根证书库，目标时间为2027年初，同时免费提供标准MTC签发服务并呼吁全行业多方参与生态建设。

When you type in an address into a browser, how do you know you’re connecting to the right website? The Web Public Key Infrastructure (Web PKI) is the complex and distributed ecosystem of policies, protocols, and infrastructure operators that helps you trust that you’re not being misdirected to an incorrect or malicious website. In the past few decades, this ecosystem has undergone significant changes. One is the addition of transparency: the now-mandatory requirement that all certificates be logged in public certificate transparency logs. Now it faces another challenge: the imminent arrival of a quantum computer, which has prompted us to upgrade to post-quantum (PQ) cryptography [by 2029](https://blog.cloudflare.com/post-quantum-roadmap/). This transition is not straightforward: simply swapping post-quantum cryptography into certificates at Internet scale would lead to unacceptable performance degradation. This moment calls for a new approach to the Web PKI, one that allows us to treat transparency as a first-party property rather than an add-on, and design a new system that scales post-quantum signatures efficiently. After gaining broad support across the industry, [Merkle Tree Certificates](https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/) (MTCs) have emerged as the path forward. This year, after a successful experimental [deployment with Chrome](https://blog.cloudflare.com/bootstrap-mtc/), Cloudflare is full steam ahead on MTCs. Following today’s announcement that Cloudflare is becoming a [certificate authority (CA)](http://blog.cloudflare.com/cloudflare-certificate-authority), we’re excited to share that this CA will support MTC issuance, targeting early 2027 for inclusion in Chrome’s newly launched [Quantum-resistant Root Store](https://googlechrome.github.io/chromerootprogram/index.html). As part of our mission to help build a better Internet, and following in Cloudflare tradition of offering the strongest available cryptography [for free](https://blog.cloudflare.com/post-quantum-crypto-should-be-free/), we will provide standard MTC issuance at no cost. Having a CA that supports both classical certificate and MTC issuance allows us to default to the most secure authentication method available, providing a painless and performant PQ upgrade path for a large swath of the Internet. To understand how MTCs are changing the game, let's start with some background on how trust works on the web today. On the client side, browsers — in this case, “TLS clients” — maintain root programs, which specify a set of policies that CAs must follow to be trusted. On the server side, CAs are the trusted gatekeepers: they operate certificate issuance infrastructure where they validate domain ownership and attest to the binding of a domain name and a public key that shows ownership of that domain. But how do we check that CAs are following the rules? Enter certificate transparency (CT), which makes certificate issuance publicly auditable. When a CA issues a certificate, it must also submit that certificate to at least two public logs. Cloudflare has operated the [Nimbus](https://blog.cloudflare.com/introducing-certificate-transparency-and-nimbus/) family of CT logs since 2016, and is launching Raio, a new family of [static CT logs](https://blog.cloudflare.com/azul-certificate-transparency-log/), going forward. While the CT ecosystem makes certificates publicly viewable, it doesn't mean they are correctly issued or safe to use. Monitoring helps with this by comparing those log records with what domain owners expected and reporting suspicious activity. Cloudflare launched [Certificate Transparency Monitoring](https://blog.cloudflare.com/introducing-certificate-transparency-monitoring/) in 2019 and recently made it [generally available](https://blog.cloudflare.com/certificate-transparency-monitoring-ga/). We also publish large-scale measurements about certificates on the [Certificate Transparency](https://radar.cloudflare.com/certificate-transparency) page in Radar (formerly known as Merkle Town). As organizations begin upgrading their servers to use PQ authentication, certificate transparency monitoring will take on an even more important role in detecting potential post-quantum downgrades. Domain owners who have upgraded their domains to post-quantum authentication should monitor CT logs for unexpectedly issued legacy certificates to prevent clients from falling back on a malicious downgrade path. Part of the problem with this current system is that transparency was an add-on, causing it to run into scaling issues. Certificates are frequently logged multiple times, in different forms, across multiple logs, requiring monitors to download and process every log to avoid missing an issuance. This can be expensive — making it difficult to encourage a diverse set of log operators at Internet scale. According to our estimates, PQ signatures will balloon the amount of data that CT logs need to store by 40x. This scaling challenge, and subsequent incentive misalignment, is at the heart of the post-quantum scaling problem. We've written extensively about the [challenges of scaling post-quantum cryptography](https://blog.cloudflare.com/bootstrap-mtc/), but in short: to support server authentication at Internet scale, the WebPKI must authenticate roughly a billion TLS servers without preloading every server’s public key into every client. Traditionally, CAs addressed this problem by using certificate chains as a trust-distribution mechanism. But over time, additions like key revocation checks and certificate transparency have added more public keys and signatures — five signatures and two keys in a typical TLS handshake. PQ signatures are roughly 40 times larger than classical ones, creating larger overheads that would be expensive for clients, CAs, logs, and monitors to handle at scale. Enter [Merkle Tree Certificates](https://datatracker.ietf.org/doc/draft-ietf-transcert-merkle-tree-certs) (MTCs), a draft specification from the [IETF PLANTS](https://datatracker.ietf.org/group/plants/about/) working group that describes an architecture for compact, efficient, post-quantum certificates. MTCs batch certificates into an append-only Merkle tree, allowing a CA to sign the root of that tree instead of many individual certificates. This allows browsers or other clients to verify a certificate using a compact inclusion proof — a sequence of cryptographic hashes — against a signed tree head rather than validating each certificate individually. A [key idea](https://datatracker.ietf.org/meeting/124/materials/slides-124-plants-solution-space-and-dispatched-work-00) behind MTCs is "don't log what you issue, issue by logging." By coupling issuance and logging, transparency becomes a requirement for operation, rather than an add-on. We’re building out our capability to issue MTCs as an integral part of our creation of a Cloudflare CA. That means keeping track of new PQ Root Program requirements, and writing an issuance and mirroring software stack at the same time we’re building the facilities, operations, and compliance functions of the traditional CA — no small feat! The upside is that we get to prioritize the requirements and architecture for this new, post-quantum PKI from day one, building our setup in a way that feels right for Cloudflare's values and global network — aiming to be as transparent as possible as we embark on this new journey. Let’s take a look at the architecture updated for MTC: If you compare this to the traditional CA ecosystem, you'll notice that the responsibilities of a CA stay mostly the same: to validate control of a domain, bind it to a public key, and issue certificates. The main difference is that in the MTC ecosystem, instead of signing certificates directly and then logging them, the CA now maintains a transparency log backed by a Merkle tree, where an inclusion proof that the certificate is indeed in the tree serves as the trust anchor. CAs will also operate *Mirroring cosigners* that store a copy of issuance logs, verifying their append-only consistency and ensuring the transparency and availability of these logs for the broader ecosystem. MTCs come in two forms, both of which can be encoded in the X.509 certificate format that client software recognizes today — just with a “funny” signature algorithm. In *standalone* form, the certificate’s signature value contains a cosigned tree head of an issuance log and an inclusion proof (a sequence of hashes) demonstrating that the certificate is contained in that log. If clients are able to obtain the cosigned tree heads out of band (e.g., via a browser update mechanism), the certificate can instead be served in *landmark-relative* form, where the signature value consists of the lightweight inclusion proof with no heavyweight post-quantum signatures at all. For simplicity’s sake, let’s take a look at an example of standalone certificate issuance. When a website wants a certificate for their domain, they can request it from a CA via the Automatic Certificate Management Environment (ACME) protocol, which handles certificate requests, domain-control validation, and issuance workflows. Cloudflare's ACME infrastructure will be a fork of [Boulder](https://github.com/letsencrypt/boulder), the widely deployed and well-tested ACME software that powers Let's Encrypt. Let's Encrypt is actively developing [MTC support](https://letsencrypt.org/2026/06/03/pq-certs) in Boulder, and we plan to maintain our own fork that incorporates these upstream changes along with Cloudflare-specific modifications, contributing back upstream where possible. When the MTC CA receives a certificate issuance request, the CA's ACME server checks that the server actually controls the domain. If those checks pass, the CA serializes that data and adds it to an append-only log. After adding the MTC entry into its issuance log, the CA computes the updated state of the log, and then signs a checkpoint over that state. This checkpoint attests that the CA issued every entry included in the log’s Merkle tree up until that point in time. The CA then sends its updated log state and new checkpoint to a trusted cosigner, which durably stores a copy of the CA's issuance log and checks that each new state is append-only, consistent with the previous tree, and correctly formed. This additional cosignature gives clients and monitors confidence that another trusted party has observed the same log state and verified that the CA is not presenting different views of issuance to different parts of the ecosystem. It also ensures that the issued certificates will be available for monitoring even if the CA issuance log is unavailable. Chrome’s [Quantum-resistant Root Program draft policy](https://googlechrome.github.io/chromerootprogram/cqrp/draft-policy/) mandates at least two cosignatures: one from a Chrome-recognized Mirroring Cosigner operated by a distinct organization, and one from the issuing MTC CA itself. As such, we'll operate mirrors for other pilot CAs — and require at least one independent cosignature on our own issued certificates. Cloudflare will implement our mirroring cosigner in [Azul](https://github.com/cloudflare/azul), our open-source Rust-based transparency log, and for maximal interoperability, it will implement [c2sp's tlog mirror](http://c2sp.org/tlog-mirror) protocol. Finally, after successfully receiving a cosignature from a mirroring cosigner, the CA constructs an MTC with the cosignatures, server's public key, and an inclusion proof. It then sends that MTC to the server, which can then use it for TLS moving forward! While standalone certificates are functional, they still send large PQ signatures over the TLS handshake, limiting their efficiency. The real performance improvements provided by the MTC design are landmark-relative certificates. Instead of sending cosignatures in every certificate, CAs can designate a sequence of subtrees that cover all active certificates in the log as a landmark, and distribute those subtrees (along with data to authenticate them) to clients via an out-of-band update service. During a TLS handshake, the actual authentication to the server happens by the browser checking that the server's certificate data — including its domain name and public key — appears in a trusted subtree of the CA’s log. If the inclusion proof connects that certificate to a cosigned landmark, and the public key then proves possession during the TLS handshake, the client knows it is talking to the right server. Periodically transmitting these signatures and tree metadata to TLS clients out of band, a small set of MTC batch signatures can efficiently cover billions of certificates issued by a given CA. While landmarks are more efficient at scale, they do not eliminate the need for standalone MTCs — clients may be newly installed, offline, or missing the relevant landmark update. That’s why it’s important that servers retain a standalone certificate fallback. This year, we ran an experiment with Chrome to test the feasibility of MTCs between a client and server. We operated a "bootstrap CA" (a fake CA that stubbed the issuance pipeline) that issued MTCs backed by a traditional certificate chain for a selection of Cloudflare domains on Cloudflare's "free" plan and served them to 50% of Chrome Beta 146. Over the course of the experiment we successfully served billions of MTCs. For TLS, we found that the common case is fairly efficient: with a landmark-relative certificate, the handshake only needs to transmit one public key, one signature, and one inclusion proof of less than 1kB. In the experiment, we fell back to the traditional certificate chain instead of serving a standalone certificate in cases where we were unable to negotiate a landmark-relative certificate with the client. On the CT side, MTCs also change the scaling properties of transparency: the log only needs to carry hashes of public keys; there are no per-entry signatures, and the signature on the tree head covers the whole log. This prevents certificate explosion because the CA issuance log is the source of truth for all certificates the CA issues, and log consumers only need to fetch a single copy of each certificate. The result: MTCs really work! At median, using a MTC is 9% faster using landmark MTCs over a classical signature chain (admittedly, most of this performance benefit is due to intermediate elision). And because we tested MTCs with classical signatures, we expect an even greater improvement with post-quantum signatures. Satisfied with these results, and with the level of cross-industry collaboration with MTCs at the [PLANTS WG](https://datatracker.ietf.org/wg/plants/documents/) at the IETF, we began winding down the experiment last month (August 2026). We’re excited that our experiment with Chrome showed that MTCs can work in practice, and are especially excited to be able to issue certificates as a real CA. However, there are still broader questions that we can only answer by running this great experiment with the full PKI ecosystem. Can independent monitors [consume and verify](https://transparency.dev/summit2025/talks/verifiable-indexes.html) MTC issuance logs at production volume? Will multiple CAs and cosigners emerge so that the system has the diversity needed for resilience? How should browsers balance the performance benefits of compact landmark MTCs with the fallback paths needed for clients without fresh landmarks? MTCs have emerged as the authoritative design for post-quantum authentication, but proving it out at production Internet scale will require participation from a diverse set of root programs, browser vendors, CAs, mirrors, monitors, and the wider community. We see the opportunity to participate in this next phase of the Web PKI as an honor, and we take the responsibility of operating CA infrastructure seriously. CAs occupy a privileged position in the trust ecosystem — browsers, domain owners, and everyday people rely on them to validate identities correctly, protect signing keys, follow policy, and operate reliably. Before Cloudflare's CA can be trusted by browsers to issue MTCs, we will need to apply to Chrome's Quantum Resistant root store and undergo a rigorous evaluation process. We welcome that scrutiny, and we expect to hold ourselves to the same high bar as any other CA trusted with helping secure the Internet. We hope other CAs will emerge to support MTC adoption, and we're excited to work with any browser that wants to deploy MTCs.