Nicolas Frankel is an IT consultant with 10 years experience in Java / JEE environments. He likes his job so much he writes technical articles on his blog and reviews technical books in his spare time. He also tries to find other geeks like him in universities, as a part-time lecturer. Nicolas is a DZone MVB and is not an employee of DZone and has posted 229 posts at DZone. You can read more from them at their website. View Full User Profile

Managing Trust Stores Across Java Versions

02.20.2012
| 2956 views |
  • submit to reddit

My debugging contest of the week happened to take place on a IBM AIX system. The bug happened when we upgraded from Java version 1.4 to version 6 (which I admit is a pretty big step). Suddenly, an old application stopped working and its log displayed NoSuchAlgorithmException.

A bit of context: when Java applications have to connect to hosts with SSL over HTTP, they must trust the host – it’s the same as when you browse a site with HTTPS. If the site can provide a SSL certificate that can proves its trustworthiness by tracing it back to a trust authority (Verisign and others), all is well. However, when browsing, you can always force the browser to trust a certificate that is not backed by a trusted authority. Such a luxury is not permitted when running an application, there’s no callback.

Therefore, you can add certificates to the JVM truststore, which is located under the $JRE_HOME/security/lib. Alternatively, you can also pass a truststore with the -Djavax.net.ssl.trustStore=<path/to/store> Java launch parameter. Before this problem, I was foolish to think you could keep the same truststore between different Java versions without a glitch. This is not the case: going back and forth a few times, we finally located the root problem.

It seems that between Java version 1.4 and 6, the good people at IBM decided to completely change their security providers. This means that when a certificate is stored by a Java 1.4 JVM, the Java 6 JVM has no chance to read it.If you’ve had told me that before then, I would have laughed in your face. Reality is weirder than fiction.

Conclusion: for Ops, it may be a good idea to consider always using the same security provider regardless of the operating system. Bouncy Castle is one of such providers, others surely exist.

Note: Sun may be defunct, but their engineers kept the same security providers between Java 1.4 and 6

From http://blog.frankel.ch/trust-stores-and-java-versions

Published at DZone with permission of Nicolas Frankel, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Goel Yatendra replied on Thu, 2012/03/15 - 3:48pm

Oracle JDK 6 has some nasty tricks of its own though: if your code used the XML libraries (e.g. JAX), the ones included with JDK6 are NOT the latest ones. If you included more recent versions, they will be ignored silently. You need to add you more modern versions to the “endorsed” directory of the JVM. You’d think there would be a list or some such, but good luck finding exactly what is not treated that way.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.