Topic starter
24/06/2026 7:37 pm
TL;DR: A simple PQC test server can use ML-DSA for certificate signatures and ML-KEM for key exchange, according to DigiCert’s walkthrough, but only command-line clients currently validate it because mainstream browsers do not yet support ML-DSA certificates. That gap makes PQC readiness a staged migration problem, not a browser toggle.
Editorial analysis by NHI Mgmt Group, based on content published by DigiCert: “How to Build Your Own PQC Test Server”.
Key questions
Q: How should teams pilot post-quantum TLS without breaking existing clients?
A: Start in a controlled environment with non-browser clients that can validate the handshake, then confirm certificate parsing, trust-store behaviour, and fallback handling.
Q: How do you know if PQC readiness is actually working in production?
A: Look for successful negotiation on real services, stable certificate issuance, no unexplained fallback to classical algorithms, and no breakage in automation that depends on signing or TLS.
Q: What breaks when browsers cannot validate quantum-safe certificates?
A: The trust chain breaks at the client boundary even if the server is correctly configured.
Practitioner guidance
- Build a staged PQC validation path Separate lab validation, staging, and production so you can test ML-DSA certificates and ML-KEM key exchange without depending on browser support.
- Inventory client support for PQC trust chains Identify which browsers, command-line tools, automation agents, and service clients can validate quantum-safe certificates today, and mark unsupported consumers as migration blockers.
- Treat certificate authentication and key exchange separately Track readiness for post-quantum signatures and post-quantum key agreement as distinct workstreams, because one can be available before the other in real deployments.
Bottom line: The article shows that quantum-safe TLS can already run in a test server, but the practical limit is client support rather than server capability.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 4:59 am
PQC readiness is now a trust-compatibility problem, not a theory problem. DigiCert’s walkthrough shows that quantum-safe TLS can already be built, but not yet consumed uniformly by mainstream browsers. That means the operational question has shifted from whether PQC exists to which trust anchors, clients, and validation paths can actually use it. For identity and PKI teams, staged interoperability is now the gating control.
A question worth separating out:
Q: Why do certificate teams need a phased PQC migration plan?
A: Because post-quantum signatures, key exchange, and client validation will not all mature at the same pace. A phased plan lets teams prove the server side first, then expand to supported consumers, and only later move browser traffic when ecosystem support catches up. Without that sequencing, organizations can create trust outages while chasing quantum-safe goals.
👉 Read our full editorial: PQC test servers expose the browser gap in quantum-safe TLS