Your browser has probably been offering post-quantum key exchange for a while. Whether it gets used depends on your server. Here’s how to check yours, and how to turn it on if it’s off.
What it protects
Someone can record your encrypted traffic today and keep it until a quantum computer can break the key exchange. It doesn’t matter that no such computer exists yet. The recording is already made.
X25519MLKEM768 deals with that. It combines classic X25519 with ML-KEM, the algorithm NIST standardized in FIPS 203, so an attacker would have to break both.
It only covers the key exchange. Your certificate stays the same and you don’t need a new one.
Check your server
The quickest way is the free post-quantum check I built for CertAvert (full disclosure: it’s my project). Type a domain and it tells you whether the server accepts it. There’s nothing to sign up for.
Or do it from a terminal. First see which OpenSSL you have:
openssl version
You need 3.5 or newer on the machine you test from. Then offer only the post-quantum group:
openssl s_client -groups X25519MLKEM768 -connect example.com:443 -servername example.com </dev/null 2>&1 | grep -iE "group|alert"
If the server accepts it, you’ll see:
Negotiated TLS1.3 group: X25519MLKEM768
A handshake failure alert means it doesn’t.
On an older OpenSSL the command fails before it connects, whatever the server supports. This is from Debian 12 with OpenSSL 3.0:
group 'X25519MLKEM768' cannot be set
That’s a problem with your machine and says nothing about the site.
What your server needs
Two things: TLS 1.3 and OpenSSL 3.5 or newer. That second one is where most people get stuck, because you can’t get there by editing a config file.
- Debian 13 has OpenSSL 3.5, so you’re fine.
- Debian 12 and Ubuntu 24.04 are on 3.0. The clean fix is upgrading the OS, not building your own OpenSSL.
If your site sits behind Cloudflare or another CDN, visitors connect to the CDN and not to you, so its settings are the ones that count. The check above will show what they get.
Turn it on
With OpenSSL 3.5 this group is on by default, so a server with no curve settings may already accept it after the upgrade. Check first. You only need the lines below if your config sets its own list, or if you’d rather be explicit.
nginx:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;
sudo nginx -t && sudo systemctl reload nginx
Apache:
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLOpenSSLConfCmd Curves X25519MLKEM768:X25519:prime256v1
sudo apachectl configtest && sudo systemctl reload apache2
Keep the classic groups in the list. Older browsers and clients don’t know the new one and need something to fall back to.
Then run the check again.
How many sites have it
On October 29, 2026 I tested the Tranco top 1,000 domains from one location, each with and without www. 655 spoke TLS 1.3, and 522 of those (about 80%) accepted X25519MLKEM768 on at least one of the two. Those are the biggest sites on the internet, though, so don’t assume your own VPS has it. Check.