On 10/08/2014 08:14 AM, Wang Weijun wrote:
On Oct 8, 2014, at 23:00, Sean Mullan <[email protected]> wrote:
I agree that we should not read jssecacerts by default. My vote would be to
extend -trustcacerts to take an optional path to a cacerts file but fallback on
lib/security/cacerts if not specified.
No keytool option takes an optional argument now. This will be a big change.
Ok, maybe add a new option then -cacertsfile <filename> (only applicable
if -trustcacerts is specified).
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 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. 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
--Max
https://blogs.oracle.com/mullan/resource/J1-2014-CON5778.pdf
(see slides 34-35)
--Sean
