🔐 Post-Quantum X.509 Certificate Chain

🎯 What This Is

A complete, working post-quantum X.509 hierarchy you can download and verify yourself. Unlike classical PKI built on RSA or ECDSA — both breakable by Shor's algorithm on a large quantum computer — every signature in it is quantum-resistant:

Why two roots: CNSA 2.0 (NSA FAQ v2.1, December 2024) approves ML-DSA-87 alone for signatures and does not approve SLH-DSA for any use, so the chain a server sends is ML-DSA-87 throughout. A hash-based root still matters: it rests only on the security of SHA-2, so a client that anchors its trust there is not exposed to an advance in lattice cryptanalysis. Cross-certification gives that client a path too — the SLH-DSA root certifies the same issuing CA, and its path runs through that cross-certificate. Public CAs move between roots the same way.

📥 Download the Hierarchy

All certificates are PEM-encoded X.509v3, using the final NIST FIPS 204/205 algorithm identifiers and key encodings:

ML-DSA-87 root SHA-256 fingerprint — confirm it matches after download:

F5:15:81:D7:AD:58:22:3D:6B:8D:A9:FB:3B:19:9B:32:D4:5A:B8:1A:D2:2B:D7:40:1B:2A:FE:2E:22:A5:40:63

SLH-DSA-SHA2-256s root SHA-256 fingerprint — confirm it matches after download:

A7:8A:6E:45:85:63:E0:6D:A5:06:B6:FF:37:AD:6B:91:87:36:2C:E0:00:FE:40:EF:6C:1D:5B:EF:40:D9:10:DC

🔍 Verify Both Paths (OpenSSL 3.5+)

OpenSSL 3.5 and later verify ML-DSA and SLH-DSA signatures natively. Download the certificates and verify the leaf through each root:

for f in cnsa2-root-ca.crt root-ca.crt issuing-ca.crt issuing-ca-cross-slhdsa.crt server.crt; do
    curl -sO https://pqcrypta.com/pqc/$f
done

# The CNSA 2.0 path: ML-DSA-87 root, issuing CA, leaf
openssl verify -CAfile cnsa2-root-ca.crt -untrusted issuing-ca.crt server.crt
# server.crt: OK

# The hash-based path: SLH-DSA root, cross-certificate, leaf
openssl verify -CAfile root-ca.crt -untrusted issuing-ca-cross-slhdsa.crt server.crt
# server.crt: OK

Give openssl verify the issuing-CA certificate that belongs to the root you trust: it takes the first certificate whose name matches and does not try the other, where a full path builder (as browsers use) would. Inspect the algorithms directly:

openssl x509 -in cnsa2-root-ca.crt -noout -text | grep "Signature Algorithm"
#   Signature Algorithm: ML-DSA-87
openssl x509 -in root-ca.crt -noout -text | grep "Signature Algorithm"
#   Signature Algorithm: SLH-DSA-SHA2-256s
openssl x509 -in server.crt -noout -text | grep "Signature Algorithm"
#   Signature Algorithm: ML-DSA-87

🌐 Live Post-Quantum TLS Endpoint

This chain is not just downloadable — it is served live. pqc.pqcrypta.com:443 terminates TLS 1.3 on pqcrypta-proxy (OpenSSL 3.5 over TCP, rustls over HTTP/3) with the ML-DSA-87 chain above: the server signs its CertificateVerify with ML-DSA-87 and sends only ML-DSA-87 certificates. A client configured as the CNSA 2.0 TLS 1.3 profile requires — ML-KEM-1024, TLS_AES_256_GCM_SHA384, ML-DSA-87 — completes a handshake that meets it exactly:

OPENSSL_CONF=/dev/null openssl s_client -connect pqc.pqcrypta.com:443 -tls1_3 \
    -groups MLKEM1024 -ciphersuites TLS_AES_256_GCM_SHA384 -sigalgs mldsa87 \
    -CAfile cnsa2-root-ca.crt -verify_hostname pqc.pqcrypta.com

# Peer signature type: mldsa87
# Negotiated TLS1.3 group: MLKEM1024
# Verify return code: 0 (ok)

To verify through the SLH-DSA root instead, give s_client the root and the cross-certificate together — cat root-ca.crt issuing-ca-cross-slhdsa.crt > slh-dsa-store.pem, then -CAfile slh-dsa-store.pem. OpenSSL 3.5 offers ML-DSA signature schemes by default, so openssl s_client -connect pqc.pqcrypta.com:443 -CAfile cnsa2-root-ca.crt alone completes a post-quantum handshake too (with X25519MLKEM768). With curl linked against OpenSSL 3.5+:

curl https://pqc.pqcrypta.com/pqc/cert-info.json \
    --sigalgs mldsa87 --curves MLKEM1024 --cacert cnsa2-root-ca.crt

The endpoint deliberately refuses clients that do not offer mldsa87 in their signature_algorithms — there is no classical fallback certificate on this hostname (a classical-only client receives a TLS handshake_failure alert). That is why a normal browser visit fails: browsers do not offer ML-DSA signature schemes yet. When they do, this endpoint is already waiting. (pqcrypta.com itself serves both: its Let's Encrypt certificate to browsers and an ML-DSA-87 chain from the same CA to clients that accept only ML-DSA.)

🖥️ Installing a Root in Your Trust Store

Reality check: no mainstream browser can validate ML-DSA or SLH-DSA certificate signatures during a TLS handshake yet — browser post-quantum support today covers key exchange (X25519MLKEM768), not certificates. Installing a root prepares your trust store for post-quantum PKI and lets OS tooling (and the OpenSSL commands above) verify the chain; it will not turn the padlock green on its own. Install the ML-DSA-87 root (cnsa2-root-ca.crt) for the path the server sends; the SLH-DSA root also needs the cross-certificate, which the leaf names in its Authority Information Access field for clients that fetch it.

📜 Certificate Details (Live from the Published Files)

🚀 Live PQC Encryption Demonstration

The certificates above prove post-quantum signatures work in X.509 today. This demo proves post-quantum encryption works in production today — a full generate → encrypt → decrypt round trip against the live PQ Crypta API using ML-KEM-1024 with pure post-quantum signatures:

🔬 Technical Stack

💡 Why Post-Quantum PKI Matters

TLS key exchange is going post-quantum first — hybrid ML-KEM is already deployed by major browsers — because recorded traffic can be decrypted retroactively ("harvest now, decrypt later"). Certificates come next: signatures can't be forged retroactively, but the WebPKI must migrate before quantum computers arrive, and rotating a global trust hierarchy takes years. The families involved:

• Lattice-based: ML-KEM and ML-DSA (FIPS 203/204) — fast, compact, the operational workhorses
• Hash-based: SLH-DSA (FIPS 205) — larger and slower, but resting only on hash function security; a conservative root of trust
• Code-based: Classic McEliece (ISO/IEC 18033-2) and HQC (NIST's backup KEM) — independent mathematical foundations

This hierarchy demonstrates that a complete post-quantum PKI is buildable and verifiable with standard tooling today — one that meets CNSA 2.0 on the wire and still offers a hash-based trust anchor, through cross-certification, to clients that want one.