Open chriskilding opened 2 years ago
Java has keystore
s and truststore
s. Of the two, we are interested in truststore
s.
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.
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.
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.