Вопрос по java, ssl-certificate, ssl – Java7 отказывается доверять сертификату в хранилище доверенных сертификатов
У меня странная проблема - поставщик использует TLS SSLv3 как с самоподписанным сертификатом клиента, так и с сервером. Это не было проблемой с Java1.5 и Java1.6 - просто импортируйте сертификат клиента и закрытый ключ в хранилище ключей, а открытый сертификат сервера - в хранилище доверенных сертификатов. Все отлично работает Однако в Java7 сертификат сервера не может быть доверенным, даже если используется то же хранилище доверенных сертификатов. Я пробовал Windows и Red Hat, использующие Java7 (версии 1.7.03, 04 и 05, x86 и x64), но безуспешно.
Я заново создал хранилище ключей / хранилище доверенных сертификатов, и они содержат только эти сертификаты. Соответствующие системные свойства были установлены (javax.net.ssl.keyStore, javax.net.ssl.trustStore), и ключевым аспектом является то, что точно такой же код и конфигурация отлично работают в JDK5 / 6.
Я в растерянности - я не могу найти никаких ссылок на дополнительную проверку, но я бы подумал, что тот факт, что сертификат был расположен в доверенном хранилище, должен означать, что он является доверенным, независимо от того, является ли он подписанным.
Любая помощь приветствуется. Объявления
Трассировка исключений:
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 терпит неудачу, пытается проверить сертификат сервера:
***
%% 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)
-Djavax.net.debug=all на вашjava командной строки и опубликовать полный результирующий журнал, особенно где загружено хранилище доверия?
David Grant
По некоторым причинам Java 8 не принимает самозаверяющий сертификат, даже добавленный к егоcacerts хранить.
Мой обходной путь для этого заключается в создании собственного хранилища ключей:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -subj "/C=MA/ST=ByExample/L=Test/O=Chapter3/OU=Org/CN=bip70.com" -nodes
keytool -import -keystore clientkeystore -file cert.der -alias bip70.com -storepass changeit
затем используя его в My IDE, используя в качестве аргумента jvm:-Djavax.net.ssl.trustStore=clientkeystore
У меня фактически была похожая проблема, когда приложение Tomcat доверяло сертификату в хранилище доверенных сертификатов при использовании Java 1.6 и отклоняло его с помощью Java 1.7. После добавленияkeyUsage на мой сертификат CA это работает (после прочтения сообщения об ошибке,JDK-7018897: проверка CertPath не может обработать самоподписанный сертификат с неверным KeyUsage).
Что я сделал (Ubuntu 12.04 x64):
- Edit /etc/ssl/openssl.cnf and uncomment
keyUsageline inv3_casection. Generate new ca cert from old one with
keyUsageincluded using the command:openssl x509 -in oldca.pem -clrext -signkey oldca.key -extfile /etc/ssl/openssl.cnf -extensions v3_ca -out newca.pemDelete old CA key from truststore and insert the new one.
Я также сталкивался с этой ситуацией, когда имел дело с JDK 1.7. Если команда req вызывается с опцией -x509, ее лучше раскомментироватьkeyUsage линия вv3_ca раздел и сгенерируйте CA снова с помощью (см.http://wwwneu.secit.at/web/documentation/openssl/openssl_cnf.html)
openssl req -new -x509 -days 3650 -keyout ca.key -out ca.crt -config openssl.cnf -extensions v3_ca -batch
И если вы используете сгенерированный сертификат CA для подписи другого сертификата, убедитесь, что вы также раскомментировали элементbasicConstraints = CA:true и установите значение true