File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Security and the fly likes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of OCA Java SE 8 Programmer I Study Guide 1Z0-808 this week in the OCAJP forum!
JavaRanch » Java Forums » Engineering » Security
Bookmark "" Watch "" New topic

john ho

Joined: Jan 25, 2008
Posts: 8
Ok, this should be a very basic question.

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?

Sorry if this is a obvious question. Thanks.
Arshad Noor
Ranch Hand

Joined: Oct 06, 2011
Posts: 34
It depends on a lot of factors.

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 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.

Arshad Noor
StrongAuth, Inc.
john ho

Joined: Jan 25, 2008
Posts: 8
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.

If anyone is interested, I actually documented my efforts here:
It is sorta covered in the JavaRanch Style Guide.