Веб-сервер, с которым я общаюсь, обновил свой сертификат SSL, и теперь мое приложение не может с ним общаться - PullRequest
2 голосов
/ 22 апреля 2011

Веб-сервер обновил свой сертификат SSL до нового сертификата, подписанного Verisign, и мое приложение Java больше не может подключиться.

Я использую Java 5 с датой в файле сертификата, ноябрь 2006 г., в / usr / java / jre / lib / security

Я получаю

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. Мне не нужно было устанавливать какие-либо сертификаты, чтобы это работало в прошлый раз.

Ответы [ 2 ]

12 голосов
/ 23 апреля 2011

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 - ок
  • сертификат сервера(3) представлен во время рукопожатия SSL - хорошо
  • , но: Java не знает промежуточного (2) - поэтому не может проверить сквозную цепочку

Чтобы это исправить, вы можете:

  • попросить AT & T исправить сервер, чтобы он отправлял серверу и промежуточный сертификат во время рукопожатия, или
  • импорт промежуточного сертификата в хранилище ключей Java

Первое решение предпочтительнее, так как оно помогает всем (не только вам) и немного менее рискованно (вы можете не заметить, если промежуточноесертификат был скомпрометирован).

Если вы хотите импортировать сертификат,В качестве временной меры, возьмите ее со страниц поддержки VeriSign (это «Сертификат вторичного промежуточного сертификата SSL»), затем:

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

Чтобы удалить сертификат (как только AT & T соберутся вместе):

simon@lucifer:~$ keytool -delete -alias same_alias_as_before \
                    -keystore your_cacerts_path
0 голосов
/ 23 апреля 2011

Звучит так, как будто ваш сервер (или приложение, но, скорее, сервер) не доверяет корневому сертификату, с которого verisign выпустил этот новый сертификат.Если вы доверяете этому сертификату, вы доверяете всем сертификатам, прикованным к нему.

Корневые CA verisign можно найти по следующей ссылке:

http://www.verisign.com/support/roots.html

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...