Jan Luehe wrote:
> In GlassFish, all SSL-enabled HTTP (and IIOP) listeners share the same
> key- and truststore locations, which are specified via system properties.
> Also, the key- and truststore types are hard-coded to "JKS".
>
> Other containers such as Tomcat do not have this limitation.
>
> This limitation was also brought up in
>
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=657
>
> The limitation in GlassFish can be fixed with a few minor code tweaks
> (at least in the HTTP, and possibly also in the IIOP case), but it
> will also require adding configuration support for key- and truststore
> locations and types at the HTTP and IIOP listener level.
>
> Therefore, I propose adding "keystore", "keystore-type", "truststore",
> and
> "truststore-type" attributes to the <ssl> element in domain.xml, as
> follows:
>
> Index: sun-domain_1_2.dtd
> ===================================================================
> RCS file: /cvs/glassfish/admin-core/config-api/dtds/sun-domain_1_2.dtd,v
> retrieving revision 1.20
> diff -u -r1.20 sun-domain_1_2.dtd
> --- sun-domain_1_2.dtd 21 Mar 2006 03:04:39 -0000 1.20
> +++ sun-domain_1_2.dtd 8 Jun 2006 16:30:12 -0000
> @@ -949,7 +949,11 @@
> ssl3-tls-ciphers CDATA #IMPLIED
> tls-enabled %boolean; "true"
> tls-rollback-enabled %boolean; "true"
> - client-auth-enabled %boolean; "false">
> + client-auth-enabled %boolean; "false"
> + keystore CDATA #IMPLIED
> + keystore-type CDATA #IMPLIED
> + truststore CDATA #IMPLIED
> + truststore-type CDATA #IMPLIED>
>
> The keystore and truststore locations can be either absolute paths or
> will be interpreted relative to ${com.sun.aas.instanceRoot}.
>
> (In a future refinement, we could also add support for individual
> keystore and truststore passwords.)
Hi Jan,
While this should working for JKS or JCEKS, there is an issue for NSS.
The following is my comments:
1. for NSS, we specific the dir and hence there is no distinction
between keystore and truststore
2. we cannot have NSS for keystore and JKS for truststore
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
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.
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
>