Java7拒绝信任信任存储中的证书 [英] Java7 Refusing to trust certificate in trust store

查看:760
本文介绍了Java7拒绝信任信任存储中的证书的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个奇怪的问题 - 供应商使用TLS SSLv3同时拥有自签名客户端和服务器证书。这对Java1.5和Java1.6来说不是问题 - 只需将客户端证书和私钥导入密钥库,将服务器公共证书导入信任库即可。
一切正常。
但是对于Java7,即使使用相同的信任库,服务器证书也无法被信任。我尝试使用Java7(1.7.03,04和05,x86和x64版本)的Windows和Red Hat都没有成功。

I've a weird problem - a supplier uses TLS SSLv3 with both a self signed client and server certificate. This hasn't been a problem with Java1.5 and Java1.6 - simply import client certificate and private key into a keystore and the server public certificate into the truststore. Everything works fine. However with Java7 the server certificate fails to be trusted even though the same truststore is being used. I've tried Windows and Red Hat both using Java7 (1.7.03, 04 and 05, x86 and x64 versions) with no success.

我重新创建了密钥库/ truststore从头开始,它们只包含这些证书。
已设置适当的系统属性(javax.net.ssl.keyStore,javax.net.ssl.trustStore),关键方面是完全相同的代码和配置在JDK5 / 6中完美运行。

I've recreated the keystore/truststore from scratch and they only contain these certificates. The appropriate system properties have been set (javax.net.ssl.keyStore, javax.net.ssl.trustStore) and the key aspect is that the exact same code and configuration runs perfectly in JDK5/6.

我很茫然 - 我找不到任何对额外检查的引用,但我认为证书位于信任库中的事实应该意味着它是值得信赖的自签名。

I'm at a loss - I can't find any reference to additional checking but I would have thought that the fact the certificate was located in the truststore should mean that it's trusted regardless of being self signed.

任何帮助表示赞赏。
广告

Any help appreciated. Ads

异常跟踪:

Exception in thread "main" javax.net.ssl.SSLHandshakeException:     sun.security.validator.ValidatorException: PKIX path validation failed:     java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1868)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:276)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:270)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1338)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:154)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:804)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:998)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1294)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:685)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:111)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
at com.alltria.ypsilon.testing.TestSSL.main(TestSSL.java:65)
Caused by: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:350)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:249)
at sun.security.validator.Validator.validate(Validator.java:260)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231)
at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1320)
... 13 more
Caused by: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:208)
at java.security.cert.CertPathValidator.validate(CertPathValidator.java:279)
at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:345)
... 19 more
Java Result: 1

ssl调试失败的部分是尝试验证服务器证书:

The part where the ssl debug fails is trying to validate the server certificate:

***
%% Invalidated:  [Session-1, SSL_RSA_WITH_RC4_128_SHA]
main, SEND SSLv3 ALERT:  fatal, description = certificate_unknown
main, WRITE: SSLv3 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 00 00 02 02 2E                               .......
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors
main, called close()
main, called closeInternal(true)


推荐答案

我实际上有一个类似的问题,在使用Java 1.6时,Tomcat应用程序会信任信任库中的ca证书,并使用java 1.7拒绝它。将 keyUsage 添加到我的ca证书后,它可以正常工作(在阅读错误报告后, JDK-7018897:CertPath验证无法处理带有错误KeyUsage的自签名证书

I actually had a somewhat similar issue, where a Tomcat application would trust the ca cert in the truststore when using Java 1.6 and reject it with java 1.7. After adding keyUsage to my ca certificate it works (after reading a bug report, JDK-7018897 : CertPath validation cannot handle self-signed cert with bad KeyUsage).

我做了什么(Ubuntu 12.04 x64) :

What I have done (Ubuntu 12.04 x64):


  1. 编辑/etc/ssl/openssl.cnf并取消注释 keyUsage line in v3_ca section。

  2. 使用 keyUsage 包含使用命令:

  1. Edit /etc/ssl/openssl.cnf and uncomment keyUsage line in v3_ca section.
  2. Generate new ca cert from old one with keyUsage included using the command:

openssl x509 -in oldca.pem -clrext -signkey oldca.key -extfile /etc/ssl/openssl.cnf -extensions v3_ca -out newca.pem


  • 从以下位置删除旧的CA密钥信任库并插入新的信任库。

  • Delete old CA key from truststore and insert the new one.

    这篇关于Java7拒绝信任信任存储中的证书的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

  • 查看全文
    登录 关闭
    扫码关注1秒登录
    发送“验证码”获取 | 15天全站免登陆