Unable to find valid certification path to requested target как исправить

В статье мы узнаем как решить проблему "PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target", которая часто встречается в API-тестах, написанных на языке Java. Мы выясним что является причиной этой проблемы, а также узнаем как сконофигурировать тесты таким образом, чтобы она больше не появлялась.

Когда люди говорят «API тесты«, они обычно имеют в виду API, предоставляемый поверх протоколов HTTP либо HTTPs. Так сложилось, что упомянутые протоколы в подавляющем большинстве случаев используются при реализации архитектуры REST, а также, для реализации веб-сервисов, работающих по протоколу SOAP. В то время как простой HTTP обычно не вызывает никаких проблем, его ssl-расширение требует более сложного подхода и привлечения таких артефактов как «ключи» и «сертификаты». Некорректная конфигурация соединения в таких случаях часто приводит к падениям тестов в результате невозможности проверить валидность сертификата, возвращаемого тестовым сервером. В этой статье мы взглянем на такую проблему и узнаем как её решать.

Возможно вы видели сообщение об ошибке вида «PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target». Если да, значит вы нашли нужную статью.

В нашем примере мы создадим вызов ендпоинта «https://webelement.click», используя базовый инструментарий, входящий в поставку Java SDK (пакет java.net.*). Этот вызов скорее всего не будет успешным по причине невозможности валидации предоставляемого сервером сертификата. После этого мы сконфигурируем наш кастомный trust store (чуть позже я объясню что это такое) и научим наш код его использовать. Также мы рассмотрим подход при котором созданный нами trust store станет частью нашего тестового проекта, что сделает тесты более независимыми от среды исполнения.

Итак, вот модель наших API-тестов, которые пытаются осуществить вызов ендпоинта с использованием Secure Socket Layer (также известным под именем Transport Layer Security) протокола.

package click.webelement.https;

import java.io.IOException;
import java.net.HttpURLConnection;
import java.net.URL;

public class ApiWithSSL {

    public static void main(String[] args) {

        try {
            HttpURLConnection connection = (HttpURLConnection) new URL("https://webelement.click").openConnection();
            int responseCode = connection.getResponseCode();
            if(responseCode != 200){
                System.out.println("Test failed with actual status code: " + responseCode);
            }else{
                System.out.println("Test passed");
            }
        } catch (IOException e) {
            System.out.println("Test failed with exception: " + e.getMessage());

        }

    }

}

Предполагается, что тест выше упадёт. Давайте теперь заглянем в проблему чуть глубже.

Вообще, конечно, может случиться и так, что тест из примера пройдет успешно. Это произойдет в том случае, если ваша среда корректно настроена и хранилище доверенных сертификатов, используемое по умолчанию содержит сертификаты агентства, выпускающего сертификаты LetsEncrypt. C другой стороны, если бы у вас не было бы проблем, вы бы вряд ли искали решение, правда?

Чаще всего рассматриваемая проблема возникает, когда вы имеете дело с сертификатами, выпущенными локальными корпоративными сертификационными центрами.

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

Что вообще означает фраза «PKIX path building failed»?

Когда ваш код пытается обратиться к https-эндпоинту, удаленный сервер посылает вашему клиенту свой публичный ключ и сертификат, подтверждающий его (сервера) «личность». Клиенту, в свою очередь, необходимо решить может ли он доверять такому сертификату. Каждый сертификат подписан цифровой подписью издателя (третьей стороной), что означает, что проверить такую подпись возможно только с помощью публичного ключа издателя.

Но можем ли мы доверять издателю этого сертификата (третьей стороне процесса)? Публичный ключ издателя также сопровождается своим сертификатом, который может быть проверен идентичным путем. Такая цепочка имеет название certificate chain.

В чем состоит основная идея, лежащая в основе протокола https? Этот протокол использует т.н. криптографию открытого ключа (так же известную как «асимметричная» криптография) для того чтобы согласовать с сервером «симметричный» ключ (а фактически — пароль, при помощи которого будут кодироваться и декодироваться сообщения). Таким образом, на первом этапе взаимодействия, клиенту требуется публичный ключ сервера, чтобы при помощи него зашифровать сообщения фазы упомянутого согласования.

Для того чтобы клиент мог быть уверенным в том, что он действительно общается с сервером, с которым он думает, что общается, публичный ключ обычно сопровождается сертификатом. Сертификат — это такой документ, который содержит имя субъекта, а также публичный ключ, ассоциированный с именем субъекта. На основании всей информация сертификата, вычисляется хэш-строка, которая затем подписывается (шифруется) при помощи секретного ключа сертификационного агентства (CA), выдавшего данный сертификат. Единственным способом проверить валидность такого сертификата является вычисление хэш-строки сертификата и сравнение результата с расшифрованным «подписанным» хэшем. Успешно расшифровать подписанный хэш можно только при помощи публичного ключа агенства, который в свою очередь, также сопровождается своим сертификатом.

Любая реализация протоколов HTTPs/SSL подразумевает наличие некоего хранилища сертификатов, которые считаются «доверенными» (в англоязычной среде такое хранилище называется trust store). Таким сертификатам мы доверяем по умолчанию. Вообще говоря, таких хранилищ может быть несколько, и каждое может быть использовано для своих целей. Основное правило, которое необходимо соблюсти для успешной коммуникации вашего кода и HTTPs-сервиса — это наличие хотя бы одного сертификата из цепочки в доверенном хранилище. В Java (в том случае если вы не меняли дефолтное состояние вещей), доверенное хранилище находится в файле %JRE_HOME%/lib/security/cacerts. Для большинства Java дистрибутивов, такой trust store уже содержит сертификаты/ключи всех общеизвестных сертификационных агентств, так что у вас не должно будет возникнуть проблем при соединении с большинством публичных сервисов в Интернете. Однако, для интранет-сервисов дела обстоят не так безоблачно.

Сообщение «PKIX path building failed» означает, что ssl-библиотека Java в процессе валидации цепочки сертификатов, пришедшей с сервера не смогла обнаружить такой сертификат, который бы находился в используемом trust store.

Подготавливаем траст стор для того чтобы наш код доверял бы сертификату от тестового сервера

Мы собираемся применить комплексный подход к решению нашей задачи. Сперва нам необходимо подготовить доверенное хранилище, которое бы содержало сертификат, возвращаемый нашим тестовым сервером. Ниже перечислены шаги, которые необходимо выполнить:

  1. Получить файл сертификата, содержащий сертификат вашего сервиса. Это может быть сделано одним из двух способов. 1) спросить ваших разработчиков или девопсов, ответственных за имплементацию и деплоймент сервиса. 2) Открыть https ендпоинт в вашем веб-браузере, кликнуть на иконку «замочек» рядом с адресной строкой, следовать указаниям открывшегося диалога, который в итоге приведет вас к ссылке на экспортирование сертификата в виде файла. Нам подойдут сертификаты в форматах .pem или .cer.

  2. Создать какой-нибудь каталог, куда положить полученный файл. Открыть командную строку и перейти в созданный каталог. Важно убедиться в том, что ваша переменная окружения PATH содержит каталог %JRE_HOME%/bin (это необходимо для того, чтобы иметь возможность запускать утилиту keytool из любого места вашей файловой системы).

  3. Находясь в созданном каталоге, импортируйте файл сертификата в хранилище (которое пока еще не создано) используя следующую команду.

