Jan Luehe wrote:
> 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
Yes
> 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:
Yes, in our case.
>
> 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.
We may not want to reference this name in our configuration as it has
been changed in different versions of NSS.
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>