This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
I am trying to connect to an MQ server using SSL. If I use the code:
then everything is fine, it connects over SSL and all is good. The jks file contains certificates and private key data (I guess) in order to negotiate the connection to the MQ server.
However, it seems to me that by using System.setProperty(...), it sets the properties for the entire JVM, isn't this potentially a problem? Doesn't this mean that if elsewhere in the system, there is code that relies on some default trust store, then it will possibly break? For example, some other code that makes https connections, etc. If this is indeed a problem, what is the best practice solution?
There is nothing wrong with an application specifying a single keystore/truststore with only one certificate as a trusted certificate in it for the entire JVM, as long as anyone using that JVM recognizes that its keystore/truststore is customized. This is a much more paranoid setting than the default which trusts more than 50 Certification Authorities all over the world.
Generally, an application's security review determines what must be trusted, what other applications are running on the same machine and do they need to use the same JVM, etc. Once you've reviewed these, there are many different ways to configure this.
1) You can create different keystores/truststores for each applications and specify these properties on the command line that starts the JVM with the -D options (see http://docs.oracle.com/javaee/1.4/tutorial/doc/Security6.html for explanation). Now each application will start its own JVM with its own keystore/truststore;
2) You can create a common keystore/truststore and have all the applications on the machine use the same *stores when they start the JVM; this assumes that they all have the same security profile and its OK for them to be sharing these resources;
3) You can write the code manually to read your own keystore/truststore and establish your own SSL session without use the System properties; this is harder and more work, but it will work for those who are super-paranoid;
4) There may be other ways, but I would usually pick a solution from either #1 or #2.
Joined: Jan 25, 2008
Hey, thanks for replying to this -- after I got no reply for a while I stopped coming back to the thread so that's why I didn't see it until now.
I ended up doing your #3 option. It was indeed a bit of extra work but not too bad, the trick was convincing the MQ drivers to use an instance of the custom SSLSocketFactory that I wrote (which uses certificates only from a specific truststore). But I find it reassuring in a way that you consider this to be super-paranoid, lol.