On 10/8/2014 11:37 AM, Wang Weijun wrote:
>
> On Oct 8, 2014, at 11:10, Xuelei Fan <[email protected]> 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
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.
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.
Xuelei
