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

Wang Weijun weijun.wang at oracle.com
Wed Oct 8 04:21:25 UTC 2014


On Oct 8, 2014, at 12:00, Xuelei Fan <xuelei.fan at oracle.com> wrote:

> On 10/8/2014 11:37 AM, Wang Weijun wrote:
>> 
>> On Oct 8, 2014, at 11:10, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>>> 
>>>> However, I can think of adding a new system property called "jdk.keytool.cacerts" so that people can point it to a file not jre/lib/security/cacerts. This would be useful for the bug reporter and we can now finally testing the -trustcacerts option.
>>>> 
>>> If I'm correct, the cacerts can be specified in command line.
>>> Considering we have had the command line option, the benefit of adding a
>>> new system property may be limited.
>> 
>> The option is a simple "-trustcacerts" without any parameter. So you cannot customize where the trusted keystore is.
>> 
> What's the option "-keystore" for?  I though it is the target keystore.
> Looks like the following command is confusing.
> 
>   $ keytool -importcert ... -trustcacerts -keystore my-key-store

This means you want to import a cert into my-key-store. If that cert is signed by another cert in cacerts (or my-key-store) then the cert is silently imported. Otherwise, a prompt is printed out.

There are two keystores here. -keystore points to user's keystore that keytool will save into. cacerts is a read-only keystore that is used to find trusted certs.

> 
> Per the doc, "If the -trustcacerts option was specified, then additional
> certificates are considered for the chain of trust, namely the
> certificates in a file named cacerts", "-trustcacerts" must store the
> cert in "cacerts", however, the "-keystore" option want to store the
> cert in "my-key-store".
> 
> If you add a new property ("jdk.keytool.cacerts"), there might be
> compatibility issues as the target store may be not cacerts, for
> "-trustcacerts" option, any more.

No. Currently the cacerts in -trustcacerts is hard coded as jre/lib/security/cacerts. The new system property makes it customizable.

> 
> Per the request of the bug, if customers want to use jssecacerts, they
> can simply use the "-keystore" option.  At the same point, if users want
> to use key store other than cacerts, just use the "-keystore" option.  I
> see not much benefits to define a new system property.

No, the -keystore points to user's own keystore, it is neither cacerts nor jssecacerts.

--Max

> 
> Xuelei
> 



More information about the security-dev mailing list