我谈到的Web服务器更新了它的SSL证书,现在我的应用程序无法与之通信
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安装。 我没有必要安装任何证书,以便上次使用它。
Java尝试通过遵循服务器提供的证书链来validation证书,直到找到它信任的证书(即cacerts
文件中存在的证书)。
我们可以使用OpenSSL命令行工具手动validation链:
simon @ lucifer:〜$ openssl s_client -connect eservices3.bus.att.com:443 <剪断> --- 证书链 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 = https://www.verisign.com/rpa上的使用条款(c)10 / CN = VeriSign Class 3安全服务器CA - G3 ---
现在,问题在于:发行者(行开始i:
:)“VeriSign Class 3安全服务器CA-G3”是中间证书,而不是根证书。 AT&T服务器配置错误,应该发送自己的证书(“eservices3.bus.att.com”) 和中间证书,以便Java可以一直validation链到根。
为了说明另一种方式,链应该如下所示:
1)VeriSign Class 3公共主要证书颁发机构 - G5(根) ^ | 被...签名 | 2)VeriSign Class 3安全服务器CA - G3(中级) ^ | 被...签名 | 3)eservices3.bus.att.com(服务器)
- 根(1)是
cacerts
– 好的 - 在SSL握手期间显示服务器证书(3) – 确定
- 但是:Java不了解中间体(2) – 因此无法端到端地validation链
要解决此问题,您可以:
- 要求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 输入密钥库密码:***** 证书已添加到密钥库
要删除证书(一旦AT&T一起行动):
simon @ lucifer:〜$ keytool -delete -alias same_alias_as_before \ -keystore your_cacerts_path
听起来好像您的服务器(或应用程序,但更可能是服务器)不信任verisign已颁发此新证书的根证书。 一旦您信任该证书,您就会信任所有链接到它的证书。
可以在以下链接中找到verisign根CA: