Temporary ML-DSA PKI
OpenSSL created an ML-DSA-44 test CA plus ML-DSA-44 server and client certificates inside a temporary directory.
Post-quantum testing
The gateway passed its first post-quantum readiness test.
Without replacing the current certificates or changing the production configuration, C=US exercised the real local mTLS gateway with temporary ML-DSA-44 identities and the hybrid X25519MLKEM768 key-exchange group.
Readiness test: passedThe gateway accepted the post-quantum client certificate and applied its existing directory certificate-binding rule.
Regression suite: 22 passedThe existing classical mTLS and identity-classification tests continued to pass.
What was run
A disposable test path around the unchanged gateway
Real gateway policy
The existing Python gateway ran on an ephemeral local port, verified the client chain, and bound its fingerprint to a synthetic directory entry.
Hybrid key agreement
A separate OpenSSL probe constrained the TLS 1.3 connection to X25519MLKEM768 and recorded the negotiated group and ML-DSA signatures.
Measured output
What the tools reported
Python runtime: 3.14.7
Python TLS library: OpenSSL 3.5.7
Certificate algorithm: ML-DSA-44 (CA, server and client)
Protocol: TLSv1.3
Cipher suite: TLS_AES_256_GCM_SHA384
Client signature type: mldsa44
Server signature type: mldsa44
Negotiated TLS 1.3 group: X25519MLKEM768
Certificate verification: OK
Gateway /identity result: HTTP 200; certificate-binding rule applied
PQ readiness test: 1 passed
Existing gateway tests: 22 passed
The OpenSSL negotiation transcript and the gateway application response come from two connections created by the same automated test. One connection verifies the application-level identity decision; the other records the explicitly constrained hybrid group.
Interpretation
Capability demonstrated; migration not completed
| Question | Measured answer | Boundary |
|---|---|---|
| Can the local gateway load and verify ML-DSA certificates? | Yes, in this test. | Temporary software keys and a test CA were used. |
| Can its TLS stack negotiate hybrid ML-KEM? | Yes. The probe negotiated X25519MLKEM768. | This proves the local OpenSSL-backed path, not every client, proxy, or hosted edge. |
| Did the certificate-binding parser still work? | Yes. The gateway returned the registered synthetic agent. | The test does not establish production security, interoperability, or certification. |
| Are today’s C=US credentials now post-quantum? | No. | The current Cloudflare-issued client certificate and YubiKey PIV identity remain classical. |
| Does this prove Cloudflare API Shield accepts ML-DSA client certificates? | No. | Cloudflare documents hybrid post-quantum key agreement at its edge, but this local test does not change or validate its client-certificate authentication service. |
Why this came first
A test is reversible; a credential migration is not
The first change deliberately created no production dependency on new algorithms. It did not replace a trust anchor, reissue an agent certificate, change a Cloudflare setting, or move a private key. Runtimes without the required algorithms skip the developer test with an explicit reason; the dedicated CI job treats missing post-quantum support as a failure.
Next safe step: keep classical identity active while testing a parallel ML-DSA credential path with a post-quantum-capable key service or HSM. The current YubiKey PIV slot cannot be assumed to hold ML-DSA keys.
Reproduction and attribution
Evidence that can be rerun
The test is stored as security/mtls/test_pq_readiness.py. On the tested Windows host it runs with:
$env:OPENSSL='C:\Program Files\OpenSSL-Win64\bin\openssl.exe'
$env:REQUIRE_PQ_READINESS='1'
py -3.14 -m unittest security/mtls/test_pq_readiness.py -v
Codex (OpenAI) generated the test, CI integration, this report, and the explanatory interpretation at the operator’s request. Python’s ssl module and OpenSSL produced the substantive cryptographic and handshake results shown above. No Claude comparison was used. The result is measured development evidence; claims about future production migration remain engineering proposals rather than student findings or certifications.
Standards and product context
Primary references
- NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM).
- NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA).
- OpenSSL 3.5 ML-DSA documentation.
- Cloudflare post-quantum support by product and connection.