Jeff Genender wrote:
Yes, the KeystoreGBean.getKeystoreFile()
KeystoreGBean.getKeystorePassword(), etc, would be simple to do...for both
containers.
The KeystoreGBean.getServerPrivateKey() would be more involved. In theory
it could be done...I need to look more at the Tomcat API to examine its
complexity level. I'll get beck to you on this later today.
Upon further review, this will be no easy feat. I recommend we allow
access tot he actual keystore file.
Can we offer both options up?
Jeff
-----Original Message-----
From: Aaron Mulder [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 13, 2005 7:17 AM
To: [email protected]
Subject: SSL Support (Jetty & Tomcat)
So we heard earlier from the TriFork guys that they'd
prefer if Geronimo had a generic Keystore service. I notice
that Jetty and Tomcat have HTTPS support requiring Keystore
configuration as well, and it doesn't seem to make a ton of
sense to me to repeat all the settings in each HTTPS/SSL
interface (unless you want them to be different). This isn't
super-onerous because normally you don't have that many, but
I can see the attraction of a centralized Leystore service.
If we provide a Keystore GBean, how would Jetty and
Tomcat be able to take advantage of it? It seems that if the
Keystore GBean was just a centralized place to access
Keystore settings, the answer would be obvious (the SSL web
connectors could just say KeystoreGBean.getKeystoreFile(),
KeystoreGBean.getKeystorePassword(), etc.). But if the
KeystoreGBean instead only used the config settings
internally and its external API instead provided access
directly to the server keys and CA certs, it's not clear to
me whether the Tomcat and Jetty HTTPS connectors could
operate on that basis (KeystoreGBean.getServerPrivateKey(),
KeystoreGBean.getCACerts(), etc.).
Any thoughts from the people who are more familiar with
the web containers?
Thanks,
Aaron
