Solution
On Windows, set the following JVM properties:
javax.net.ssl.trustStore=NUL
javax.net.ssl.trustStoreType=Windows-ROOT
I’ve successfully tested this with Java 7, which runs on a 64-bit Windows installation which trusts a self-signed CA.
Configuring the security provider
If the above solution works for you (it should), you may skip this section. Otherwise, check the setup of your Java Cryptography Extension (JCE), which is bundled with modern JDKs. Your JDK installation should have a property file which contains a list of security providers. The location of that file may vary with Java versions; mine is located at "%JAVA_HOME%jrelibsecurityjava.security"
. Inside that file, locate a set of properties whose names begin with security.provider
. One of those entries should be set to sun.security.mscapi.SunMSCAPI
.
Example
To set the properties at runtime, use the following Java code:
System.setProperty("javax.net.ssl.trustStore", "NUL");
System.setProperty("javax.net.ssl.trustStoreType", "Windows-ROOT");
Explanation
javax.net.ssl.trustStoreType
On Windows, Java ships with SunMSCAPI, a security provider which is actually a wrapper around the Windows CAPI.
Setting the javax.net.ssl.trustStoreType
property to Windows-ROOT
instructs Java to refer to the native Windows ROOT keystore for trusted certificates, which includes root CAs. (Similarly, setting javax.net.ssl.keyStoreType
to Windows-MY
tells Java to refer to the native Windows MY keystore for user-specific certificates and their corresponding keys).
javax.net.ssl.trustStore
If the javax.net.ssl.trustStoreType
property is set to Windows-ROOT
, one would expect that the value of javax.net.ssl.trustStore
is ignored, and that it can be set to e.?g. NONE
.
One common workaround for this issue is to set javax.net.ssl.trustStore
to NONE
, and then creating a dummy file whose file name is NONE
. If you find yourself affected by this quirk, try setting javax.net.ssl.trustStore
to NUL
so you won’t have to create any dummy files.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…