Hi Shing Wai,
Shing Wai Chan wrote On 06/09/06 10:17,:
> Hi Jan,
> While this should working for JKS or JCEKS, there is an issue for NSS.
> The following is my comments:
Thanks for looking at this from the NSS perspective!
> 1. for NSS, we specific the dir and hence there is no distinction
> between keystore and truststore
Got it! I see a single system property in an EE domain.xml:
<jvm-options>-Dcom.sun.appserv.nss.db=${com.sun.aas.instanceRoot}/config</jvm-options>
whereas PE has
<jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/config/keystore.jks</jvm-options>
<jvm-options>-Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/config/cacerts.jks</jvm-options>
Does NSS require the key3.db and cert8.db files to reside in the same
directory, or is this just the way we've been using NSS? Are the names
of the NSS key and cert files configurable?
If both NSS key and cert files must reside in the same directory, and
have hard-coded names, we could document this restriction:
In the case of NSS, the values of the keystore and truststore
attributes must meet these requirements: The keystore file must
be named key3.db, and the truststore file must be named cert8.db.
In addition, the keystore and truststore files must reside in the
same directory.
> 2. we cannot have NSS for keystore and JKS for truststore
OK. Again, we could add this to the list of configuration restrictions:
If the keystore-type attribute of an <ssl> element is set to "NSS",
that element's truststore-type attribute also must be set to "NSS",
and vice versa.
> 3. we can only have pne NSS per JVM, so we can NSS for one listener
> and JKS for another listener
> But we cannot have NSS db1 for one listener and NSS db2 for
> another listener
Got it.
> 4. if we allow multiple keystores, then we may also need to consider
> what it means for outbound SSL.
> I am not sure whether we separate the request from different
> listeners when we process outbound.
> In order words, we may not be using the same keystore for all
> outbound. We need to do more investigation on this.
OK, please let us know what you find.
In JSSE, each HTTPS listener has its own, individually configured
JSSESocketFactory, whose trust manager is used to authenticate
requests, and whose key manager is used to produce the server's
handshake messages.
Again, if this is not how it works in NSS, we can add this to the list
of limitations.
Looks like we can cover both the JSSE and NSS use cases with the
proposed <ssl> attributes, as long as we document the restrictions
that apply to NSS.
Thanks,
Jan
>
>
> Regards,
> Shing Wai Chan
>
>>
>> Please let me know what you think.
>>
>> Thanks,
>>
>> Jan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>