keytool -importcert -file your-cert-file.pem -keystore mytruststore -storetype PKCS12

Установите какой-нибудь пароль. Этот пароль будет использоваться при обращении вашего кода к созданному хранилищу. Также ответьте «Yes» на вопрос действительно ли вы хотите доверять импортируемому сертификату.

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

Как использовать новый trust store в моем Java-тесте?

После того, как мы создали новый траст стор, нам необходимо как-то сообщить нашему тестовому коду, что теперь ему следует работать с новым хранилищем. Это можно сделать либо установив значения для соответствующих системных свойств через параметры командной строки при вызове ваших тестов из консоли (это, например, удобно делать при интеграции ваших тестов с инструментами Continuous Integration) или установить эти значения прямо в исполняемом коде. Мы будем использовать второй способ. Свойства, значения для которых нам надо будет установить, такие: javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword.

Предположим, что мы создали хранилище доверенных сертификатов в файле mytruststore, который находится в каталоге /home/me/ssl и пароль, установленный для нашего хранилища — mystorepass. Тогда неработающий пример из начала статьи можно было бы переписать таким образом:

package click.webelement.https;

import java.io.IOException;
import java.net.HttpURLConnection;
import java.net.URL;

public class ApiWithSSL {

    static {

        System.setProperty("javax.net.ssl.trustStore", "/home/me/ssl/mytruststore");
        System.setProperty("javax.net.ssl.trustStorePassword", "mystorepass");

    }

    public static void main(String[] args) {

        try {
            HttpURLConnection connection = (HttpURLConnection) new URL("https://webelement.click").openConnection();
            int responseCode = connection.getResponseCode();
            if(responseCode != 200){
                System.out.println("Test failed with actual status code: " + responseCode);
            }else{
                System.out.println("Test passed");
            }
        } catch (IOException e) {
            System.out.println("Test failed with exception: " + e.getMessage());
        }

    }

}

Где мы просто добавляем блок статической инициализации в котором устанавливаем необходимые значения для наших свойств.

Такая настройка не обязательно должна находится в блоке статической инициализации. Она может быть добавлена в любое место, исполняемое до вызова https ендпоинта.

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

Если после прочтения у вас всё ещё остались вопросы, присылайте их мне используя эту форму обратной связи. Я постараюсь ответить вам напрямую, а также скорректировать статью, опираясь на ваши отзывы.

Источник

The article presents the steps to import required certificates and enable Java application to connect to Azure SQL DB/Managed Instance. If required certificates are missing on client machine when connecting via AAD authentication, a similar error will be prompted in the application logs:

«SQLServerException: Failed to authenticate the user in Active Directory (Authentication=ActiveDirectoryPassword).
Caused by: ExecutionException: mssql_shaded.com.microsoft.aad.adal4j.AuthenticationException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Caused by: AuthenticationException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target. «

This is an issue in Java Certificate Store. As a quick workaround, if you enable TrustServerCertificate=True in the connection string, the connection from JDBC succeeds. When TrustServerCertificate is set to true, the transport layer will use SSL to encrypt the channel and bypass walking the certificate chain to validate trust. If TrustServerCertificate is set to true and encryption is turned on, the encryption level specified on the server will be used even if Encrypt is set to false. The connection will fail otherwise. However, for security considerations, it is not recommended to bypass the certificate validation. Hence, to address the issue, follow the steps below to change the connection string and import the required certificates. 

  • Change the connection string to point to the Java certificate path

    String connectionUrl =  «jdbc:sqlserver://localhost:1433;» + 
        «databaseName=AdventureWorks;integratedSecurity=true;» + 
        «encrypt=true; trustServerCertificate=false;» + 
        «trustStore= C:Program FilesJavajdk-14.0.2libcacert;trustStorePassword=changeit»;

  • Import all the certificates mentioned in this document.

    Note: To import above certificates into the keystore cacerts, please use below command and please note you must mention truststore and truststore password in the connection string to successfully connect.  

Steps to import missing certificates in Java Certificate Store

Download all the certs from here, store them in a location on client host and then use keytool utility to import these certificates into the truststore. Please follow the below steps:

  • Save all the certificates from the above MS doc.
  • Keytool utility is in the bin folder of your default Java location (C:Program FilesJavajdk-14.0.2bin). You need to use command prompt to navigate to that location.
  • Then you can use the keytool command to import the certificate previously saved. 
  • When prompted for password insert the key in the password as “changeit”

Example of commands:

keytool -importcert -trustcacerts -alias TLS1 -file «C:UsersDocumentsMicrosoft RSA TLS CA 01.crt» -keystore «C:Program FilesJavajdk-14.0.2libsecuritycacerts»

keytool -importcert -trustcacerts -alias TLS2 -file «C:UsersDocumentsMicrosoft RSA TLS CA 02.crt» -keystore «C:Program FilesJavajdk-14.0.2libsecuritycacerts»

Certificate was added to keystore.

Источник

WebElement.click()

Полное руководство по решению проблемы «PKIX path building failed» в ваших API-тестах на Java

К огда люди говорят «API тесты«, они обычно имеют в виду API, предоставляемый поверх протоколов HTTP либо HTTPs. Так сложилось, что упомянутые протоколы в подавляющем большинстве случаев используются при реализации архитектуры REST, а также, для реализации веб-сервисов, работающих по протоколу SOAP. В то время как простой HTTP обычно не вызывает никаких проблем, его ssl-расширение требует более сложного подхода и привлечения таких артефактов как «ключи» и «сертификаты». Некорректная конфигурация соединения в таких случаях часто приводит к падениям тестов в результате невозможности проверить валидность сертификата, возвращаемого тестовым сервером. В этой статье мы взглянем на такую проблему и узнаем как её решать.

Возможно вы видели сообщение об ошибке вида «PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target». Если да, значит вы нашли нужную статью.

Описание примера: API-тест на Java, испытывающий проблемы с валидацией сертификата

В нашем примере мы создадим вызов ендпоинта «https://webelement.click», используя базовый инструментарий, входящий в поставку Java SDK (пакет java.net.* ). Этот вызов скорее всего не будет успешным по причине невозможности валидации предоставляемого сервером сертификата. После этого мы сконфигурируем наш кастомный trust store (чуть позже я объясню что это такое) и научим наш код его использовать. Также мы рассмотрим подход при котором созданный нами trust store станет частью нашего тестового проекта, что сделает тесты более независимыми от среды исполнения.

Итак, вот модель наших API-тестов, которые пытаются осуществить вызов ендпоинта с использованием Secure Socket Layer (также известным под именем Transport Layer Security) протокола.

Предполагается, что тест выше упадёт. Давайте теперь заглянем в проблему чуть глубже.

Вообще, конечно, может случиться и так, что тест из примера пройдет успешно. Это произойдет в том случае, если ваша среда корректно настроена и хранилище доверенных сертификатов, используемое по умолчанию содержит сертификаты агентства, выпускающего сертификаты LetsEncrypt. C другой стороны, если бы у вас не было бы проблем, вы бы вряд ли искали решение, правда?

Чаще всего рассматриваемая проблема возникает, когда вы имеете дело с сертификатами, выпущенными локальными корпоративными сертификационными центрами.

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

Что вообще означает фраза «PKIX path building failed»?

