JDK-8162628 : The CACERTS keystore type
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • Submitted: 2016-07-27
  • Updated: 2022-06-03
  • Resolved: 2021-10-13
Related Reports
Blocks :  
Blocks :  
Blocks :  
CSR :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
The built-in collection of trust anchors for a JDK release is the cacerts keystore. It is in JKS format which has some limitations and is proprietary. Investigate migrating to a more standard format.
Comments
cacerts was using JKS which is not a standard and needs a password. This enhancement is one of the explorations we've searched for. Now that we've already used passwordless pkcs12 to store the file, there is no need to do more investigation in this area.
03-06-2022

Withdraw this proposal.
13-10-2021

There has been some discussion about alternatively creating a "PEM" KeyStore for cacerts for lower overhead, and improved performance. See https://mail.openjdk.java.net/pipermail/security-dev/2019-June/020068.html My recommendation: It sounds like it is worth exploring the benefits of a "PEM" Keystore implementation some more, but there is not enough time to do that in JDK 13. Given that, I think we should delay this issue and not push it to JDK 13. I think we want to avoid a case where we end up moving cacerts from JKS to PKCS12 and then changing our minds and moving it to PEM. Let's take the additional release to work out what is the best long-term solution here.
11-06-2019

Workaround before change: -Djavax.net.ssl.trustStorePassword=changeit.
11-01-2018