Language support: Java / JVM

[chriskilding]

Tracking the state of native TLS certificate verification in Java.

This also covers all other languages that run on the JVM, like Scala, Clojure, Kotlin, Groovy, and so on.

[chriskilding]

Java has keystores and truststores. Of the two, we are interested in truststores.

Windows

The original implementations which access the Windows Certificate Store were:

• WINDOWS-ROOT
• WINDOWS-MY

But slightly confusingly, both of these only access the user's certificates - not the local computer certificates.

In JDK 19 Early Access Build 23 (https://jdk.java.net/19/release-notes#JDK-6782021) Windows KeyStore support in the SunMSCAPI provider was expanded to include access to the local machine location. This was in response to https://bugs.openjdk.org/browse/JDK-6782021.

The new keystore types are:

• Windows-MY-LOCALMACHINE
• Windows-ROOT-LOCALMACHINE

The following keystore types were also added, allowing developers to make it clear that they map to the current user:

• Windows-MY-CURRENTUSER (same as Windows-MY)
• Windows-ROOT-CURRENTUSER (same as Windows-ROOT)

Note: being early access, this might change before the final release.

macOS

Apple contributed the KeychainStore implementation to the JDK many years ago, so all modern versions of Java support it.

KeychainStore reads from the current user's Keychain. (i.e. unfortunately not the System one where most root certificates are).

It is activated by running Java with these options:

• -Djavax.net.ssl.trustStoreType=KeychainStore
• -Djavax.net.ssl.trustStore=/dev/null (this is a workaround for the fact that, even when you're not using filesystem-based trust stores, Java insists on reading a filesystem location anyway - which it then ignores)

This can be made persistent, either by specifying them in your Maven config, or by setting an environment variable in your shell profile:

export JAVA_TOOL_OPTS="-Djavax.net.ssl.trustStoreType=KeychainStore -Djavax.net.ssl.trustStore=/dev/null"

It also works with the Keytool helper, and is activated by running Keytool with these options:

keytool -list -storetype KeychainStore -keystore NONE 

(TODO: figure out if this was the appropriate syntax for using keytool in truststore mode, rather than keystore mode)

---

This is a good start, and it shows that the JVM clearly has a route to specify alternate truststore handling - we just need to fit into that.

The main problem we need to fix is that the Mac JDK does not currently read from the System / computer trust store.