Когда ваш код пытается обратиться к https-эндпоинту, удаленный сервер посылает вашему клиенту свой публичный ключ и сертификат, подтверждающий его (сервера) «личность». Клиенту, в свою очередь, необходимо решить может ли он доверять такому сертификату. Каждый сертификат подписан цифровой подписью издателя (третьей стороной), что означает, что проверить такую подпись возможно только с помощью публичного ключа издателя.

Но можем ли мы доверять издателю этого сертификата (третьей стороне процесса)? Публичный ключ издателя также сопровождается своим сертификатом, который может быть проверен идентичным путем. Такая цепочка имеет название certificate chain.

В чем состоит основная идея, лежащая в основе протокола https? Этот протокол использует т.н. криптографию открытого ключа (так же известную как «асимметричная» криптография) для того чтобы согласовать с сервером «симметричный» ключ (а фактически — пароль, при помощи которого будут кодироваться и декодироваться сообщения). Таким образом, на первом этапе взаимодействия, клиенту требуется публичный ключ сервера, чтобы при помощи него зашифровать сообщения фазы упомянутого согласования.

Для того чтобы клиент мог быть уверенным в том, что он действительно общается с сервером, с которым он думает, что общается, публичный ключ обычно сопровождается сертификатом. Сертификат — это такой документ, который содержит имя субъекта, а также публичный ключ, ассоциированный с именем субъекта. На основании всей информация сертификата, вычисляется хэш-строка, которая затем подписывается (шифруется) при помощи секретного ключа сертификационного агентства (CA), выдавшего данный сертификат. Единственным способом проверить валидность такого сертификата является вычисление хэш-строки сертификата и сравнение результата с расшифрованным «подписанным» хэшем. Успешно расшифровать подписанный хэш можно только при помощи публичного ключа агенства, который в свою очередь, также сопровождается своим сертификатом.

Любая реализация протоколов HTTPs/SSL подразумевает наличие некоего хранилища сертификатов, которые считаются «доверенными» (в англоязычной среде такое хранилище называется trust store). Таким сертификатам мы доверяем по умолчанию. Вообще говоря, таких хранилищ может быть несколько, и каждое может быть использовано для своих целей. Основное правило, которое необходимо соблюсти для успешной коммуникации вашего кода и HTTPs-сервиса — это наличие хотя бы одного сертификата из цепочки в доверенном хранилище. В Java (в том случае если вы не меняли дефолтное состояние вещей), доверенное хранилище находится в файле %JRE_HOME%/lib/security/cacerts . Для большинства Java дистрибутивов, такой trust store уже содержит сертификаты/ключи всех общеизвестных сертификационных агентств, так что у вас не должно будет возникнуть проблем при соединении с большинством публичных сервисов в Интернете. Однако, для интранет-сервисов дела обстоят не так безоблачно.

Сообщение «PKIX path building failed» означает, что ssl-библиотека Java в процессе валидации цепочки сертификатов, пришедшей с сервера не смогла обнаружить такой сертификат, который бы находился в используемом trust store.

Подготавливаем траст стор для того чтобы наш код доверял бы сертификату от тестового сервера

Мы собираемся применить комплексный подход к решению нашей задачи. Сперва нам необходимо подготовить доверенное хранилище, которое бы содержало сертификат, возвращаемый нашим тестовым сервером. Ниже перечислены шаги, которые необходимо выполнить:

Получить файл сертификата, содержащий сертификат вашего сервиса. Это может быть сделано одним из двух способов. 1) спросить ваших разработчиков или девопсов, ответственных за имплементацию и деплоймент сервиса. 2) Открыть https ендпоинт в вашем веб-браузере, кликнуть на иконку «замочек» рядом с адресной строкой, следовать указаниям открывшегося диалога, который в итоге приведет вас к ссылке на экспортирование сертификата в виде файла. Нам подойдут сертификаты в форматах .pem или .cer.

Создать какой-нибудь каталог, куда положить полученный файл. Открыть командную строку и перейти в созданный каталог. Важно убедиться в том, что ваша переменная окружения PATH содержит каталог %JRE_HOME%/bin (это необходимо для того, чтобы иметь возможность запускать утилиту keytool из любого места вашей файловой системы).

Находясь в созданном каталоге, импортируйте файл сертификата в хранилище (которое пока еще не создано) используя следующую команду.

Установите какой-нибудь пароль. Этот пароль будет использоваться при обращении вашего кода к созданному хранилищу. Также ответьте «Yes» на вопрос действительно ли вы хотите доверять импортируемому сертификату.

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

Как использовать новый trust store в моем Java-тесте?

После того, как мы создали новый траст стор, нам необходимо как-то сообщить нашему тестовому коду, что теперь ему следует работать с новым хранилищем. Это можно сделать либо установив значения для соответствующих системных свойств через параметры командной строки при вызове ваших тестов из консоли (это, например, удобно делать при интеграции ваших тестов с инструментами Continuous Integration) или установить эти значения прямо в исполняемом коде. Мы будем использовать второй способ. Свойства, значения для которых нам надо будет установить, такие: javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword .

Предположим, что мы создали хранилище доверенных сертификатов в файле mytruststore , который находится в каталоге /home/me/ssl и пароль, установленный для нашего хранилища — mystorepass . Тогда неработающий пример из начала статьи можно было бы переписать таким образом:

Где мы просто добавляем блок статической инициализации в котором устанавливаем необходимые значения для наших свойств.

Такая настройка не обязательно должна находится в блоке статической инициализации. Она может быть добавлена в любое место, исполняемое до вызова https ендпоинта.

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

Если после прочтения у вас всё ещё остались вопросы, присылайте их мне используя эту форму обратной связи. Я постараюсь ответить вам напрямую, а также скорректировать статью, опираясь на ваши отзывы.

This post is about a common error that most java developers would have witnessed in their career. The problem appears with a cryptic error message “unable to find valid certification path to requested target‘’. This error message is generally printed out by the sun.security.provider.certpath.SunCertPathBuilderException class.

This is an exception handling class in Java that deals with verifying the SSL certificates of the server that the java application is trying to connect to. Below is a snippet of the log messages the developer is shown while encountering this error.

What makes it difficult to troubleshoot is that this exception class can be triggered in multiple situations. It can be thrown during any operation that requires accessing a service that is secured using SSL encryption. Some of the typical situations that trigger this error are listed below.

  • The most common situation in which this error is faced is when a package build process tries to access the maven package repository. The typical reason is an outdated client certification configuration. It also comes to the light straight after a Java version change operation at the client-side.
  • Another typical situation is during the use of client libraries provided by third-party services. When the developer tries to use the library in his code, the library tries to access its parent REST or SOAP API and throws this error. The reason, in this case, is also the lack of certificate configuration of the parent domain in the client machine. A client library like Twitter4J that helps pull tweets by accessing Twitter APIs can trigger this error if your client machine has an outdated certificate configuration.
  • This error can also be seen in cases where a client application accesses a service succeed by self-signed certificates.

Out of the three situations above, the most common occurrence of this error is while dealing with the artifact build process and package management. A package repository like PackageCloud that just works all the time can relieve you from thinking about frustrating problems like these.

You can checkout PackageCloud here. Now that we understand the typical situations in which this error is found, let’s move on to understanding the root cause.

What is the problem when you see “unable to find valid certification path to requested target”

