[tls] On 8059818 Keytool does not recognize jssecacerts for -trustcacerts command line option

[Vincent Ryan]

On 10 Oct 2014, at 09:43, Wang Weijun <weijun.wang at oracle.com> wrote:

> 
> On Oct 8, 2014, at 23:30, Sean Mullan <sean.mullan at oracle.com> 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)?

The DKS implementation supports the common use case of loading a single keystore from a file to aid compatibility with existing
keystore applications and existing keystores.

Although I can also see the advantage of supporting a DKS configuration file via that load method. Maybe the implementation
should support both?


> 
>> 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
>