我联系的Web服务器更新了它的SSL证书,现在我的应用程序无法与之通信

Question

Web服务器将其SSL证书更新为新的verisign签名证书,我的Java应用程序无法再连接.

我在/ usr/java/jre/lib/security中使用带有日期的java 5和2006年11月的cert文件

我明白了

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 com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1518)
    at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:174)
    at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:168)
    at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:848)
    at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:106)
    at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)
    at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:818)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1030)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1057)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1041)
    at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:402)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:170)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:133)

如何安装服务器提供的新密钥？

从我得到的不同的java实例

Certificate chain received from eservices3.bus.att.com - 135.38.253.93 was not trusted causing SSL handshake failure.

我认为它来自同一根问题.

更新在远程服务器更新之前,这适用于我们的标准Java安装.我没有必要安装任何证书,以便上次使用它.

Answer 1

Java尝试通过遵循服务器提供的证书链来验证证书,直到找到它信任的证书(即cacerts文件中存在的证书).

我们可以使用OpenSSL命令行工具手动验证链:

simon@lucifer:~$ openssl s_client -connect eservices3.bus.att.com:443
<snipped>
---
Certificate chain
 0 s:/C=US/ST=Georgia/L=Alpharetta/O=ATT Services, Inc./OU=ATTIT/CN=eservices3.bus.att.com
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure Server CA - G3
---

现在,问题在于:发行者(行开头i:)"VeriSign Class 3安全服务器CA-G3"是中间证书,而不是根证书.AT&T服务器配置错误,应该发送自己的证书("eservices3.bus.att.com")和中间证书,以便Java可以一直验证链到根.

为了说明另一种方式,链应该如下所示:

1) VeriSign Class 3 Public Primary Certification Authority - G5 (root)
                               ^
                               | signed by
                               |
2)          VeriSign Class 3 Secure Server CA - G3      (intermediate)
                               ^
                               | signed by
                               |
3)                 eservices3.bus.att.com                     (server)

• 根(1)是cacerts- 好的
• 在SSL握手期间显示服务器证书(3) - 确定
• 但是:Java不了解中间体(2) - 因此无法端到端地验证链

要解决此问题,您可以:

• 要求AT&T修复服务器,以便在握手期间发送服务器和中间证书,或者
• 将中间证书导入Java的密钥库

第一种解决方案更可取,因为它可以帮助每个人(不仅仅是你)并且风险稍低(如果中间证书受到损害,您可能不会注意到).

如果要将证书作为临时措施导入,请从VeriSign的支持页面(它是"辅助SSL中间CA证书")中获取它,然后:

simon@lucifer:~$ keytool -importcert -alias some_alias_of_your_choosing \
                    -file intermediate_cert_path.crt \
                    -keystore your_cacerts_path
Enter keystore password:  *****
Certificate was added to keystore

要删除证书(一旦AT&T一起行动):

simon@lucifer:~$ keytool -delete -alias same_alias_as_before \
                    -keystore your_cacerts_path