Skip to content
pqdoctor

Verify by hand

Every pqdoctor report ends with a command that checks the same thing with standard tools. Use it to confirm a verdict, or after applying a fix.

Key exchange, with OpenSSL 3.5+

Section titled “Key exchange, with OpenSSL 3.5+”

Offer only X25519MLKEM768. A post-quantum server completes the handshake with it. Any other server fails.

Terminal window
openssl s_client -connect example.com:443 -servername example.com -groups X25519MLKEM768 </dev/null 2>&1 | grep -i 'group'
  • Post-quantum: the output names the negotiated group, X25519MLKEM768.
  • Not post-quantum: the handshake fails, typically with a handshake failure alert.

This needs OpenSSL 3.5 or newer (openssl version), the first release with ML-KEM. Older OpenSSL doesn’t know the group and refuses to run.

For mail, add -starttls smtp, imap or pop3. For an IP address, leave out -servername. pqdoctor’s report already prints the right variant.

TLS 1.2 only

Section titled “TLS 1.2 only”
Terminal window
openssl s_client -connect example.com:443 -tls1_3 </dev/null

A TLS 1.2-only server answers with a protocol_version alert.

Is this how pqdoctor was checked?

Section titled “Is this how pqdoctor was checked?”

Yes. The accuracy checks used exactly this test, through Node 24’s OpenSSL 3.5.5: a completed PQ-only handshake proves support. pqdoctor agreed 59 / 59 on real sites where OpenSSL gave a definite answer.

One caution from that work: OpenSSL counts any later alert as a failure. receptivity.io picked X25519MLKEM768 in its ServerHello, then failed later on an SNI problem, so the plain OpenSSL test said “no” while the key exchange was in fact post-quantum. If OpenSSL fails, look at where.

ML-DSA, with OpenSSL 3.5+

Section titled “ML-DSA, with OpenSSL 3.5+”
Terminal window
openssl s_client -connect origin.example.com:443 -sigalgs mldsa44 -brief </dev/null

A server with an ML-DSA-44 certificate completes and prints Signature type: mldsa44. One without it fails.

SSH, with OpenSSH

Section titled “SSH, with OpenSSH”
Terminal window
ssh -vv -o BatchMode=yes -o StrictHostKeyChecking=yes -o UserKnownHostsFile=/dev/null -o GlobalKnownHostsFile=/dev/null github.com 2>&1 | grep -E 'kex: algorithm|KEX algorithms'

With no known host keys, ssh stops right after the key exchange, before offering any key, so it can’t log in. Look for kex: algorithm: mlkem768x25519-sha256. This needs an OpenSSH client with that method: 9.9 or newer.