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.)
Please let me know what you think.
Thanks,
Jan