dev@glassfish.java.net

Re: [PROPOSAL] Improve configuration support for SSL key- and truststores

From: Kedar Mhaswade <Kedar.Mhaswade_at_Sun.COM>
Date: Fri, 09 Jun 2006 00:59:44 -0700

Interesting idea.
The less we depend on -D properties, the better.

Some questions to Jan.

- Is this stemming from parity with Tomcat alone or
   do you see any other need for it?

- Just so that it is clear, we are entertaining something like:
   <http-listener id="one" ...>
    <ssl .. keystore="ks1" />
   </http-listener>
   <http-listener id="two" ...>
    <ssl .. keystore="ks2" />
   </http-listener>

   where each keystore has keys with different keypasswords,
   with a currently proposed limitation of same key with which
   all the keystores are locked. Is that right?

   If that's the case, then can you elaborate the advantages of
   having various keystores? [Note that in order to configure
   it on the GlassFish server, you'll need to know the admin user
   and admin password].

- Shouldn't the keystore/truststore types be enums (entities),
   rather than CDATA sections?

Thanks.

Jacob Hookom wrote:
> In B2B WS world, this would be quite a nice enhancement.
>
> 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.)
>>
>> 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
>>
>>
>
>