Jan Luehe wrote:
> 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?
In NSS case, key passwords = keystore passwords.
So, we may like to have the configuration so that it will not make the
domain.xml too complicated.
Also, before adding this level of complexity, we may also need to think
about how to get those passwords during server startup.
>
> > 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>);
In general, this is true. But, it may not be that simple in some cases.
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>