http-pqc-j17: validate certificate chains in the custom trust manager

[jamesnetherton]

Problem

HybridPqcX509TrustManager performed its own certificate checks instead of delegating. Because registering a custom X509TrustManager replaces the one Quarkus builds from the configured truststore — JSSE consults only the trust manager it is given — client authentication was effectively unauthenticated:

• Any self-signed certificate carrying the three Chimera extensions was accepted. CertificatesUtil did cert.verify(cert.getPublicKey()), a self-signature check that establishes nothing, and getAcceptedIssuers() returned an empty array. The truststore configured in application.properties was never consulted.
• Expired certificates were accepted; nothing checked the validity period.
• checkServerTrusted had an empty body — the textbook trust-all trust manager, ready to be copied into an outbound client.
• The ML-DSA-65 signature was computed over the subject DN only, so the PQC extensions could be lifted onto another certificate along with that DN by someone who never held the ML-DSA key.

This matters because the example's whole subject is TLS security, so its trust manager is exactly the code a reader will lift into their own project. I reproduced each of the four points against the running application before changing anything.

Changes

• HybridPqcTrustManagerCustomizer retrieves the trust manager Quarkus built from quarkus.http.ssl.certificate.trust-store-file and passes it to HybridPqcX509TrustManager as a delegate instead of discarding it. Startup fails if no truststore is configured, rather than leaving the PQC check as the only barrier.
• HybridPqcX509TrustManager delegates chain, trust anchor and validity-period validation, then verifies the ML-DSA-65 signature on each certificate in the chain. checkServerTrusted is implemented and getAcceptedIssuers returns the configured anchors. The class Javadoc explains why the ordering matters, since that is the part worth copying.
• CertificatesUtil verifies the alternative signature with the issuer's ML-DSA-65 public key via X509CertificateHolder.isAlternativeSignatureValid, which covers the whole TBSCertificate. Verifying against a key carried by the certificate under test would authenticate nothing.
• HybridCertificateGenerator adds a hybrid CA holding both an RSA and an ML-DSA-65 keypair, and issues the server and client certificates from it, signing each with both keys. The truststores hold the CA. This is what gives the post-quantum signature meaning: an attacker who could forge RSA still could not mint an accepted certificate without the CA's ML-DSA-65 key. BouncyCastle's build(signer, isCritical, altSigner) produces the spec-correct extensions, replacing the hand-rolled version.
• Docs correct the claims about what is validated and what is quantum-safe (the transport remains classical on Java 17 — only the certificate authentication is hybrid), switch curl -k to --cacert, and drop the pinned BouncyCastle version.

The certificates were previously self-signed while declaring Issuer: CN=PQC Hybrid CA, which is the hierarchy PQC-EXPLANATION.adoc already described. The CA makes the code match the documentation rather than the other way round.

Tests

13 → 18 tests. The RSA-only client certificate is now issued by the same CA, so it passes chain validation and the missing ML-DSA-65 signature is the only fault — previously that test could have passed with the PQC check entirely broken. New cases cover an untrusted hybrid certificate, an expired one, one issued by a different CA, one whose issuer publishes no PQC key, and one carrying extensions lifted from another certificate. Cases that chain validation would reject first are unit-tested against CertificatesUtil directly, so they exercise the signature check rather than passing incidentally.

Verification

• mvn clean verify on Java 17: 18/18 tests pass
• mvn clean verify -Dnative (Mandrel 25): native build plus 5 native integration tests pass
• mvn license:check formatter:validate impsort:check clean
• Both curl commands in the README run against a live quarkus:dev server, including the documented failure case

---

Claude Code on behalf of James Netherton

🤖 Generated with Claude Code

[JiriOndrusek]

Two observations about the trust manager for anyone adapting this beyond the demo.

This review covers conventions and security correctness only — it does not replace specialized tools such as CodeRabbit, Sourcery, or SonarCloud.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

[JiriOndrusek]

Observation: X509TrustManager vs X509ExtendedTrustManager

This implements X509TrustManager, not X509ExtendedTrustManager. The extended interface adds 3-arg methods (checkServerTrusted(chain, authType, SSLEngine)) that carry the SSL context needed for endpoint identification (hostname verification).

For this example it is safe:

