Hi Hubert,
Hubert Iwaniuk wrote:
> Hi Bruno,
>
> Issue describing changes in SSLConfig:
> https://grizzly.dev.java..net/issues/show_bug.cgi?id=494
> <https://grizzly.dev.java.net/issues/show_bug.cgi?id=494>
> Basically aim was to provide defaults and remove need for providing
> keystore and truststore if only key store was needed.
> Changes made to SSLConfig kept it backward compatible on interface level
> and relaxed restrictions put on users but allowing to configure kestore
> without configuring truststore.
This makes sense. I'm not sure about the current default values, though.
I think it might make more sense to follow the default values in
<
http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#Customization>.
In particular, I get the impression that, if the
'javax.net.ssl.trustStore' system property isn't set, the default
SSLConfig behaviour is to try to load a file called 'truststore.jks',
which would have to be set up by the user, rather than the 'jssecacerts'
or 'cacerts' set up in the JRE.
Another example is the default store type, which is hard-coded to be
"JKS", whereas it could be KeyStore.getDefaultType() (which is going to
be "JKS" indeed 99% of the time indeed).
If you don't mind trying to have default values closer to those of the
JSSE Ref. Guide, I'll try to come up with a patch over the next few days.
The other point I'm not sure about is the "public(Properties)" method.
In jSSLutils's KeyStoreLoader, I've specifically removed all the getters
and prevented cloning the instance so as to prevent extraction of
potentially sensitive information (I'm not sure which code would get
hold of such an instance). Exporting information such as the keystore
password might not be suitable (depending on how much the code that may
get hold of the instance can be trusted). Is it used by anything in
particular?
Best wishes,
Bruno.