PKIX路径构建在Java应用程序中失败

Question

在将我的应用程序从Windows 2000移动到Windows 2008 R2 Server之后,我一直在努力让我的应用程序运行近一周.

程序,流程:

1. 已安装Java JDK 1.7.0_25
2. 将系统环境变量设置JAVA_HOME为C:\Progra~1\Java\jdk1.7.0_25\
3. 将证书导入cacerts中 keytool
4. 确保了证书存在于keytool同-list.

我试图重复第3步,InstallCert以确保我没有弄乱任何东西.

上面的方法没有解决我的问题,所以我尝试以编程方式进行:

System.setProperty("javax.net.ssl.trustStore",
"C:/Progra~1/Java/jdk1.7.0_25/jre/lib/security/cacerts");
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");

仍然没有任何运气.我被卡住了,不太确定从这里走哪个方向.

堆栈跟踪:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
    at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1886)
    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:276)
    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:270)
    at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1341)
    at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:153)
    at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
    at sun.security.ssl.Handshaker.process_record(Handshaker.java:804)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323)
    at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:515)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
    at util.SMS.send(SMS.java:93)
    at domain.ActivationSMSSenderMain.sendActivationMessagesToCustomers(ActivationSMSSenderMain.java:80)
    at domain.ActivationSMSSenderMain.<init>(ActivationSMSSenderMain.java:44)
    at domain.ActivationSMSSenderMain.main(ActivationSMSSenderMain.java:341)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:385)
    at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
    at sun.security.validator.Validator.validate(Validator.java:260)
    at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326)
    at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231)
    at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126)
    at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1323)
    ... 14 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:196)
    at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:268)
    at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380)
    ... 20 more

更新:

两者 System.out.println(System.getProperty("javax.net.ssl.trustStore")); 和 System.out.println(System.getProperty("javax.net.ssl.keyStore"));

回报null.

Answer 1

我遇到了类似的问题,其原因和解决方案都变得非常简单:

主要原因:未使用keytool导入正确的证书

注意:仅导入根CA(或您自己的自签名)证书

注意:请勿导入中间非证书链根证书

imap.gmail.com的解决方案示例

1. 确定根CA证书:

   openssl s_client -showcerts -connect imap.gmail.com:993
   

   在这种情况下,我们发现根CA是Equifax安全证书颁发机构

2. 下载根CA证书.
3. 通过与此处的信息进行比较,验证下载的证书是否具有正确的SHA-1和/或MD5指纹

4. 进口证书javax.net.ssl.trustStore:

   keytool -import -alias gmail_imap -file Equifax_Secure_Certificate_Authority.pem
   

5. 运行你的java代码

Answer 2

您已将证书导入JDK中提供的JRE的信任库,但您正在运行直接安装的JRE的java.exe.

编辑

为了清楚起见,为了解决下面评论中的误解,您需要将证书导入到您打算使用的JREcacerts文件中,并且很少会出现在JDK中的一个,因为客户赢了通常有一个JDK.以下评论中的任何内容都应该被忽略,因为这里没有表达我的意图.

一个更好的解决方案是创建自己的信任库,从cacerts文件的副本开始,并特别告诉Java通过系统属性使用该信任库javax.net.ssl.trustStore.

您应该构建构建过程的这一部分,以便及时更新cacertsJDK升级导致的文件更改.