我与之交谈的Web服务器更新了其SSL证书，现在我的应用无法与之对话

Question

网络服务器将其SSL证书更新为新的经过verisign签名的证书，并且我的Java应用程序无法再连接。

我正在使用Java 5并在/ usr / java / jre / lib / security中的证书文件上带有日期的2006年11月

我懂了

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>
---
证书链
 0秒：/ C = US / ST =乔治亚州/ L =阿尔法利塔/ O = ATT Services，Inc./OU=ATTIT/CN=eservices3.bus.att.com
   i：/ C = US / O = VeriSign，Inc./OU=VeriSign信任网络/ OU =使用条款，网址为https://www.verisign.com/rpa（c）10 / CN = VeriSign 3类安全服务器CA -G3
---

现在，这是问题所在：颁发者（行开头i:）“ VeriSign
3类安全服务器CA-G3”是中间证书，而不是根证书。AT＆T服务器配置错误，应该同时发送自己的证书（“ eservices3.bus.att.com”）
和 中间证书，以便Java可以一直验证到根的链。

为了说明另一种方式，链条应如下所示：

1）VeriSign 3类公共一级证书颁发机构-G5（根）
                               ^
                               | 被...签名
                               |
2）VeriSign 3类安全服务器CA-G3（中级）
                               ^
                               | 被...签名
                               |
3）eservices3.bus.att.com（服务器）

• 根（1）在cacerts-好的
• SSL握手期间显示服务器证书（3）-好的
• 但是：Java不了解中间件（2）-因此无法端对端验证链

要解决此问题，您可以：

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

第一种解决方案是更可取的，因为它可以帮助所有人（不仅限于您），而且风险较小（您可能不会注意到中间证书是否受到威胁）。

如果要将证书作为临时措施导入，请从VeriSign的支持页面（即“中学SSL中间CA证书”）中获取证书，然后：

simon @ lucifer：〜$ keytool -importcert -alias some_alias_of_your_choosing \
                    -文件middle_cert_path.crt \
                    -keystore your_cacerts_path
输入密钥库密码：*****
证书已添加到密钥库

删除证书（一旦AT＆T共同行动）：

simon @ lucifer：〜$ keytool-删除-alias same_alias_as_before \
                    -keystore your_cacerts_path