Kedar,
Kedar Mhaswade wrote On 06/09/06 00:59,:
> 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?
Both. :)
By allowing HTTP listeners to be configured for different trust
environments, a single appserver domain could be used to host webapps
belonging to different trust domains, by designating one or more HTTP
listeners for each trust domain, having those listeners feed into
their own virtual server, and deploying webapps onto that virtual
server.
> - 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>
Exactly.
> where each keystore has keys with different keypasswords,
Not sure. I believe even in the current case, it is impossible to
protect each key individually, meaning all keys are sharing the
the same password that is also used to protect the keystore.
> with a currently proposed limitation of same key with which
> all the keystores are locked. Is that right?
Yes, but this limitation is only temporary, until we have a better
understanding of how to specify different passwords for different
keystores. We certainly would not want to add a keystore-password
attribute to <ssl> and specify the password in cleartext.
Any suggestions?
> 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].
As I mentioned, the password restriction is temporary only. The added
benefit of being able to configure different trust domains for a single
appserver domain remains.
> - Shouldn't the keystore/truststore types be enums (entities),
> rather than CDATA sections?
Not sure. Any specified keystore-type will be passed as the argument to
java.security.KeyStore.getInstance(<keystore-type>);
Keystore impls are provider based, and providers may introduce their own
keystore types, meaning the list of supported keystore types is extensible.
Jan
>
>
> 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
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>