On 23/01/07, Kevin Smith <[EMAIL PROTECTED]> wrote:
OK. I've had a chance to look at the docs, and I think I have a handle on how to do this. I'm thinking of adding a <ssl></ssl> block to the configs containing all the info needed to fully configure the SSL context factory: <ssl> <keystore-path>/some/path/to/keystore.ks</keystore-path> <keystore-password>some_password</keystore-password> <cert-type>SunX509</cert-type> </ssl>
This looks good.
I do have a couple of questions surrounding this though: 1) Does more need to be configurable? For example, would we ever use a protocol other than TLS for the SSLContext? My experience with SSL is limited so it's quite likely I'm missing some use cases here.
I think TLS 1.0 is the only one that is going to be used. Until of course someone invents TLS 2.0 :-). Whether we want to put a placeholder for this now, I'm not sure and I don't think it's a biggie. We probably want to have a section for a keystore to contain the certificates of any certificate authorities (i.e. separate from the identity keystore) that need to be trusted by the broker. The other thing we definitely need to be able to support is mutual authentication with SSL - i.e. the client must present a certificate to the broker as well as the other way round. One thing that does occur to me is that some people might want to use a different JCE provider. For example, nCipher (http://www.ncipher.com) provide a hardware SSL solution (i.e. offloading SSL to a separate processor) and use a custom JCE provider. I have never done it but it might be useful to look at how you go about setting up a custom JCE provider and whether we need to do anything special to support that.
2) Does this config need to be interchangeable with the C++ broker?
I'm not sure any of our config is interchangable with the C++ broker. RG
