Resolving javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed Error?
Устранение исключения javax.net.ssl.SSLHandshakeException: sun.security.validator.Исключение ValidatorException: ошибка при построении пути PKIX?
Редактировать : Я попытался отформатировать вопрос и принятый ответ более презентабельным образом в своем блоге.
Вот исходная проблема.
Я получаю эту ошибку:
подробное сообщение sun.security.validator.Исключение ValidatorException: ошибка построения пути PKIX: sun.security.provider.certpath.Исключение SunCertPathBuilderException: не удается найти действительный путь сертификации к запрошенной цели
причина исключения javax.net.ssl.SSLHandshakeException: sun.security.validator.Исключение ValidatorException: ошибка построения пути PKIX: sun.security.provider.certpath.Исключение SunCertPathBuilderException: не удается найти действительный путь сертификации к запрошенной цели
Я использую Tomcat 6 в качестве веб-сервера. У меня есть два веб-приложения HTTPS, установленные на разных Tomcats на разных портах, но на одном компьютере. Скажем, App1 (порт 8443) и App2 (порт 443). App1 подключается к App2. Когда App1 подключается к App2, я получаю указанную выше ошибку. Я знаю, что это очень распространенная ошибка, поэтому сталкивался со многими решениями на разных форумах и сайтах. У меня есть приведенная ниже запись в server.xml обоих Tomcats:
Каждый сайт говорит об одной и той же причине, по которой сертификата, предоставленного app2, нет в доверенном хранилище jvm app1. Похоже, это также верно, когда я пытался перейти по тому же URL-адресу в браузере IE, это работает (при прогреве возникает проблема с сертификатом безопасности этого веб-сайта. Здесь я говорю перейти на этот веб-сайт). Но когда Java-клиент нажимает на тот же URL (в моем случае) Я получаю приведенную выше ошибку. Поэтому, чтобы поместить ее в truststore, я попробовал эти три варианта:
Но этот подход хорош для установки devbox, но я не могу использовать его в производственной среде.
Мне интересно, почему три подхода, упомянутые выше, не сработали, когда я упомянул те же значения в server.xml сервера App2 и те же значения в truststore, установив
System.setProperty("javax.net.ssl.trustStore", "C:/.keystore") and System.setProperty("javax.net.ssl.trustStorePassword", "changeit");
в программе App1.
Для получения дополнительной информации вот как я устанавливаю соединение:
Вам необходимо добавить сертификат для App2 в файл truststore используемой JVM, расположенный по адресу $JAVA_HOME\lib\security\cacerts.
Сначала вы можете проверить, находится ли ваш сертификат уже в truststore, выполнив следующую команду: keytool -list -keystore "$JAVA_HOME/jre/lib/security/cacerts" (вам не нужно вводить пароль)
Если ваш сертификат отсутствует, вы можете получить его, загрузив в свой браузер и добавив в truststore с помощью следующей команды:
Исключение javax.net.ssl.SSLHandshakeException: sun.security.validator.Исключение ValidatorException: ошибка построения пути PKIX: sun.security.provider.certpath.Исключение SunCertPathBuilderException: не удается найти действительный путь сертификации к запрошенной цели
• Когда я получил сообщение об ошибке, я попытался найти в Google значение выражения и обнаружил, что эта проблема возникает, когда сервер изменяет свой HTTPS SSL-сертификат, а наша более старая версия java не распознает корневой центр сертификации (CA).
• Если вы можете получить доступ к URL-адресу HTTPS в своем браузере, то можно обновить Java для распознавания корневого центра сертификации.
• В вашем браузере перейдите по URL HTTPS, к которому Java не удалось получить доступ. Щелкните цепочку сертификатов HTTPS (в Internet Explorer есть значок блокировки), нажмите на блокировку, чтобы просмотреть сертификат.
• Перейдите в раздел “Сведения” о сертификате и “Скопируйте в файл". Скопируйте его в формате Base64 (.cer). Он будет сохранен на вашем рабочем столе.
• Установите сертификат, игнорируя все предупреждения.
• Вот как я собрал информацию о сертификате URL-адреса, к которому я пытался получить доступ.
Теперь мне пришлось сделать так, чтобы моя версия java знала о сертификате, чтобы в дальнейшем она не отказывалась распознавать URL. В этой связи я должен упомянуть, что я погуглил, что информация о корневом сертификате по умолчанию хранится в папке JDK \ jre \ lib \ security, а пароль для доступа по умолчанию: changeit.
Для просмотра информации cacerts необходимо выполнить следующие процедуры:
• Нажмите кнопку "Пуск" -> "Выполнить".
• Введите cmd. Откроется командная строка (возможно, вам потребуется открыть ее от имени администратора).
замените <your domain> своим доменом (например, jossef.com)
замените <JAVA HOME> на ваш домашний каталог java
3) Взломать его
Несмотря на то, что iv'e установил мой сертификат в Javaхранилища сертификатов по умолчанию, Tomcat игнорирует это (похоже, он не настроен на использование хранилищ сертификатов Java по умолчанию).
Чтобы взломать это, добавьте следующее где-нибудь в свой код:
В моем случае проблема заключалась в том, что веб-сервер отправлял только сертификат и промежуточный CA, а не корневой CA. Добавление этой опции JVM решило проблему: -Dcom.sun.security.enableAIAcaIssuers=true
Доступна поддержка метода доступа caIssuers расширения доступа к полномочной информации. По умолчанию оно отключено для обеспечения совместимости и может быть включено путем установки системному свойству com.sun.security.enableAIAcaIssuers значения true.
Если установлено значение true, реализация Sun PKIX CertPathBuilder использует информацию в расширении AIA сертификата (в дополнение к указанным хранилищам сертификатов) для поиска выдавшего сертификат CA, при условии, что это URI типа ldap, http или ftp.