• Server-side checkClientTrusted does not do hostname verification regardless.
• JSSE's SSLContextImpl.chooseTrustManager() wraps a plain X509TrustManager in AbstractTrustManagerWrapper, which performs endpoint identification after calling the 2-arg method.

However, that safety net does not cover non-standard deployments (e.g. Netty's OpenSSL/tcnative provider, which bypasses SSLContext.init()). If someone adapts this for client-side TLS in such a setup, checkServerTrusted(chain, authType) on the delegate runs without the SSLEngine, so hostname verification is skipped — a valid certificate for evil.com would be accepted when connecting to good.com.

Implementing X509ExtendedTrustManager instead and delegating the 3-arg methods to delegate.checkServerTrusted(chain, authType, engine) before calling validateHybridChain would close this gap for all deployment scenarios.

[jamesnetherton]

Agreed, and fixed in de263d6. The class now extends X509ExtendedTrustManager and delegates all four three-argument overloads to the matching delegate method, so the Socket/SSLEngine reaches the platform trust manager that performs endpoint identification.

HybridPqcTrustManagerCustomizer now also requires the platform trust manager to be an X509ExtendedTrustManager and fails startup otherwise, rather than quietly wrapping one that cannot verify hostnames. Every JDK provider has returned the extended form since Java 7, so failing there means something unusual is in play.

A test asserts the delegation rather than just the outcome: a recording delegate checks that each three-argument overload reaches the corresponding delegate method. Forwarding them to the two-argument method would validate the certificate just as well and pass a naive test while dropping the hostname check.

I also corrected the README, which had claimed hostname verification is lost outright — your point about AbstractTrustManagerWrapper is right, and the text now says so and names the bypass case instead.

Verified with mvn clean verify (21 tests) and mvn clean verify -Dnative (native build plus 5 native integration tests).

---

Claude Code on behalf of James Netherton

[JiriOndrusek]

Observation: DN-only issuer matching

findIssuer matches by X500Principal (the distinguished name) alone. The platform trust manager uses Authority Key Identifier (AKI) / Subject Key Identifier (SKI) for unambiguous issuer resolution, so the PQC layer can diverge from the chain the platform actually validated.

For this example's flat hierarchy (one CA, no intermediates) it is safe.

In a production PKI it breaks under:

• CA key rollover — truststore holds both old and new root CAs with the same DN but different ML-DSA keys. getAcceptedIssuers() returns whichever first; if it picks the wrong one, the PQC check rejects a valid certificate.
• Cross-certified CAs — two CAs sharing a DN, same problem.
• Malicious chain injection — an attacker sends [leaf, rogue-intermediate] where the rogue has the right DN but the wrong alt public key. The platform ignores it (AKI/SKI mismatch), but findIssuer picks it because it matches the DN and appears first.

Using the AKI extension (OID 2.5.29.35) on the certificate under test to match the issuer's SKI would resolve all three.

[jamesnetherton]

Agreed, and fixed in de263d6. findIssuer now resolves in three ordered steps: a candidate whose subject key identifier matches the certificate's authority key identifier, then the certificate itself when it is self-issued, then a candidate matching the issuer name alone for certificates predating the extensions. HybridCertificateGenerator now issues certificates carrying both extensions, which the matching needs. Preferring key-identifier matches also covers your third case — a certificate carrying only the right issuer name can no longer displace the one the platform built the path through.

Working through your key-rollover case turned up something I had missed on the first attempt: the leaf is not the hard part. A self-signed anchor carries no authority key identifier, so nothing distinguishes it from a same-DN sibling — and this example's keystores put the CA in the client's chain, so validateHybridChain checks the CA on every handshake. With a rolled-over CA in the truststore twice, the CA's own ML-DSA-65 signature was verified against the other CA's key. That is what the self-issued step exists for. The regression test sends each certificate both alone and with its CA, and the CA-in-chain assertions fail without it.

One thing worth being precise about: none of this was a bypass. The delegate validates the chain first, so a mis-resolved issuer causes a valid certificate to be rejected, not an invalid one accepted — and a peer only controls its own chain. The value is keeping this layer in step with the path the platform actually built.

Verified with mvn clean verify (21 tests) and mvn clean verify -Dnative (native build plus 5 native integration tests). Each new test was confirmed to fail without its corresponding fix.

---

Claude Code on behalf of James Netherton