For most of the last two decades, configuring TLS on a web server meant choosing a certificate, picking a cipher list, and moving on. The key exchange underneath it all, first RSA and then elliptic-curve Diffie-Hellman, was considered settled.
That is no longer true. NIST has finalized its first post-quantum standards, CNSA 2.0 has put dates on the calendar, and browsers and CDNs are already negotiating quantum-resistant key exchange by default. For organizations in regulated environments, the question is shifting from whether to enable PQC in TLS to how to do it without breaking FIPS compliance.
The challenge? Apache HTTP Server and NGINX don’t implement key exchange themselves. Whether your server can negotiate ML-KEM depends entirely on the cryptographic library it was built against.
How Post-Quantum TLS Works in Apache and NGINX
Apache and NGINX are among the most widely deployed pieces of software on the internet. They are commonly used as:
- Public-facing web servers and reverse proxies
- TLS termination points for application tiers
- API gateways and load balancers
- Ingress controllers in containerized environments
Because they terminate TLS for the systems behind them, they are usually the first place a quantum-capable adversary would look. Traffic recorded today can be decrypted later if the key exchange that protected it is broken. This “harvest now, decrypt later” risk is the reason PQC key exchange is the first migration priority, ahead of signatures and certificates.
Both servers delegate that key exchange to OpenSSL through mod_ssl and ngx_http_ssl_module. The server exposes configuration directives; OpenSSL decides what is actually available to negotiate.
The Post-Quantum TLS Readiness Gap
Organizations often assume that a current web server release is “PQC ready.” In practice, several things have to line up:
- The OpenSSL library must implement ML-KEM (FIPS 203) and the hybrid TLS groups that carry it
- The server must be built against that library, not the system OpenSSL
- The server configuration must explicitly offer PQC groups, since defaults vary by version
- Clients must support the same groups, or the handshake silently falls back to classical ECDHE
And for regulated environments, there is a fourth requirement that is easy to overlook: the ML-KEM implementation has to live inside a FIPS 140-3 validated boundary. Enabling PQC with a non-validated library trades one compliance gap for another.
Why Hybrid ML-KEM Key Exchange Matters
Today’s PQC deployments in TLS 1.3 use hybrid key exchange: a classical ECDHE key agreement and an ML-KEM encapsulation are performed together, and the shared secret is derived from both. If either algorithm holds, the session is protected.
The two hybrid groups that matter most in practice are:
- X25519MLKEM768 — the de facto internet default, supported by major browsers and CDNs
- SecP256r1MLKEM768 — pairs ML-KEM-768 with the NIST P-256 curve, which keeps the classical component on an approved curve
Both are supported in CryptoComply Core. Which one you lead with depends on whether interoperability or strict FIPS alignment is the priority for a given endpoint. Offering both, with a classical group as a fallback, covers most client populations.
Using a FIPS 140-3 Validated Cryptographic Library for PQC
The core insight is the same one that applies to FIPS enablement generally: PQC has to be enforced at the cryptographic layer, not bolted onto the application.
SafeLogic’s CryptoComply Core provides:
- A FIPS 140-3 validated cryptographic module with ML-KEM support
- OpenSSL API and ABI compatibility, so Apache and NGINX build without modification
- A single library that satisfies both the FIPS and PQC requirements
SafeLogic’s published use cases for Apache HTTP Server and NGINX walk through linking each server against CryptoComply Core with FIPS mode enabled. The PQC configuration below assumes you have completed those steps and verified that the server reports the CryptoComply Core OpenSSL version rather than the system one.
How to Configure Post-Quantum TLS in Apache
The FIPS use case restricts key exchange to approved curves with SSLOpenSSLConfCmd Curves P-256:P-384. Enabling PQC is a matter of replacing that directive with a group list that leads with hybrid ML-KEM and retains a classical fallback:
<VirtualHost _default_:443>
ServerName www.example.com:443
SSLEngine on
SSLProtocol -all +TLSv1.3
SSLCertificateFile “/opt/apache/conf/server-ecdsa.crt”
SSLCertificateKeyFile “/opt/apache/conf/server-ecdsa.key”
# Hybrid post-quantum key exchange first, classical fallback last
SSLOpenSSLConfCmd Groups X25519MLKEM768:SecP256r1MLKEM768:P-256:P-384
</VirtualHost>
Groups is the OpenSSL 3.x name for what older configurations called Curves. Order matters: the server prefers groups from left to right, and the client’s first key share that matches is what gets used.
How to Configure Post-Quantum TLS in NGINX
NGINX exposes the same OpenSSL setting through ssl_ecdh_curve. Despite the name, the directive accepts any TLS group the underlying library supports:
server {
listen 443 ssl;
http2 on;
server_name www.example.com;
ssl_protocols TLSv1.3;
ssl_certificate /usr/local/nginx/conf/server-ecdsa.crt;
ssl_certificate_key /usr/local/nginx/conf/server-ecdsa.key;
# Hybrid post-quantum key exchange first, classical fallback last
ssl_ecdh_curve X25519MLKEM768:SecP256r1MLKEM768:prime256v1:secp384r1;
}
Note the naming difference: NGINX and OpenSSL use prime256v1 and secp384r1 for the classical curves where Apache accepts P-256 and P-384.
How to Verify an ML-KEM TLS Handshake
Configuration is not proof. Confirm what the server is actually negotiating using the openssl binary shipped with CryptoComply Core:
openssl s_client -connect localhost:443 -tls1_3 -groups X25519MLKEM768 </dev/null 2>&1 \
| grep -E “Negotiated TLS1.3 group|Protocol|Cipher”
A successful handshake reports Negotiated TLS1.3 group: X25519MLKEM768. Repeat the check with -groups P-256 to confirm the classical fallback still works for older clients, and with a group you did not configure to confirm the server rejects it.
For ongoing assurance, the TLS cipher-testing utilities included in the use case packages can be added to a CI pipeline so that a build regression or a configuration drift is caught before it reaches production.
What Post-Quantum TLS Means for Certificates
The configuration above changes key exchange only. Your server certificate remains ECDSA or RSA, and that is the correct sequencing. ML-DSA (FIPS 204) certificates require CA support, client support, and PKI changes that most organizations are not ready for, and the “harvest now, decrypt later” threat does not apply to signatures in the same way.
That said, certificate migration is coming. Choosing a cryptographic library that already carries validated ML-DSA implementations means the next step will be a configuration change rather than another rebuild.
A Practical Path to Post-Quantum TLS Migration
Rather than waiting for a mandate or attempting a wholesale overhaul, organizations can:
- Build Apache or NGINX against a FIPS 140-3 validated library that includes ML-KEM
- Enable hybrid key exchange groups with a classical fallback
- Verify the negotiated group in staging and monitor it in production
- Plan for PQC certificates on the same validated foundation
This sequence delivers quantum-resistant protection for data in transit today while keeping the FIPS boundary intact.
Building a FIPS-Compliant Post-Quantum TLS Strategy
Apache and NGINX are the front door to most application stacks, and they inherit their post-quantum readiness directly from the OpenSSL library they are built against. Enabling PQC in TLS is not a server upgrade; it is a cryptographic library decision followed by a small, deliberate configuration change.
With CryptoComply Core, organizations can meet FIPS 140-3 requirements and begin the post-quantum transition with the same build, using the Apache and NGINX use cases as the starting point.
Ready to Bring Post-Quantum TLS Into Production?
If you’re evaluating Apache or NGINX for post-quantum TLS, SafeLogic can help you determine whether your current cryptographic stack supports ML-KEM, FIPS 140-3 requirements, and the operating environments you need.
