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

score 29 · Answer 1 · answered Jul 20 '19 at 00:57

29

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.

answered Jul 20 '19 at 00:57

rmbrad

952
10
13

This worked to have Fiddler working for me. Thank you! – Technomad Sep 15 '19 at 16:10
3

This by far is the best answer. Thank you! – Jonathan S. Fisher Mar 10 '20 at 14:33
FYI, [Apple JCA Provider@Java 11](https://docs.oracle.com/en/java/javase/11/security/oracle-providers.html#GUID-3185649A-C316-45F2-A70E-2B3FF6BDC34F) – ryenus Apr 10 '21 at 18:20
1

This appears to break requests that use certs from the default truststore file, sadly. Apparently it won't obey both at the same time. – Shannon Sep 07 '21 at 21:29
What if your spring application is running in a docker container? I suspect KeychainStore will not be accessible there. Any idea how to fix it in that case? – Prasannjeet Singh Aug 13 '22 at 22:33
@Shannon You're right. This seems to be a new bug, because it used to work. Unfortunately, I was unable to find out if it's a problem of Java or the Apple JCE provider or macOS itself. :-( – not2savvy Oct 05 '22 at 09:36
This worked after many days of struggling. Thank you! – user2436956 Mar 10 '23 at 14:17

score 18 · Accepted Answer · edited Dec 28 '16 at 16:01

18

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?

edited Dec 28 '16 at 16:01

Captain Man

6,997
6
48
74

answered Jan 11 '13 at 17:19

Tamas

3,254
4
29
51

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. – sehrgut Jul 22 '21 at 17:39
2

@sehrgut There’s actually a defined mechanism to check for revoked certificates that should be used rather than let every application bring its own trust store. Installing a company root certificate is already a nightmare with so many trust stores scattered over each client system. – not2savvy Oct 21 '22 at 06:38

hagrawal7777 · Answer 3 · 2016-12-29T01:22:24.883

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:

score 0 · Answer 4 · answered Dec 28 '16 at 15:46

0

Ah! i know this problem. I had similar issue, and it was related to the Java bindings in OSX. Once i installed the latest version, it got fixed.

https://support.apple.com/en-us/HT204036

answered Dec 28 '16 at 15:46

blganesh101

3,647
1
24
44

not2savvy · Answer 5 · 2022-10-05T10:24:15.253

To make Java use the macOS keychain, pass the following parameter to the Java VM:

-Djavax.net.ssl.trustStoreType=KeychainStore

However, there seems to be a bug in either the Apple JCE provider (that handles the keychain access) or perhaps in macOS itself, which obviously leads to the issue that certificates in the login and system keychain are seen by Java, but not those in system roots. Unfortunately, the latter is exactly where all the system provided certificates are stored. :-(

Some users report that adding

-Djavax.net.ssl.trustStore=NUL

or

-Djavax.net.ssl.trustStore=/dev/null

has resolved the issue for them. I cannot confirm that. It did not work for me when I tried it.

I'm pretty sure that this used to work properly, though.

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

5 Answers5

Linked