Cloudflare origin PQC: ML-DSA-44, OpenSSL 3.5.0

Run openssl genpkey -algorithm mldsa44 on a stock Ubuntu 24.04 box and it fails. Unknown algorithm, because that release ships OpenSSL 3.0 and this wants 3.5.0. One command, and you already know most of what Cloudflare's 29 July post means for you: post-quantum authentication between Cloudflare and your origin server is live, on Authenticated Origin Pulls and Custom Origin Trust Store, using ML-DSA certificates you issue yourself from a CA you run. No public certificate authority anywhere in it. The cryptography has shipped. The tooling mostly has. The piece that turns this from a project into a version bump, native ML-DSA in Go 1.27, lands next month. So the real question is whether this is a this-quarter job or a line in the backlog, and that depends on things the announcement does not lead with.

The half of the path nobody looks at

Most post-quantum coverage is about browsers. Harvest now, decrypt later, the padlock, your certificate chain. Fine. But when a visitor hits a site behind Cloudflare there are two TLS connections, and the second one, edge to origin, is the one your team actually controls and the one that carries the same plaintext.

That leg has had post-quantum encryption since 2023. Authenticity is what just landed.

Image: Cloudflare, from the 29 July 2026 announcement by Luke Valenta and Kevin Guthrie.

Cloudflare frames it as the first milestone on a stated path to full post-quantum security by 2029, and the reasoning for why this leg went first is more interesting than the milestone. On the origin connection Cloudflare is the client, not the server. It pools connections, so the cost of a fat drop-in signature gets amortised across a lot of requests. And there is already a trust relationship, your account, which means the whole thing can run on a custom PKI instead of queuing behind the WebPKI. That is why ML-DSA to origin arrived years before ML-DSA in your browser. We went through why ML-DSA is the signature the industry keeps landing on in post-quantum TLS and the case for shipping ML-DSA, and the size trade-off there is the same one being amortised here.

What you actually configure

Two products, and they solve opposite directions of the same handshake.

Custom Origin Trust Store is Cloudflare verifying you. It replaces the default set of publicly trusted CAs for your zone with CAs you control, and it now accepts ML-DSA CAs, so Cloudflare will trust an origin certificate chaining to yours. It needs Full (strict) mode and Advanced Certificate Manager.

Authenticated Origin Pulls is you verifying Cloudflare. Cloudflare presents a client certificate to your origin so you can reject anything that did not come through the network, and the per-zone and per-hostname levels now take ML-DSA certificates and keys. AOP is free on all plans. Run both and you have mutual TLS that is post-quantum in both directions.

The generation step is where people will get stuck, and it is worth reading carefully before you start.

Two gotchas in that sequence, both documented and both easy to hit. The private key has to be in the FIPS 204 seed-only encoding, and Cloudflare’s upload endpoints reject the expanded-key format outright. And you cannot verify the real handshake from outside, because it happens server to server. You test each side separately, then confirm by logging the client certificate serial on the origin. In NGINX that is a one-line log_format with $ssl_client_serial, and a request through Cloudflare should show the serial of the certificate you uploaded.

The parts the headline skips

Here is the honest read, and it cuts both ways.

The downgrade line is the one I would put in front of whoever signs off. Uploading a CA to COTS wipes the default trust store for that zone. Leave a classical CA trusted alongside your shiny ML-DSA one and an attacker who can forge classical credentials still walks straight in, which means a partial migration here is much closer to worthless than to half done. Cloudflare says it plainly in the config guide. It is the kind of thing that gets skimmed.

There is also a small confession in the post that I found more useful than the feature itself. Pingora Origin, the service handling Cloudflare’s origin-bound traffic, had not updated BoringSSL in four years. They ran an internal fork instead, because BoringSSL had been quiet enough to make that look safe. Taking four years of commits at once brought in stricter KeyUsage enforcement, which is correct per the specifications and promptly invalidated a small number of customer certificates, causing an incident on 10 June 2026. Rolled back, patched to keep tolerating RSA certificates with technically invalid KeyUsage, then shipped.

Anyone who has deferred a dependency bump on something stable knows that shape. The bill arrives all at once.

Should you do this now

Depends entirely on your origin’s TLS library.

If you terminate on NGINX with OpenSSL 3.5.0 or later, this is a contained afternoon: generate two chains, upload, flip SSL mode to Full (strict), add ssl_verify_client on, then read your logs. If you are on a distribution OpenSSL, budget for that upgrade first and treat it as the actual work. If your origin is a Go service, waiting for Go 1.27 in August is the sane call, because after that it genuinely is a version bump plus a certificate.

Worth being clear about the threat model, though. This defends against an attacker who can forge classical credentials with a quantum computer, which nobody can do today. Cloudflare’s own stated reason for moving authentication up the queue is that recent progress in quantum computing and cryptanalysis pulled the timelines forward. That is a judgement call about the future, not a live incident, and it is fair to plan it as a 2027 deliverable rather than a Friday emergency. What I would not do is nothing at all, because the OpenSSL and Go version floors mean the prerequisite work has a long lead time even when the config change is small.

If you just want to see what your current certificate chain is signed with before any of this, our SSL certificate checker reads it back without an install. And if TLS 1.3 is still on your to-do list, that is the harder prerequisite here, since ML-DSA to origin assumes it: TLS 1.2 versus TLS 1.3 covers what changes.

Sources

Cloudflare’s announcement, Post-quantum authentication to origins is now supported (29 July 2026), by Luke Valenta and Kevin Guthrie. The configuration reference, Post-quantum between Cloudflare and origin servers, in the Cloudflare SSL/TLS developer docs. The original ship note, Post-quantum ML-DSA certificates for Authenticated Origin Pulls and Custom Origin Trust Store (17 June 2026), which is where the capability quietly appeared six weeks before the blog post explained it.

Frequently asked questions