Полное руководство по решению проблемы "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) протокола.

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.

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

#автоматизированное #java #api #ssl #https

Ознакомьтесь с последними публикациями