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

Question

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

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

我明白了

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)

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

我从一个不同的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 中 - ok
• 服务器证书 (3) 在 SSL 握手期间出示 - 确定
• 但是:Java 不知道中间 (2) - 因此无法端到端地验证链

要解决此问题，您可以:

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

第一种解决方案更可取，因为它对每个人(而不仅仅是您)都有帮助，而且风险稍低(您可能不会注意到中间证书是否受到威胁)。

如果您想导入证书作为临时措施，请从 VeriSign's support pages 中获取它(它是“辅助 SSL 中间 CA 证书”)，然后:

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

删除证书(一旦 AT​​&T 采取行动):

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