In a nutshell, the root cause of this error irrespective of the scenario you encountered it in is an invalid certificate configuration at the client machine. Fixing this error needs one to have a full understanding of what is involved in an invalid certificate configuration. As mentioned above, this error is usually thrown by Java client applications. The client application can either be a package management client or third-party library or even a custom java module.

While trying to access an API or domain secured by SSL, the Java framework checks whether the certificate used by the service is trusted. It does this by checking whether the root certificate authority who signed it is present in its internal trusted list. If it does not find mention of it, Java aborts accessing the service and throws this error. It is now straightforward to understand that a client application trying to access a service signed by a self-signed certificate will always end up in trouble.

But why does this error get thrown while trying to access third-party services from dependable providers? The reason can be either of the two listed below.

  • Something that happened in your Java framework installation directory has messed up its list of trusted providers. This can even be a simple version upgrade gone wrong.
  • The certificate at the third-party service may not be signed by a popular root CA or it could be signed by an intermediate CA that is not present in JRE’s trusted list.

If you are unfamiliar with the concepts of SSL encryption, terms like root CA and intermediate CA may be intimidating. Before going to the solution for the problem, let’s try to understand how these terms are important in the context of the error.

Understanding SSL encryption and certificates

An SSL certificate is the backbone of an HTTPS connection. It establishes the identity of the website or the service through a pair of public and private keys. Everything that is served by the domain is encrypted or signed by the private key and the client applications verify the identity by using the public keys. The key pair is generated by the website or the server by placing a certificate signing request with a certificate authority who is well known.

The Certificate Authority generally has a root certificate that has been approved by trust stores run by organizations like Microsoft, Google, Mozilla, etc. It uses this root certificate to provide SSL certificates. The catch here is that certificate authorities do not always use their root certificates to authorize SSL certificates. In order to mitigate their risk and avoid a single point of failure, they generate intermediate certificates using root certificates and then use these intermediate certificates to generate SSL certificates. This is called a certificate chain. This chain can be made longer by generating child certificates from root certificates and intermediate certificates.

With the introduction of chaining and intermediate CAs, the client applications now should be able to verify the authenticity of servers by checking the intermediate certificates. At times this may not work well and the user has to manually add the whole certificate chain to the trust store to ensure client applications are able to connect. The other relevant concept that needs to be understood is the self-signed certificate. These are certificates that are generated by the website or service itself without depending on a well-known certificate authority.

Naturally, these certificates can not be trusted unless there is a special relationship between the client and server. In the same entity is managing both the client and server application, self-signed certificates can be used. Since JRE does not have any mechanism for verifying a self-signed certificate, it will trust it only if the user has manually added the certificate to the trust store. Now that we understand the theory of SSL certificates, it is evident that the solution to this problem is to add the certificate of the server to the trust store. Let’s now understand how we can accomplish this.

How to solve “unable to find valid certification path to requested target”

1. The first step of troubleshooting this problem is to check whether this is indeed a certificate problem or something to do with the network. To confirm this, try accessing the URL from your favorite browser. If the browser is able to access it, then it means, the problem is with an invalid certificate configuration at the application client. If the browser is not able to access it, then the problem could be because of network configuration or a firewall.

2. Once you have confirmed that the problem is indeed with the certificate configuration, the next step is to get hold of the certificate used by the server. In the simplest of cases, this could be the root certificate, but in most cases there will be a certificate chain and intermediate CAs.

If you are using a browser, click the lock icon next to the URL bar and click on the Certificate link and click details. From the details section, the certificate can be exported using the export button. Ensure that you select DER encoded binary as the format for export.

3. An alternate way to download the certificate is to use the below command with the URL you want to access.

The command will output all the certificates included in the chain. The output will be as follows.

Save each of them as a file with unique names. Ensure that you copy both the BEGIN CERTIFICATE and END CERTIFICATE part.

4. The next step is to add the certificate to the trust store. This can be done using the keytool utility.

While importing multiple certificates, ensure that the alias name is different for each of them. The default password for the JRE trust store is ‘changeit’. If you have changed this password, ensure to use the correct password.

Once this is done, restart your application and everything should be fine.

Conclusion

The error ‘unable to find valid certification path to requested target’ is a tough one to troubleshoot since it needs elaborate knowledge on SSL certificates, root CAs and intermediate CAs. This error is extremely common while dealing with package managers, automated deployment processes etc. The best way to avoid losing time stuck on such issues is to use a reliable package repository like Packagecloud that just works all the time.

«Ошибка построения пути PKIX» и «невозможно найти действительный путь сертификации к запрошенной цели»

Я пытаюсь получить твиты, используя библиотеку twitter4j для моего проекта Java. При первом запуске я получил ошибку о сертификате sun.security.validator.ValidatorException и sun.security.provider.certpath.SunCertPathBuilderException . Затем я добавил твиттер сертификат по:

Но без успеха. Вот процедура получения твитов:

  1. Перейдите по ссылке в вашем браузере:
    • Firefox — нажмите на цепочку сертификатов HTTPS (значок замка прямо рядом с URL-адресом). Нажмите «more info» > «security» > «show certificate» > «details» > «export..» . Выберите имя и выберите тип файла example.cer
    • chrome — нажмите на иконку сайта слева для адресации в адресной строке, выберите «Сертификат» -> «Детали» -> «Экспорт» и сохраните в формате «Der-закодированный двоичный файл, один сертификат».

Теперь у вас есть файл с хранилищем ключей, и вы должны добавить его в JVM. Определите местоположение файлов cacerts, например. C:Program Files (x86)Javajre1.6.0_22libsecuritycacerts.

Затем импортируйте example.cer файл в cacerts в командной строке:

keytool -import -alias example -keystore C:Program Files (x86)Javajre1.6.0_22libsecuritycacerts -file example.cer

Вам будет предложено ввести пароль, по умолчанию changeit

Перезагрузите JVM / ПК.

После многих часов попыток создать файлы сертификатов, чтобы моя установка Java 6 работала с новыми сертификатами Twitter, я, наконец, наткнулся на невероятно простое решение, скрытое в комментарии на одной из досок объявлений. Просто скопируйте файл cacerts из установки Java 7 и перезапишите файл в вашей установке Java 6. Вероятно, лучше всего сначала сделать резервную копию файла cacerts, но затем просто скопируйте новый файл в BOOM! это просто работает.

Обратите внимание, что я фактически скопировал файл Windows cacerts в установку Linux, и он работал просто отлично.

Файл находится в jre/lib/security/cacerts в старой и новой установках Java jdk.

Надеюсь, это спасет кого-то еще часы от обострения.

МОЙ пользовательский интерфейс:

  1. Загрузите проводник ключей здесь
  2. Откройте $ JAVA_HOME / jre / lib / security / cacerts
  3. введите PW: changeit (можно изменить на Mac)
  4. Импортируйте ваш файл .crt
  1. keytool -importcert -file jetty.crt -alias jetty -keystore $JAVA_HOME/jre/lib/security/cacerts
  2. введите PW: changeit (можно изменить на Mac)

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

