On Oct 8, 2014, at 23:30, Sean Mullan <[email protected]> wrote:
>>> This enhancement could then be useful for more than just jssecacerts. For >>> example, in my JavaOne presentation, I gave an example of creating a Domain >>> KeyStore that encompasses two root stores: >> >> This means we will need to provide both store type and store path (or config >> file) in the same option. It looks like multiple system properties is good >> at this. > > Good point. > >> >> Or, shall we invent a URI scheme? > > No, that seems like too much work. In your slide, the DKS keystore is loaded by keystore.load(new DomainLoadStoreParameter(uri, Collections.emptyMap()); which means we cannot simply provide two system properties (or two new options) jdk.keytool.cacerts = dks.config jdk.keytool.cacerts.type = dks and write a common code to load it. BTW, I see that DomainKeyStore#load(stream,pass) is designed to load a keystore of JKS (or another default storetype). Why didn't we load a DKS config file (with common passwords or all null)? > In fact, it is plausible we should defer this RFE for now if it is a lot of > work, and we have higher priority things to work on. OK. The bug report already included a workaround. --Max > How common is jssecacerts used anyway? I never really understood why there > was a separate JSSE specific file for ca root certificates, I believe this > may have been an artifact from when JSSE was shipped as a standalone > extension. > > --Sean
