JDK-8189131 : Open-source the Oracle JDK Root Certificates
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-10-10
  • Updated: 2019-05-14
  • Resolved: 2017-12-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10 JDK 8 JDK 9 Other
10 b36Fixed 8-poolResolved 9.0.4Fixed openjdk8u222Fixed
Related Reports
Blocks :  
JDK-8191486 - JEP 319: Root Certificates
Duplicate :  
JDK-8191300 - InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
Relates :  
JDK-8194170 - Few tests fail after JDK-8189131 fix
Relates :  
JDK-8194693 - jdk considers one of its own root certificates insufficiently secure
Relates :  
JDK-8194702 - pkcs12 can be loaded with null password but certificates are missing
Relates :  
JDK-8193447 - Open-source the Oracle JDK Root Certificates (Phase 2)
Sub Tasks
JDK-8189357 :  
Release Note: TLS does not work by default on OpenJDK 9 - Closed
JDK-8193890 :  
Release Note: JEP 319 Root Certificates - Closed
Description
Move the root certificates that are delivered in the cacerts keystore in Oracle's JDK to OpenJDK so that there are no differences. The cacerts keystore in OpenJDK is currently empty and this prevents things like TLS from working out-of-the-box. This is part of the overall effort to make the OpenJDK and Oracle JDK builds the same.

Each CA must must sign the Oracle Contributor Agreement (OCA) or an equivalent agreement that permits Oracle broad open sourcing rights of the roots before the certificates can be included. Those that do not sign an agreement will not be included. Those that take longer to process will be included in the next release (JDK 11). See the JEP (JDK-8191486) for more details.
Comments
Review request sent: http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016557.html
01-12-2017
Is this still expected for jdk 10? The corresponding JEP doesn't seemed to be targeted.
30-11-2017
Here's an example of exception seen if client runs with no trusted certs : ========================================== $ ./jdk-9/bin/java -showversion SSLConnect2 openjdk version "9" OpenJDK Runtime Environment (build 9+181) OpenJDK 64-Bit Server VM (build 9+181, mixed mode) Before handshake Exception in thread "main" javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty at java.base/sun.security.ssl.Alerts.getSSLException(Alerts.java:214) at java.base/sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1969) at java.base/sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1921) at java.base/sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1904) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1436) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413) at SSLConnect2.main(SSLConnect2.java:35) Caused by: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty at java.base/sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:89) at java.base/sun.security.validator.Validator.getInstance(Validator.java:181) at java.base/sun.security.ssl.X509TrustManagerImpl.getValidator(X509TrustManagerImpl.java:330) at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrustedInit(X509TrustManagerImpl.java:180) at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:192) at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:133) at java.base/sun.security.ssl.ClientHandshaker.checkServerCerts(ClientHandshaker.java:1825) at java.base/sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1655) at java.base/sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:260) at java.base/sun.security.ssl.Handshaker.processLoop(Handshaker.java:1086) at java.base/sun.security.ssl.Handshaker.processRecord(Handshaker.java:1020) at java.base/sun.security.ssl.SSLSocketImpl.processInputRecord(SSLSocketImpl.java:1137) at java.base/sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1074) at java.base/sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973) at java.base/sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1402) at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1429) ... 2 more Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty at java.base/java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200) at java.base/java.security.cert.PKIXParameters.<init>(PKIXParameters.java:120) at java.base/java.security.cert.PKIXBuilderParameters.<init>(PKIXBuilderParameters.java:104) at java.base/sun.security.validator.PKIXValidator.<init>(PKIXValidator.java:86) ... 17 more
16-10-2017