Configuring Post-Quantum Authentication for Cloudflare Origin Connections

Introduction to Origin-Level Post-Quantum Authentication

While early post-quantum migration focused primarily on encryption to mitigate harvest-now/decrypt-later risks, advancing quantum cryptanalysis timelines necessitate an immediate shift toward post-quantum authentication. Attackers equipped with future quantum computers will be able to break classical credentials, rendering impersonation attacks a severe threat to public and private web infrastructure. Cloudflare has reached a significant milestone by introducing post-quantum authentication support for connections between its edge network and customer origin servers.

This capability is available through two core products: Authenticated Origin Pulls (AOP) and the Custom Origin Trust Store (COTS). By utilizing the Module-Lattice-Based Digital Signature Algorithm (ML-DSA), organizations can now build fully post-quantum secure, mutually authenticated Transport Layer Security (mTLS) connections to their backends well ahead of full WebPKI ecosystem readiness.

Understanding the Cloudflare-to-Origin Architecture

Securing a proxied website involves two distinct legs: the visitor-to-Cloudflare connection and the Cloudflare-to-origin connection. While visitor-facing connections rely on massive public trust roots and face strict constraints within the public key infrastructure, the origin connection offers unique operational advantages that simplify post-quantum rollouts.

For the origin leg, Cloudflare acts as the client. This dynamic enables connection pooling, allowing Cloudflare to fan in millions of global visitor requests onto a smaller, highly optimized set of persistent connections to the backend server. Consequently, the performance overhead of drop-in post-quantum signature sizes is easily amortized. Furthermore, because a pre-existing cryptographic trust relationship already exists via the customer’s account configuration, administrators can bypass the intermediate certificate overhead and Certificate Transparency requirements inherent to the public WebPKI.

Custom Origin Trust Store Implementation

When Cloudflare establishes a TLS connection to an origin running under Full (strict) SSL mode, it validates the backend server certificate against an internal trust store. The Custom Origin Trust Store (COTS) feature, which requires Advanced Certificate Manager, permits administrators to replace default public Certificate Authorities with custom, user-managed CAs.

COTS now natively accepts ML-DSA-based CAs. When configured, Cloudflare evaluates origin certificates against this custom hierarchy, ensuring that verification relies purely on post-quantum signatures. To achieve genuine security, administrators must completely strip out quantum-vulnerable CAs from this trust store to eliminate downgrade attack vectors where an on-path adversary could force a fallback to classical RSA or ECDSA schemes.

Authenticated Origin Pulls and mTLS Configuration

Authenticated Origin Pulls (AOP) ensure that origin servers exclusively accept traffic originating from Cloudflare’s verified infrastructure by demanding a client certificate during the TLS handshake. AOP operates across global, per-zone, and per-hostname levels, with zone-level and per-hostname configurations now fully supporting ML-DSA client certificates and private keys.

By supplying an ML-DSA seed-format private key and matching certificate via the Cloudflare API, the edge proxy presents this post-quantum credential to the origin server. When paired with COTS, this establishes a completely post-quantum secure mTLS tunnel, guaranteeing that neither the server’s identity nor the client’s identity can be impersonated using classical mathematical attacks.

Generating ML-DSA Certificates via OpenSSL

Deploying post-quantum origin authentication requires a modern cryptographic toolchain. Using OpenSSL 3.5.0 or later, administrators must generate keys utilizing the FIPS 204 seed-only encoding format, which is currently the only layout accepted by the Cloudflare ingestion pipeline.

The following example demonstrates generating an ML-DSA-44 Certificate Authority and a corresponding server certificate for COTS:

# Create a private ML-DSA-44 CA for the origin server
openssl genpkey -algorithm mldsa44 
  -provparam ml-dsa.output_formats=seed-only 
  -out origin-ca.key

openssl req -new -x509 -key origin-ca.key 
  -out origin-ca.crt -days 10950 
  -subj "/CN=Origin Server CA"

# Create the origin server certificate
openssl genpkey -algorithm mldsa44 
  -provparam ml-dsa.output_formats=seed-only 
  -out origin-server.key

openssl req -new -key origin-server.key 
  -out origin-server.csr 
  -subj "/CN=origin.example.com"

openssl x509 -req -in origin-server.csr 
  -CA origin-ca.crt -CAkey origin-ca.key -CAcreateserial 
  -out origin-server.crt -days 5475 
  -extfile <(printf "basicConstraints=CA:FALSEnkeyUsage=digitalSignaturensubjectAltName=DNS:origin.example.comn")

A similar certificate generation process is required to create the client certificate chain utilized by Authenticated Origin Pulls, ensuring both endpoints rely exclusively on FIPS 204 compliant parameter sets such as ML-DSA-44, ML-DSA-65, or ML-DSA-87.

API Integration and Cloudflare Configuration

Once the post-quantum keys and certificates are generated, they must be provisioned to your Cloudflare zone programmatically using the API. First, upload the custom origin trust store CA:

CA_CERT=$(jq -Rs . < origin-ca.crt)
curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/acm/custom_trust_store" 
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" 
  --header "Content-Type: application/json" 
  --json "{"certificate": $CA_CERT}"

Next, configure zone-level Authenticated Origin Pulls by uploading the client certificate and private key pair, followed by enabling the feature flag:

CERT=$(jq -Rs . < aop-client.crt)
KEY=$(jq -Rs . < aop-client.key)

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/origin_tls_client_auth" 
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" 
  --header "Content-Type: application/json" 
  --json "{"certificate": $CERT, "private_key": $KEY}"

curl -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/origin_tls_client_auth/settings" 
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" 
  --header "Content-Type: application/json" 
  --json '{"enabled": true}'

Backend Server Configuration and Validation

To successfully terminate these connections on your backend infrastructure (such as NGINX), the web server must be explicitly configured to load the ML-DSA certificate and enforce client certificate verification:

server {
    listen 443 ssl;
    ssl_certificate /etc/ssl/origin-server.crt;
    ssl_certificate_key /etc/ssl/origin-server.key;
    ssl_client_certificate /etc/ssl/aop-ca.crt;
    ssl_verify_client on;
    ssl_protocols TLSv1.3;
}

Because the handshake occurs over server-to-server links, testing requires checking components independently. You can verify origin trust store configurations directly via OpenSSL using openssl s_client -connect <ORIGIN_IP>:443 -brief and looking for Signature type: mldsa44 in the output. For AOP validation, inspecting origin server logs for the expected client certificate serial number confirms that Cloudflare is actively presenting the post-quantum credential.

Engineering Challenges and Ecosystem Limitations

Building production-ready post-quantum authentication required overcoming several engineering hurdles across both control and data planes. Because Cloudflare’s control plane services are written in Go, and Go’s standard X.509 and TLS libraries lacked native ML-DSA support at inception, engineers patched functionality directly into Cloudflare’s CIRCL cryptographic library while awaiting upstream language releases.

On the data plane, origin-bound connections are managed via Pingora Origin, which relies on BoringSSL. While upgrading BoringSSL introduced native post-quantum signature verification, it also exposed strict adherence to RFC KeyUsage specifications. Because many legacy origin certificates lacked explicit digital signature flags, strict enforcement caused transient validation errors until fallback patches were deployed. Organizations adopting post-quantum cryptography must strictly audit their certificate extensions to avoid unexpected handshake failures during policy enforcement updates.

Primary reference: Review the original announcement for exact release details. This article is an independent explanation and does not reproduce the source text.