По сути, вы должны добавить сертификат с сервера в сертификаты Java Home.

  1. Создайте или получите свой сертификат и настройте Tomcat для его использования в Servers.xml
  2. Загрузите исходный код Java этого класса InstallCert и выполните его во время работы сервера, предоставив следующие аргументы server[:port] . Пароль не требуется, так как оригинальный пароль работает для сертификатов Java («changeit»).
  3. Программа подключится к серверу, а Java сгенерирует исключение, проанализирует сертификат, предоставленный сервером, и позволит вам создать jssecerts файл в каталоге, в котором вы запустили Программу (если выполняется из Eclipse, убедитесь, что вы настроили Работу каталог в Run -> Configurations ).
  4. Вручную скопируйте этот файл в $JAVA_HOME/jre/lib/security

После выполнения этих шагов соединения с сертификатом больше не будут генерировать исключения в Java.

Следующий исходный код важен, и он исчез из (Sun) блогов Oracle, единственная найденная мной страница была по указанной ссылке, поэтому я прилагаю его в ответе для любой ссылки.

1. Проверьте сертификат

Попробуйте загрузить целевой URL-адрес в браузере и просмотреть сертификат сайта (обычно он доступен по значку со знаком блокировки. Он находится слева или справа от адресной строки браузера), независимо от того, истек ли он или нет по другой причине.

2. Установите последние версии JRE и JDK

Новые версии обычно поставляются с обновленным набором доверенных сертификатов.

Также, если это возможно, удалите старые версии. Это сделает ошибки неверной конфигурации явными.

3. Проверьте свою конфигурацию:

  • Проверьте, куда указывает ваша переменная окружения JAVA_HOME.
  • Проверьте, какую версию Java вы используете для запуска программы. В IntelliJ проверьте:
    • Файл -> Структура проекта . -> Настройки проекта -> Проект -> Project SDK:
    • Файл -> Структура проекта . -> Настройки платформы -> SDK

    4. Скопируйте весь склад ключей из новой версии Java

    Если вы разрабатываете с использованием JDK, отличного от последнего доступного — попробуйте заменить %JAVA_HOME%/jre/lib/security/cacerts файл новым из последней установленной JRE (сначала сделайте резервную копию), как предлагает @ jeremy-goodell в своем ответе.

    5. Добавьте сертификат (ы) в ваше хранилище ключей

    Если ничто иное не решает вашу проблему, используйте keytool для сохранения сертификатов в хранилище ключей Java:

    Файл с сертификатом можно получить в браузере, как @MagGGG предлагает в своем ответе. .

    Примечание 1: вам может потребоваться повторить это для каждого сертификата в цепочке к сертификату вашего сайта. Начните с корневого.

    Примечание 2: <alias_name> должно быть уникальным среди ключей в магазине или keytool будет отображать ошибку.

    Чтобы получить список всех сертификатов в магазине, вы можете запустить:

    Если что-то пойдет не так, это поможет вам удалить сертификат из магазина:

    Используется для проверки сертификата.

    Предупреждение Использовать только в целях разработки, это небезопасно!

    У меня была немного другая ситуация, когда в моей системе присутствовали JDK и JRE 1.8.0_112.

    Я импортировал новые сертификаты CA в [JDK_FOLDER]jrelibsecuritycacerts уже известную команду:

    Тем не менее, я продолжал получать ту же ошибку при создании пути PKIX .

    Я добавил отладочную информацию в Java CLI, используя java -Djavax.net.debug=all . > debug.log . В файле debug.log строка, начинающаяся с trustStore: фактически указывает на хранилище cacerts, найденное в [JRE_FOLDER]libsecuritycacerts .

    В моем случае решением было скопировать файл cacerts, используемый JDK (в который были добавлены новые CA), в файл, используемый JRE, и это решило проблему.

    История вопроса:

    Я получаю следующую ошибку, когда пытаюсь запустить mvn clean install в моем проекте и с помощью опции очистки и сборки IDE Netbeans. Эта проблема возникает из-за того, что сертификат недоступен при загрузке через IDE NET / через командную строку, но позволяет загружать файлы через браузер.

    Ошибка :

    Разрешение:

    1. Загрузите сертификат указанного URL:

    • Запустите IE с помощью «Запуск от имени администратора» (иначе мы не сможем скачать сертификат)
    • Введите URL-адрес в IE-> https: // url / local-repo (в моем случае этот URL-адрес имел ненадежный сертификат введите описание изображения здесь.)
    • Загрузите сертификат, нажав «Ошибка сертификата» -> просмотреть сертификат
    • Выберите вкладку «Сведения» -> «Копировать в файл» -> «Далее» -> «Выбрать» кодированный двоичный код DER X.509 (.CER).
    • сохраните сертификат в каком-либо месте, например: c: /user/sheldon/desktop/product.cer
    • Congrats! Вы успешно загрузили сертификат для сайта

    2. Теперь установите хранилище ключей, чтобы исправить проблему.

    • Выполните команду keytool, чтобы добавить загруженное хранилище ключей в существующий файл сертификата.
    • Команда: Команда ниже в папке bin jdk (JAVA_HOME) .

    C: Program Files Java jdk1.8.0_141 jre bin> keytool -importcert -file «C: /user/sheldon/desktop/product.cer» -alias product -keystore «C: / Программные файлы / Java / jdk1.8.0_141 / JRE / Библиотека / безопасность / cacerts».

    • Вам будет предложено ввести пароль. Введите пароль хранилища ключей: введите «changeit» еще раз для «Доверять этому сертификату? [No]:», введите «yes»

    Примеры команд командной строки / вывод:

    • Contgrats! Теперь вы должны были избавиться от ошибки «Ошибка построения пути PKIX: sun.security.provider.certpath.SunCertPathBuilderException» в вашей среде IDE Netbeans.

    Я хотел импортировать сертификат для smtp.gmail.com

    Единственное решение, сработавшее для меня, это 1. Введите команду для просмотра этого сертификата.

    D: openssl bin openssl.exe s_client -connect smtp.gmail.com:465

    Скопируйте и сохраните строки между «—— BEGIN CERTIFICATE ——» и «—— END CERTIFICATE ——» в файл gmail.cer

    keytool -import -alias smtp.gmail.com -keystore «% JAVA_HOME% / jre / lib / security / cacerts» -файл C: Users Admin Desktop gmail.cer

    Нажмите Да, чтобы импортировать сертификат

    Теперь запустите команду, и вы готовы идти

    Это не специфичный для Твиттера ответ, но этот вопрос возникает при поиске этой ошибки. Если ваша система получает эту ошибку при подключении к веб-сайту, который, по- видимому, имеет действительный сертификат при просмотре в веб-браузере , это, вероятно, означает, что веб-сайт имеет неполную цепочку сертификатов .

    Для краткого изложения проблемы: Центры сертификации не используют свой корневой сертификат для подписи только старого сертификата. Вместо этого они (обычно) подписывают промежуточное сертификаты, для которых также установлен флаг центра сертификации (то есть разрешено подписывать сертификаты). Затем, когда вы покупаете сертификат в ЦС, они подписывают ваш CSR одним из этих промежуточных сертификатов.

    Ваше хранилище доверия Java, скорее всего, имеет только Root Cert, а не промежуточные.

    Неправильно настроенный сайт может вернуть только подписанный сертификат. Проблема: она была подписана промежуточным сертификатом, которого нет в вашем хранилище доверенных сертификатов. Браузеры справятся с этой проблемой, загрузив или используя кэшированный промежуточный сертификат; это максимизирует совместимость сайта. Java и такие инструменты, как OpenSSL, однако, не будут. И это приведет к ошибке в вопросе.

    Вы можете проверить это подозрение с помощью Qualys SSL Test . Если вы запустите это против сайта, и он говорит

    Цепочка сертификатов этого сервера неполная.

    тогда это подтверждает. Вы также можете увидеть это, посмотрев пути сертификации и увидев текст Extra Download .

    Как это исправить: администратор сервера должен настроить веб-сервер так, чтобы он также возвращал промежуточные сертификаты. Например, для Comodo этот .ca-bundle файл пригодится. Например, в конфигурации Apache с mod_ssl вы должны использовать параметр SSLCertificateChainFile конфигурации. Для nginx необходимо объединить промежуточные сертификаты и подписанный сертификат и использовать его в конфигурации сертификата SSL. Вы можете найти больше путем поиска «неполной цепочки сертификатов» онлайн.

    Причина, по которой мы получаем вышеупомянутую ошибку, заключается в том, что JDK связан с большим количеством доверенных сертификатов Центра сертификации (CA) в файл с именем ‘cacerts’, но этот файл не имеет понятия о нашем самозаверяющем сертификате. Другими словами, файл cacerts не имеет импортированного нашего самозаверяющего сертификата и, таким образом, не обрабатывает его как доверенную сущность и, следовательно, выдает вышеуказанную ошибку.

    Чтобы исправить вышеуказанную ошибку, все, что нам нужно, это импортировать самоподписанный сертификат в файл cacerts.

    Сначала найдите файл cacerts. Нам нужно будет узнать местоположение JDK. Если вы запускаете приложение через одну из сред IDE, например Eclipse или IntelliJ Idea, перейдите в настройки проекта и выясните, где находится JDK. Например, в Mac OS типичное расположение файла cacerts будет в этом месте / Library / Java / JavaVirtualMachines / > / Contents / Home / jre / lib / security на компьютере Windows, оно будет находиться в > / > / JRE / Библиотека / безопасность

    Как только вы нашли файл cacerts, теперь нам нужно импортировать наш самоподписанный сертификат в этот файл cacerts. Проверьте последнюю статью, если вы не знаете, как правильно создать самозаверяющий сертификат.

    Если у вас нет файла сертификата (.crt) и у вас просто есть файл .jks, вы можете сгенерировать файл .crt с помощью следующей команды. Если у вас уже есть файл .crt / .pem, вы можете проигнорировать следующую команду

    ## Для генерации сертификата из хранилища ключей (файл .jks) ####

    Выше шаг будет генерировать файл с именем selfsigned.crt.Now Импортировать сертификат в cacerts

    Теперь добавьте сертификат в JRE / lib / security / cacerts (trustore)

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

