On Wed, Oct 10, 2018 at 3:10 AM, Weijun Wang <weijun.w...@oracle.com> wrote:
> > > > On Oct 10, 2018, at 1:07 AM, Martin Buchholz <marti...@google.com> > wrote: > > > > Seems alright to this non-crypto expert. > > > > The key thing I would like to see working is: > > > > If I create a keystore for cacerts and then use it via > -with-cacerts-file taking the defaults, this results in goodness (which > presumably means not getting JKS keystore) > > I haven't tried this configure option before, but does it mean just copy > your own file to lib/security/cacerts? > My own mental model of -with-cacerts-file is that it effectively copies the file to replace java.base/share/lib/security/cacerts. Currently, to explore this file you need to know to use JKS and learn about the "well-known" password (where is this documented??) > Then you need to make it correct, i.e. a JKS file, or a password-less > pkcs12 file, or with-password pkcs12 but you set the correct storepass (TLS > system property?). > > > > > Make sure keystore creators don't have to specify a storepass. > > If you want to create a password-less pkcs12 file, you will need to > specify those system properties (certProtectionAlgorithm and macAlgorithm > to NONE). Then I'll make sure there is no need to specify a storepass. > Because we're trying to replace a data file that already comes with the JDK, we'll always prefer to use exactly the same format and password (or lack thereof). If and when openjdk comes with a password-less pkcs12 file, we will switch as well.
