我与之交谈的网络服务器更新了其 SSL 证书，现在我的应用程序无法与其交谈

Question

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

我正在使用 java 5，其证书文件的日期为 2006 年 11 月，位于 /usr/java/jre/lib/security

我得到了

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 Secure Server 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 中 - 好的，
• 服务器证书 (3) 在 SSL 握手期间呈现 - 好的
• 但是：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

Answer 2

听起来好像您的服务器（或应用程序，但更可能是服务器）不信任 verisign 颁发此新证书的根证书。一旦您信任该证书，您就会信任与其关联的所有证书。

可以在以下链接找到 verisign 根 CA：

http://www.verisign.com/support /roots.html