Источник

Устранение неполадок, связанных с сертификатом

В файле журнала Google Cloud Directory Sync (GCDS) вы можете встретить следующие ошибки, связанные с сертификатом:

  • sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
  • ldap_simple_bind_s() failed: Strong Authentication Required

Чтобы устранить их, выполните указанные ниже инструкции.

Как устранить ошибки, связанные с сертификатами

Развернуть раздел  |  Свернуть все и перейти к началу

Шаг 1. Обновите файлы VMOPTIONS

Примечание. Если вы используете Linux, пропустите этот шаг и перейдите к шагу 2. 

  1. Закройте Диспетчер конфигураций.
  2. В каталоге установки GCDS откройте файлы sync-cmd.vmoptions и config-manager.vmoptions.

    Обычно он расположен по следующему пути: C:Program FilesGoogle Cloud Directory Sync.

  3. Добавьте в файлы следующие строки:

    -Djavax.net.ssl.trustStoreProvider=SunMSCAPI
    -Djavax.net.ssl.trustStoreType=Windows-ROOT
    -Dcom.sun.jndi.ldap.connect.pool.protocol=plain ssl
    -Dcom.sun.jndi.ldap.connect.pool.authentication=none simple

  4. Перезапустите Диспетчер конфигураций и перейдите на страницу LDAP Configuration (Конфигурация LDAP).
  5. Для настройки Connection type (Тип подключения) укажите LDAP+SSL.
  6. Для настройки Port (Порт) укажите 636 (если ранее использовали порт 389) или 3269 (если ранее использовали порт 3268).
  7. Нажмите Test connection (Проверить подключение).
  8. Если ошибка не исчезла, выполните указанные ниже действия.
    • На компьютере, на котором запущен инструмент GCDS, убедитесь, что сертификат является доверенным в Windows.
    • Если возникает ошибка, связанная с проверкой отзыва сертификата, ознакомьтесь с инструкциями из раздела Как GCDS проверяет списки отзыва сертификатов.
  9. Если ошибка продолжает появляться, перейдите к шагу 2. Если у вас возникают другие ошибки, например связанные с сетью, ознакомьтесь с инструкциями в статье Устранение неполадок в GCDS.

Шаг 2. Импортируйте сертификат сервера

С помощью этих инструкций вы также можете импортировать сертификаты с серверов LDAP или самозаверяющие сертификаты с прокси-серверов HTTP.

  1. Войдите в контроллер домена.
  2. Откройте окно командной строки (cmd.exe) или терминала.
  3. Введите команду certutil -store My DomainController dccert.cer.
  4. Скопируйте файл dccert.cer на сервер, где установлено приложение GCDS.
  5. Выполните вход на сервер, где установлено приложение GCDS.
  6. Откройте окно командной строки (cmd.exe) или терминала.

    На компьютере Windows убедитесь, что вы запустили окно командной строки как администратор.

  7. Чтобы перейти в каталог, где установлена среда выполнения Java (JRE) приложения GCDS, следуйте указанным ниже инструкциям.
    • Для Microsoft Windows: введите команду cd «c:Program FilesGoogle Cloud Directory Syncjre».
    • Если 32-разрядная версия GCDS установлена в 64-разрядной системе Windows, используйте команду cd «c:Program Files (x86)Google Cloud Directory Syncjre».
    • Для Linux: введите команду cd ~/GoogleCloudDirSync/jre.
  8. Чтобы импортировать сертификат контроллера домена, введите одну из следующих команд:
    • binkeytool -keystore libsecuritycacerts -storepass changeit -import -file c:dccert.cer -alias mydc (для Windows);
    • bin/keytool -keystore lib/security/cacerts -storepass changeit -import -file ~/dccert.cer -alias mydc (для Linux).

      Примечание. Если вам нужно импортировать несколько сертификатов, повторите эти шаги, используя другой псевдоним вместо mydc.

  9. Чтобы сделать сертификат доверенным, введите Yes (Да).
  10. Закройте Диспетчер конфигураций.
  11. В каталоге установки GCDS откройте файлы sync-cmd.vmoptions и config-manager.vmoptions.

    Обычно он расположен по следующему пути: C:Program FilesGoogle Cloud Directory Sync (Windows) или ~/GoogleCloudDirSync (Linux).

  12. В каждом файле удалите следующие строки:

    -Djavax.net.ssl.trustStoreProvider=SunMSCAPI
    -Djavax.net.ssl.trustStoreType=Windows-ROOT

    Примечание. После этого GCDS будет использовать сертификат, хранящийся в каталоге lib/security/cacerts, а не в системном хранилище Windows.

  13. Откройте Диспетчер конфигураций, перейдите на страницу LDAP Configuration (Конфигурация LDAP) и нажмите Test Connections (Протестировать соединения), чтобы проверить подключение к серверу LDAP.
  14. Если ошибки продолжают появляться, вместо сертификата контроллера домена импортируйте тот, что подписан центром сертификации вашей организации. Для этого выполните описанные выше действия с нужным сертификатом.

