How to set up Java VM to use the root certificates (truststore) handled by Mac OS X

Question

I get the following exception while using the scribe OAuth library.

Caused by: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

Based on some googling it seems I should set up the JVM truststore somehow.

Why do I need to do this? How can I instruct the Java VM to use the default truststore of the os? (Mac OS X in my case).

Solution 1

I can setup the default truststore by adding this system propery when launching the VM:

-Djavax.net.ssl.trustStore=/Library/Java/Home/lib/security/cacerts

I still don't understand why do I need to do this. This should be the default. It's also very annoying to add this every time. Is there a better way, e.g. some OS settings?

Solution 2

You can use the Apple JCA Provider to use the OSX keychain as the java trust store. Just start the JVM with the following system property:

-Djavax.net.ssl.trustStoreType=KeychainStore

You can set this property for every started JVM using the JAVA_TOOL_OPTIONS environment variable, as described in hagrawal's answer.

Solution 3

I think it is clear to everyone that JAVA needs a way to identify the default truststore, when dealing with SSL, so this information has be passed to JAVA in some way, so I think the "updated" question in hand is how to do it in a do-it-one-time-and-then-forget-everytime way.

The best way I could found was by setting JAVA_TOOL_OPTIONS environment variable at your OS level, if this environment variable is set then JAVA will be launched by default with the arguments you have provided in this environment variable.

So, you need not to set -Djavax.net.ssl.trustStore=/Library/Java/Home/lib/security/cacerts each time JVM is launched, instead set JAVA_TOOL_OPTIONS environment variable "once" at your OS level with value as -Djavax.net.ssl.trustStore=/Library/Java/Home/lib/security/cacerts and then you are done.

Below is the excerpt from #1 of "Further readings":

When this environment variable is set, the JNI_CreateJavaVM function (in the JNI Invocation API) prepends the value of the environment variable to the options supplied in its JavaVMInitArgs argument.

Only caveat to watch out is mentioned below, excerpt from #1 of "Further readings":

In some cases this option is disabled for security reasons, for example, on Solaris OS the option is disabled when the effective user or group ID differs from the real ID.

Below is one more caveat (excerpt from #1 of "Further readings") to watch out but I think since context is not about VM selection argument so it is not relevant, but just to mention.

Since this environment variable is examined at the time that JNI_CreateJavaVM is called, it cannot be used to augment the command line with options that would normally be handled by the launcher, for example, VM selection using the -client or the -server option.

Further readings:

• http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-VM/html/envvars.html
• http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#tooloptions

Comments

[sehrgut]

Re: "This should be the default." Java is often updated out-of-sync from the host operating system. Using a separate truststore allows known-insecure certificates to be untrusted more quickly for security, and allows Java apps running on older operating systems that might not themselves bundle all the modern root CAs — and embedded systems that might not have any system CA truststore — to be kept secure. Similar reasoning is why many browsers bypass the system truststore. In fact, Chrome is moving towards this model and away from the system truststore.