Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.
PKIX vs SunX509
PKIX is not the default KeyManagerFactory algorithm in OpenJDK, and both Semeru and Liberty intentionally align with upstream behaviour. SunX509 remains the default—even in FIPS mode—unless explicitly overridden.
PKIX executes the full RFC 5280 path validation logic, which includes extended policy evaluation and CRL/OCSP behaviour. NIST’s PKITS test suite illustrates the complexity of PKIX‑compliant validation paths. [docs.oracle.com]
In contrast:
These differences might explain the benchmark results showing that PKIX can introduce a noticeable performance overhead (~2× in some scenarios) mentioned in this PR. The upstream references above document the underlying algorithmic differences even though OpenJDK does not provide explicit benchmarks.
Because workload characteristics vary (e.g., chain depth, CRL usage, handshake rate), organisations should validate PKIX behaviour in their environments before adopting it.
Enabling FIPS 140-3 in Liberty inserts the FIPS‑validated crypto providers but does not modify OpenJDK’s default TrustManagerFactory (PKIX) or KeyManagerFactory (SunX509) algorithms. This aligns with both Semeru’s and upstream OpenJDK’s design. If PKIX is desired for KeyManager, it can be easily configured via the property ssl.KeyManagerFactory.algorithm=PKIX in the file java.security.
Copy