Как GCDS проверяет списки отзыва сертификатов

При подключении к API Google (через HTTPS) и серверу LDAP по протоколу SSL приложение GCDS проверяет сертификаты SSL. Для этого оно получает списки отзыва сертификатов из центров сертификации по протоколу HTTP. Иногда подключение установить не удается, потому что прокси-сервер или брандмауэр блокирует HTTP-запрос.

Проверьте, может ли сервер GCDS открыть следующие URL через HTTP (порт 80):

  • http://crl.pki.goog
  • http://crls.pki.goog

Сведения о текущих списках отзыва сертификатов приведены в разделе Проверка CRL. Если для LDAP через SSL вы используете собственные сертификаты, вам могут потребоваться дополнительные URL.

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

  1. В каталоге установки GCDS откройте файлы sync-cmd.vmoptions и config-manager.vmoptions.

    Обычно он расположен по следующему пути: C:Program FilesGoogle Cloud Directory Sync (Windows) или ~/GoogleCloudDirSync (Linux).

  2. Добавьте в файлы следующие строки:
    • -Dcom.sun.net.ssl.checkRevocation=false
    • -Dcom.sun.security.enableCRLDP=false

Медленная синхронизация после перехода на LDAP+SSL

Попробуйте выполнить следующие действия:

  1. Закройте Диспетчер конфигураций.
  2. В каталоге установки GCDS откройте файлы sync-cmd.vmoptions и config-manager.vmoptions, используя текстовый редактор.
    Примечание. Как правило, каталог установки расположен по следующему пути: C:Program FilesGoogle Cloud Directory Sync (Windows) или ~/GoogleCloudDirSync (Linux).
  3. Добавьте в файлы следующие строки:
    -Dcom.sun.jndi.ldap.connect.pool.protocol=plain ssl
    -Dcom.sun.jndi.ldap.connect.pool.authentication=none simple
  4. Сохраните файлы и снова запустите синхронизацию.

Проверьте, корректно ли выполняется аутентификация после обновления Microsoft ADV190023

Если вы используете Microsoft Active Directory с включенным связыванием каналов и подписыванием LDAP, вам необходимо принять меры, чтобы аутентификация GCDS выполнялась с использованием LDAP через SSL. В противном случае GCDS не будет подключаться к Active Directory и выполнить синхронизацию не удастся. Следуйте приведенным ниже инструкциям, даже если ранее запускали синхронизацию с помощью аутентификации через стандартный LDAP. Дополнительная информация об обновлении ADV190023 приведена в документации Microsoft.

Если вы уже используете сервер LDAP через SSL, дальнейших действий с вашей стороны не требуется.

Развернуть раздел  |  Свернуть все и перейти к началу

Шаг 1. Включите TLS в Active Directory

Шаг 2. Убедитесь, что сертификат является доверенным

Центр сертификации, подписывающий сертификат вашего контроллера домена, должен быть одобрен GCDS. Многие известные интернет-центры сертификации, такие как Verisign, Comodo и Let’s Encrypt, являются доверенными. Если вы используете их, пропустите этот шаг.

Если ваш центр сертификации не является доверенным или вы используете корневой центр сертификации, следуйте инструкциям в разделе Как устранить ошибки, связанные с сертификатами.

Шаг 3. Настройте Диспетчер конфигураций

  1. Откройте Диспетчер конфигураций и перейдите на страницу LDAP Configuration (Конфигурация LDAP).
  2. Для настройки Connection type (Тип подключения) укажите LDAP+SSL.
  3. Для настройки порта укажите 636 (если ранее использовали порт 389) или 3269 (если ранее использовали порт 3268).
  4. Нажмите Test connection (Проверить подключение).

Google, Google Workspace, а также другие связанные знаки и логотипы являются товарными знаками компании Google LLC. Все другие названия компаний и продуктов являются товарными знаками соответствующих компаний.

Эта информация оказалась полезной?

Как можно улучшить эту статью?

Источник

Author: Abhishek Bathwal

While developing some application, we might sometimes come across below error which the maven throws while building the application:

Reason: The error due to the system firewall. The system firewall restricts the application to connect to external unsecured systems. The firewall requires a valid certificate to allow access to the external systems.

Solution: The solution is very simple. We just need to install the required certificates of the external system in our system so the firewall allows us to interact with the external system and complete our process.

We are going to perform two activities:

  1. Download the Certificate.
  2. Install the Certificate.

To download the certificate, follow the below steps:

  1. Take the particular URL from the error and copy it to a browser (In the above error the url is https://repository.mulesoft.org/releases/).

  1. Now to the left of the URL there is a lock icon (). Click on this icon and a window will pop up. From the window, select the certificate.

  1. Once we select the certificate, it will redirect to another window. From there we have to select the Details tab and from the Details click on Copy to File. After clicking again, a new window will pop up. In that window, select next.

  1. After we perform all the above steps, we will be redirected to a new window where we need to select the format for the certificate. We will have to choose DER encoded binary and click on Next.

  1. Now we need to choose a location where we need to save the certificate and we also need to give some name to the certificate.

  1. Once a File name is given and saved, then select Next. It will direct us to another window showing the details. If all the details are correct, click on Finish. A export Success pop up will appear.

Note: I saved the File name as repo.

So, the downloading of certificates is done. Now the next process is to install the certificate in the cacerts file of the jdk installed in our system using the command line.

Installation of the Certificate from Command line:

Command for installation: keytool -importcert -trustcacerts -alias <alias name for the certificate> -file <path were we have save the certificate> -keystore “<path for the cacerts file>” -storepass changeit

For me the Command will be: keytool -importcert -trustcacerts -alias repo -file C:UsersDELLDesktoprepo.cer -keystore “C:Program FilesJavajdk1.8.0_131jrelibsecuritycarcets” -storepass changeit

Note: 

  1. I am using jdk1.8.0_131 so the cacerts file path for my system is “C:Program FilesJavajdk1.8.0_131jrelibsecuritycarcets”. It may differ for you based on your system and jdk version.
  2. I have given the alias name as repo and the path where I save my certificate is C:UsersDELLDesktoprepo.cer
To install the certificate, follow the below steps:
  1. Open Command Prompt as an Administrator and use the command for installation and press enter.

  1. Once the command is executed, it will ask for confirmation. Write Yes and the certificate will be installed with confirmation.

In the above process, we have downloaded and installed the certificate successfully in our system.

Now if we will execute the application it will not show certificate issues and will also download the required data from that particular system.

Thank you!

Источник


0 Flares



Twitter


0








Facebook


0








Google+


0








LinkedIn


0








Email


—








Filament.io






0 Flares


×

How To Fix Error : sun.security.validator.ValidatorException: PKIX path building failed:

sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

You could get the error “PKIX path building failed” validation error when working on a client that works with an SSL enabled server running in https protocol. This article focuses on detecting the root cause of the error and on how to fix the issue.
There are other similar issues related the SSL certificates. One of the common situation is the missing certificate in trust store. In that case you may see the following error message.

Caused by: java.security.cert.CertificateException: No name matching localhost found at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:210) at sun.security.util.HostnameChecker.match(HostnameChecker.java:77)

