Post-Quantum (PQC) TLS Readiness Checker
-
Enter a hostname, a URL, or
host:port. - Hosts must be publicly reachable.
- Limit: 10 checks per hour per visitor. Need more? Create a free account.
What is post-quantum TLS?
Post-quantum TLS uses post-quantum cryptography (PQC) to help protect HTTPS and other encrypted connections from future quantum computers. Someone could record encrypted traffic today and decrypt it years later with a powerful enough quantum computer: "harvest now, decrypt later."
Protection starts with the key exchange: how a browser and server agree on encryption keys. A hybrid key
exchange such as X25519MLKEM768 combines the existing X25519 method with ML-KEM, the
quantum-resistant algorithm standardized from Kyber (CRYSTALS-Kyber). Both the browser and server need
to support it.
Is TLS 1.3 quantum safe?
Not by itself. TLS 1.3 can still use classical key exchange, such as X25519 or P-256, which a powerful enough
quantum computer could break. Both ends must negotiate a post-quantum option such as
X25519MLKEM768 to protect against future decryption. Use the checker above to test your server.
What this tool checks
The checker runs several TLS handshakes to test what your server actually supports:
- Post-quantum key exchange.
X25519MLKEM768,SecP256r1MLKEM768,SecP384r1MLKEM1024and pureML-KEM-768are tested separately to identify supported groups. - Whether browsers actually get it. A Chrome-like handshake offers both post-quantum and classical options. A server that supports post-quantum key exchange but chooses a classical group still leaves those connections unprotected against quantum attacks.
- TLS 1.2 exposure. Whether clients can still connect over TLS 1.2, leaving a path without post-quantum key exchange.
- Forward secrecy on TLS 1.2. Whether the server falls back to static RSA key exchange, which exposes every recorded session if the private key is ever recovered.
- Legacy protocols. Whether the server accepts TLS 1.0 or 1.1. Both are deprecated and lack post-quantum protection.
- Certificate authentication. Whether the server certificate and its chain use classical keys (RSA, ECDSA, EdDSA) or post-quantum ones (ML-DSA, SLH-DSA, or composite ML-DSA drafts).
- Encryption strength. Which encryption algorithm the server picks when AES-256-GCM is offered first. AES-256 provides a larger security margin against quantum attacks.
Results include a readiness verdict, recommended changes, and details of each handshake.
How to enable post-quantum key exchange
Enable TLS 1.3 and upgrade your server's TLS library if needed. Then check its key exchange settings.
- OpenSSL 3.5+ enables
X25519MLKEM768by default. Services using it (nginx, Apache, HAProxy, Node.js, Python) may override that default. To set group preference:- nginx:
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1; - Apache:
SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:P-256 - HAProxy:
curves X25519MLKEM768:X25519:P-256
- nginx:
- Go 1.24+ and Caddy 2.10+ enable
X25519MLKEM768by default. Custom settings can override this. - Cloudflare supports it at the edge. For any CDN, check the origin separately if the CDN connects to it over TLS.
- Windows / IIS depends on SChannel in the Windows build you run. Check the release notes for your version for ML-KEM support before assuming it is on.
After enabling it, re-run this check. If the server negotiates X25519MLKEM768 when it is offered alone
but not in the browser-like handshake, move it to the front of the server's group preference list.
Do I need a post-quantum certificate?
Not for post-quantum key exchange. Your existing SSL/TLS certificate still works. Post-quantum certificates address a separate risk: a future quantum computer impersonating your server. The checker reports a classical certificate as information, not a warning.
Moving to post-quantum certificates will mean finding, reissuing, and deploying them. CertKit's certificate discovery and monitoring keep your inventory ready.