PQC Toolbox

Website PQC checker

Does your website use post-quantum cryptography? Enter its hostname to see which key exchange it negotiates, how its certificate is signed, and whether it accepts older TLS settings.

HTTPS / TCP 443
Check a website
Diagnostic outputPUBLIC HTTPS
Ready for a hostname

Run a check to see the negotiated connection and certificate chain here.

Probe profile
OfferChecks
Modern TLSNegotiated cipher, key exchange and certificate chain
Hybrid-only TLS 1.3Hybrid ML-KEM support
Legacy TLSTLS 1.0, TLS 1.1 and TLS 1.2 static RSA

A website can negotiate hybrid post-quantum key exchange while using a classically signed certificate. The key exchange protects the session secret. The signatures authenticate the website. See where each appears in a TLS handshake.

Test coverage and data retention

The worker resolves the hostname, selects one public IP address and makes five offers on port 443: a modern client, a hybrid-only client, TLS 1.0, TLS 1.1 and selected TLS 1.2 static RSA suites. Each successful observation requires certificate and hostname verification.

A CDN edge and its origin can use different settings. Observations can be reused for three minutes. Finished jobs expire after approximately one hour. You can download the JSON report during that window.

INTERACTIVE SEQUENCE DIAGRAM

Follow a TLS handshake

Read from top to bottom. Each arrow points toward the receiver. Select a message to see what it carries.

Check a hostname above to populate the diagram with its results.

Example flow · Full TLS 1.3 handshake with server authentication.

Algorithm legend Hybrid PQC Post-quantum Classical public-key Symmetric cipher Unclassified

ClientWeb server
  1. Client to server.01 ClientHelloOffer versions, algorithms and a key share

    The client proposes the parameters it can use and usually sends an ephemeral key share so the server can respond in one round trip.

  2. Server to client.02 ServerHelloSelect the connection parameters

    The server chooses the protocol and cipher suite and returns its key share. Both sides can now derive handshake keys.

  3. Server to client.03 EncryptedExtensionsConfirm additional options

    This is the first encrypted handshake message in this flow. It carries negotiated extensions, which can include the application protocol.

  4. Server to client.04 CertificatePresent the server’s identity

    The server supplies its certificate and usually intermediate certificates. The client checks the hostname and builds a chain to a trusted issuer.

  5. Server to client.05 CertificateVerifyProve possession of the private key

    The server signs the handshake transcript. This live signature can use a different algorithm from the issuer signature on the certificate.

  6. Server to client.06 FinishedServer confirms the transcript

    The server authenticates the handshake so far with a value derived from its handshake secret. The client verifies it before trusting the connection.

  7. Client to server.07 FinishedClient confirms the transcript

    The client returns its own verification value. Both parties now have confirmation that their handshake transcripts agree.

  8. Both directions.08 Application DataExchange encrypted records

    HTTP requests and responses travel inside authenticated TLS records. Each direction uses its own traffic key.

Arrows represent protocol messages. Several messages can share one network packet. The worker reports negotiated values and certificates. Message order is illustrated, and the application-data row shows where HTTP would begin.