Невозможно пройти аутентификацию на сайте SSL в java: «pathLenConstraint нарушен - этот сертификат должен быть последним сертификатом в пути сертификации» - PullRequest
7 голосов
/ 06 мая 2009

Я пытаюсь читать с защищенной (т. Е. SSL) веб-страницы в коде Java. Я пытаюсь использовать URLConnection (java.net) и HTTPClient Apache. В обоих случаях, когда я делаю запрос, я получаю это исключение:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: Ошибка проверки пути PKIX: java.security.cert.CertPathValidatorException: проверка основных ограничений не удалась: pathLenConstraint нарушен - это сертификат должен быть последним сертификатом в путь сертификации в com.sun.net.ssl.internal.ssl.Alerts.getSSLException (Alerts.java:150) в com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal (SSLSocketImpl.java:1518) в com.sun.net.ssl.internal.ssl.Handshaker.fatalSE (Handshaker.java:174) в com.sun.net.ssl.internal.ssl.Handshaker.fatalSE (Handshaker.java:168) в com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate (ClientHandshaker.java:848) в com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage (ClientHandshaker.java:106) в com.sun.net.ssl.internal.ssl.Handshaker.processLoop (Handshaker.java:495) в com.sun.net.ssl.internal.ssl.Handshaker.process_record (Handshaker.java:433) в com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord (SSLSocketImpl.java:818) в com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake (SSLSocketImpl.java:1030) в com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake (SSLSocketImpl.java:1057) в com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake (SSLSocketImpl.java:1041) в sun.net.www.protocol.https.HttpsClient.afterConnect (HttpsClient.java:402) в sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect (AbstractDelegateHttpsURLConnection.java:166) в sun.net.www.protocol.http.HttpURLConnection.getInputStream (HttpURLConnection.java:934) в sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream (HttpsURLConnectionImpl.java:234) в com.sap.river.coghead.rest.Main.testJavaHTTPConnection (Main.java:45) в com.sap.river.coghead.rest.Main.main (Main.java:32) Вызванный: sun.security.validator.ValidatorException: Ошибка проверки пути PKIX: java.security.cert.CertPathValidatorException: проверка основных ограничений не удалась: pathLenConstraint нарушен - это сертификат должен быть последним сертификатом в путь сертификации в sun.security.validator.PKIXValidator.doValidate (PKIXValidator.java:187) в sun.security.validator.PKIXValidator.engineValidate (PKIXValidator.java:139) в sun.security.validator.Validator.validate (Validator.java:203) в com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted (X509TrustManagerImpl.java:172) в com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted (SSLContextImpl.java:320) в com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate (ClientHandshaker.java:841) ... еще 13 причин: java.security.cert.CertPathValidatorException: проверка основных ограничений не удалась: pathLenConstraint нарушен - это сертификат должен быть последним сертификатом в путь сертификации в sun.security.provider.certpath.PKIXMasterCertPathValidator.validate (PKIXMasterCertPathValidator.java:139) в sun.security.provider.certpath.PKIXCertPathValidator.doValidate (PKIXCertPathValidator.java:316) в sun.security.provider.certpath.PKIXCertPathValidator.engineValidate (PKIXCertPathValidator.java:178) в java.security.cert.CertPathValidator.validate (CertPathValidator.java:206) в sun.security.validator.PKIXValidator.doValidate (PKIXValidator.java:182) ... еще 18

Обратите внимание, что мне удалось установить не-ssl-соединение с другим хостом. Я также могу просматривать эту страницу с помощью браузера - сертификаты там проверены правильно.

Вам нужно как-то изменить порядок сертификатов при их получении с сервера?Мне не хватает какой-то конфигурации?

Заранее спасибо,

Лиор

Ответы [ 3 ]

6 голосов
/ 06 мая 2009

Я копался дальше, и ответ заключается в том, что мне нужно было импортировать необходимые сертификаты в хранилище ключей, используемое JVM для аутентификации SSL. Хранилище ключей - это файл 'cacerts' в папке jre / lib / security в jre, который используется для запуска программы.

Я вручную экспортировал сертификаты сайта - все они.
Затем я импортировал его в хранилище ключей по умолчанию с помощью утилиты 'keytool', предоставленной Sun. Обратите внимание, что вы должны импортировать их в правильном порядке.
Затем я поставил новое хранилище ключей вместо JRE - и оно заработало.

Полагаю, было бы лучше импортировать сертификаты непосредственно в хранилище ключей JRE, но инструмент попросил у меня пароль, который я не знал.

Я полагаю, что есть еще способ запрограммировать это, просто еще не нашел. Я буду счастлив получить несколько указателей (класс TrustManager в JSSE?).

Наконец, немного кредита. Этот пост здесь: http://javaishdiscoveries.blogspot.com/2009/02/battle-with-cacerts-and-https.html помог указать мне правильное направление.

0 голосов
/ 25 августа 2009

Проблема была в заказе цепочки сертификатов. Это было: A-> C-> B, но должно быть A-> B-> C, как только мы установили порядок цепочек, приложение начало работать.


Я лично не исправил сертификаты. но этот пост был полезен

http://groups.google.com/group/google-checkout-api-troubleshooting/browse_thread/thread/99862c11d37d3127

0 голосов
/ 27 июня 2009

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: сбой проверки пути PKIX: java.security.cert.CertPathValidatorException: сбой проверки основных ограничений: pathLenConstraint нарушен - этот сертификат должен быть последним в сертификате путь в

pathLenConstraint

см. (Примечание о цепочках сертификатов) в

http://groups.google.com/group/google-checkout-developers-forum/web/google-checkout-and-ssl-certificates?version=49

Google говорит, что это может быть проблема с порядком цепочки сертификатов, я только что обнаружил, что мой сертификат не в порядке, еще не исправлен, работает над ним. Я обновлю это позже.


старое сообщение:

У меня почти такая же проблема.

Добавление сертификата вручную в хранилище ключей помогает, но я бы предпочел сделать это более автоматически с моим клиентом.

Итак, мое решение:

Я буду использовать хранилище ключей только для этого одного приложения и одного хоста 1. хранилище ключей не существует - создайте с некоторым сгенерированным паролем 2. сохранить пароль в конфигурационном файле 3. спросите пользователя (или не), хочет ли он принять этот сертификат 4. если это так - сохраните его в хранилище ключей и используйте при необходимости

Это хорошее решение? Есть комментарии?

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