See the following article to read more about the above error and its solution.

    How to Fix : java.security.cert.CertificateException: No name matching localhost found

Table of Contents

  • What is PKIX?
  • How to Detect PKIX Path Building Failed Error?
  • Unable to Find Valid Certification Path to Requested Target: Possible Reason For The Error
  • Fix for PKIX path building failed Error:sun.security.provider.certpath.SunCertPathBuilderException
  • References

The first part of the error, “javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: “,  indicates the type of error and the second part of the error message “sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target” gives an indication on what exactly went wrong.
Before diving into the cause and solution let us get some general knowledge 🙂
java pkix path building validation

What is PKIX?

PKIX is Public-Key Infrastructure X.509. PKIX is public key infrastructure standards based on X.509 protocol. X.509 is an ITU-T cryptography standard for a public key infrastructure (PKI) and Privilege Management Infrastructure (PMI). Read references for more details on The PKIX (Public-Key Infrastructure X.509) Working Group (PKIX-WG).

PKIX path building failed : sun.security.validator.ValidatorException

This error is one of the many SSL related errors you may experience when you start developing applications those communicates securely. This happens during one of the SSL Handshake phase. This exception is of type javax.net.ssl.SSLHandshakeException,  which indicates that the client and server could not negotiate the desired level of security. The connection is no longer usable.
The complete exception message is below:

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

How to Detect PKIX Path Building Failed Error?

Even though this is a common exception while connecting a service over HTTPS,  identifying the exact problem without proper debugging configuration is difficult. Unless you enable the SSL handshake debug mode (Java VM parameter -Djavax.net.debug=ssl:handshake) you will not be able to identify the root cause. Without SSL debug enabled you most likely will see the following error.

javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)

The above message is more generic and in most cases will not give you the root cause of the issue. Once you enable SSL handshake debug mode you will see the following exception trace:

 http-localhost/127.0.0.1:8443-1, SEND TLSv1 ALERT: fatal, description = certificate_unknown
http-localhost/127.0.0.1:8443-1, WRITE: TLSv1 Alert, length = 2
http-localhost/127.0.0.1:8443-1, called closeSocket()
http-localhost/127.0.0.1:8443-1, 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
http-localhost/127.0.0.1:8443-1, called close()
http-localhost/127.0.0.1:8443-1, called closeInternal(true)

The above error indicates a missing trusted certificate in the trusted Java  store. Some other cases where,  you already have the certificate but there is a problem with its validity, you may see the following error (“timestamp check failed“).

handling exception: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: timestamp check failed.

We will be addressing the first scenario in which there is no certificate available (certificate_unknown).

Unable to Find Valid Certification Path to Requested Target: Possible Reason For The Error

If we look at the phase of the SSL handshake we’re in, we can see that we’ve already sent our client certificate and finishing up the handshake when we receive this error.

2015-02-04 21:59:33,002 INFO  [stdout] (http-localhost/127.0.0.1:8443-2) -  - *** ServerHelloDone
http-localhost/127.0.0.1:8443-2, WRITE: TLSv1 Handshake, length = 865
http-localhost/127.0.0.1:8443-1, READ: TLSv1 Handshake, length = 865
*** ServerHello, TLSv1
RandomCookie:  GMT: 1406265764 bytes = { 30, 87, 196, 168, 159, 159, 7, 254, 62, 168, 199, 80, 108, 117, 48, 3, 113, 72, 1, 226, 31, 195, 238, 86, 88, 192, 96, 94 }
Session ID:  {84, 210, 234, 164, 204, 121, 25, 56, 166, 145, 81, 180, 26, 103, 98, 72, 207, 54, 246, 139, 136, 17, 1, 140, 50, 131, 195, 18, 157, 80, 142, 4}
Cipher Suite: SSL_RSA_WITH_RC4_128_MD5
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: 
***
%% Created:  [Session-9, SSL_RSA_WITH_RC4_128_MD5]
** SSL_RSA_WITH_RC4_128_MD5
*** Certificate chain
Version: V3
Subject: CN=************************************
Signature Algorithm: SHA1withRSA, OID = *********************
Key:  Sun RSA public key, 2048 bits
.................................................
...................................................
***
SEND TLSv1 ALERT:  fatal, description = certificate_unknown
WRITE: TLSv1 Alert, length = 2
READ: TLSv1 Alert, length = 2
called closeSocket()
RECV TLSv1 ALERT:  fatal, certificate_unknown
called closeSocket()
handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown
handling exception: 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

The above error stack trace is actually helpful. It says that “unable to find valid certification path to requested target“. This means that the certificate the server certificate is not issued by certification authority, but a self signed or issued by a private CMS. If the certificate is issued by a trusted authority (VeriSign etc) the error will not happen.

Fix for PKIX path building failed Error:sun.security.provider.certpath.SunCertPathBuilderException

All you need to do to fix this error is to add the server certificate to your trusted Java key store. First You need to download the document from the server.

To download: access the URL of the service from any browser.You will get a certificate related warning message. Click on view certificate and then Install certificate. You can export the certificate from browser to some location in hard drive (In IE go to Tools->’Internet Options’ ->Content->Certificates).

Once you have the certificate in your hard drive you can import it to the Java trust store. To import the certificate to the trusted Java key store, you can use the java ‘keytool‘ tool.
Use keytool command as follows to import the certificate to JRE.

keytool -import -alias _alias_name_ -keystore ..libsecuritycacerts -file _path_to_cer_file

It will ask for a password. By default the password is “changeit”. If the password is different you may not be able to import the certificate.
Note: You can also use the installcert java program from here.
Once completed restart/re-run your client application. You will be able to see successful SSL handshakes.

References:

  1. X.509 Public-key and attribute certificate frameworks
  2. Internet X.509 Public Key Infrastructure Certificate and CRL Profile RFC 2459
  3. Import the Certificate as a Trusted Certificate 

Incoming search terms:

  • pkix path building failed
  • pkix validation failed
  • PKIXPathBuildingFailed(Validation):sun security validator ValidatorException
  • sun security validator ValidatorException: PKIX path building failed: sun security provider certpath SunCertPathBuilderException: unable to find valid certification path to requested target
  • https://java globinch com/enterprise-java/security/pkix-path-building-failed-validation-sun-security-validatorexception/
  • PKIX path building failed: sun security provider certpath SunCertPathBuilderException: unable to find valid certification path to requested target
  • feign RetryableException: PKIX path building failed: sun security provider certpath SunCertPathBuilderException:
  • pkix path validation failed: java security cert certpathvalidatorexception: validity check failed
  • dbviewer download driver javax net ssl SSLHandshakeException:PKIX
  • Couldnt download vanilla jar! sun security validator ValidatorException: PKIX path building failed: sun security provider certpath SunCertPathBuilderException: unable to find valid certification path to requested target


0 Flares



Twitter


0








Facebook


0








Google+


0








LinkedIn


0








Email


—








Filament.io






0 Flares


×

Источник

Понравилась статья? Поделить с друзьями:
  • Unable to find the vmx binary как исправить
  • Unable to find some essential data как исправить
  • Unable to find a compatible srs audio device как исправить
  • Unable to execute самп как исправить
  • Unable to execute samp как исправить