Вопрос по java, ssl-certificate, ssl – Java7 отказывается доверять сертификату в хранилище доверенных сертификатов

11

У меня странная проблема - поставщик использует 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)
@ adam-green, не могли бы вы выяснить, как это исправить? Мы как бы в одной лодке ... tavlima
Привет из Ипсилона, мы работаем над этим :) cat_baxter
Я сейчас пытаюсь решить эту проблему. Я исследовал базу данных ошибок Java, и она говорит, что эта проблема исправлена, но я не вижу, каково это решение. Кто-нибудь знает, как пройти это? IcedDante
Может быть, это связано сbugs.sun.com/bugdatabase/view_bug.do?bug_id=7018897 ?? Pma
Можете добавить-Djavax.net.debug=all на вашjava командной строки и опубликовать полный результирующий журнал, особенно где загружено хранилище доверия? David Grant

Ваш Ответ

3   ответа
0

По некоторым причинам 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

10

У меня фактически была похожая проблема, когда приложение Tomcat доверяло сертификату в хранилище доверенных сертификатов при использовании Java 1.6 и отклоняло его с помощью Java 1.7. После добавленияkeyUsage на мой сертификат CA это работает (после прочтения сообщения об ошибке,JDK-7018897: проверка CertPath не может обработать самоподписанный сертификат с неверным KeyUsage).

Что я сделал (Ubuntu 12.04 x64):

  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
    
  3. Delete old CA key from truststore and insert the new one.

Если быть более точным ... Я установил openSSL, я загрузил сертификат с целевого сервера. Но я не уверен, как получить файл oldca.key. Кроме того, я думал, что сертификаты управляются с помощью & quot; crt & quot; расширение. Есть ли причина, по которой вы используете pem?
УвидетьRFC 5280 а такжеRFC 6125 для правил, которые использует Java.
Как это решение работает в среде Windows? У меня нет файла openssl.cnf. Глядя на сообщение об ошибке, я не уверен, что это за исправление. Должен ли я получить сертификат в Java и изменить его там во время выполнения? Не похоже на правильное решение ...
0

Я также сталкивался с этой ситуацией, когда имел дело с 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

Опубликованный вами URL не работает. У вас есть обновленный?
@IcedDante - СмотритеHow do you sign OpenSSL Certificate Signing Requests with your Certification Authority? Переполнение стека.

Похожие вопросы