Java rejects any certificate chain with an ML-DSA signature in it — even under a classical leaf
A fully classical P-256 server certificate was undeployable on Tomcat because the CA that issued it signed with ML-DSA-65. The constraint is on the issuer, not the endpoint, and it reshapes a migration plan.
The objective was to serve TLS from Tomcat with a certificate issued by the book's post-quantum CA, using the standard Java connector. The certificate was deliberately conservative: an EC P-256 key, the most classical thing a server can present. It was not deployable, and the reason is the finding.
java.security.cert.CertPathValidatorException:
Algorithm constraints check failed on signature algorithm: ML-DSA-65
Fatal (HANDSHAKE_FAILURE): No available authentication schemeThe Java secure-socket provider validates the server's own chain before offering it, and it fails that validation on the issuer's signature algorithm. The leaf is classical; the CA signed it with ML-DSA-65; the provider finds no usable certificate and closes the connection before ServerHello. The client sees an unexpected end of file and nothing else. The measurement was made on Tomcat 11.0.24 with Temurin JDK 26, with handshake debugging on, so the refusal is in the provider's own words.
A control test establishes the cause rather than inferring it. Same Tomcat, same JDK, same connector, same port; only the keystore changed, to a self-signed EC pair generated by keytool with no post-quantum signature anywhere:
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Signature type: ecdsa_secp256r1_sha256The ML-DSA-signed issuer is therefore the sole cause. The same successful handshake reported a classical temporary key, X25519, while the OpenSSL client across from it had offered the hybrid group — a second finding on a working connection: Java TLS 1.3 succeeds, with classical key exchange, whatever the client proposes.
The migration consequence is the part that matters to a planner. A classical server certificate is not deployable on Java if a post-quantum CA issued it. During a PKI migration, a Java estate must be served from a classically-signed chain until the provider supports ML-DSA in path validation, and that is a constraint on which CA signs, not on which algorithm the endpoint holds. An enterprise that stands up a post-quantum issuing CA and begins moving servers under it will find its Java tier refusing to start, with no error on the client side — one of the silent breakages the book exists to name. The book's later chapters confirm the boundary from the other direction: the same provider lists ML-DSA among its signature algorithms and offers none of them, names no post-quantum group, and a newer Java changes nothing on the wire. The remedy on Java today is the OpenSSL-backed connector, which the Tomcat chapter builds and measures, and which serves the full CNSA 2.0 profile from an unmodified application server.
In the book: Chapter 11 carries the full transcript, the figures and the runbook. In the apparatus: the fix is in the repository, pinned to the versions that were measured. In your estate: if this is the problem you are looking at, this is what an engagement does about it.