В интеграционном тесте отключена проверка TLS-сертификата внешнего API, и запросы проходят успешно. Какой дефект клиента такая настройка может скрыть?
Такая настройка может скрыть дефект проверки подлинности внешнего сервиса: клиент не обнаружит недоверенный, просроченный сертификат или сертификат, выданный для другого имени хоста. В результате тест проверяет только обмен данными, но не подтверждает, что соединение установлено именно с ожидаемым сервером.
TLS появился для защиты соединения от перехвата и подмены узла. Одной шифрации канала недостаточно: клиенту нужно проверить, кому принадлежит сертификат и можно ли доверять цепочке сертификации.
Проверка сертификата опирается на доверенный центр сертификации, срок действия сертификата и соответствие имени сервера указанному в сертификате. Отключение этой проверки иногда используют в локальной разработке, но оно удаляет важную часть поведения реального клиента.
Если интеграционный тест отключает проверку сертификата, он может успешно пройти при неправильном адресе внешнего сервиса, подменённом endpoint-е или ошибочной настройке доверия. Такой дефект проявится только в окружении, где проверка TLS включена, например в промышленной среде.
Это особенно опасно для платёжных, идентификационных и административных интеграций. Клиент может установить зашифрованное соединение с неизвестным узлом, хотя приложение будет считать зависимость доступной и надёжной.
Интеграционный тест должен выполнять соединение с включённой проверкой TLS. Для тестового окружения обычно создают контролируемый сертификат и добавляют его тестовый центр сертификации в доверенное хранилище клиента, не отключая саму валидацию.
Проверяются как минимум успешное соединение с корректным сертификатом и отказ при нарушении доверия или несовпадении имени хоста. Проверка сертификата сервера не заменяет проверку mTLS: если интеграция требует взаимной аутентификации, отдельно проверяют наличие и корректность клиентского сертификата.
Важно не подменять TLS-проверку проверкой бизнес-ответа. Сервер может вернуть корректный JSON, но это не доказывает, что клиент подключился к правильному узлу. Одновременно тест не должен зависеть от публичного центра сертификации или реального внешнего сервиса: контролируемый тестовый центр сертификации делает проверку воспроизводимой.
Команда тестировала клиент, обращающийся к API партнёра, и отключила проверку сертификата, поскольку в тестовой сети использовался внутренний центр сертификации. Вариант с отключением был простым, но скрывал ошибки доверия и мог закрепить небезопасную настройку клиента.
Использование промышленного сертификата сделало бы тест зависимым от сроков его действия и внешней инфраструктуры. Поэтому выбрали отдельный тестовый центр сертификации, выпустили сертификат на тестовое имя API и настроили клиент доверять только этому центру.
После этого положительная проверка подтвердила рабочее соединение, а отрицательная — отказ при сертификате для другого имени. Тест стал выявлять ошибочную настройку TLS, оставаясь изолированным и детерминированным.
Нет. Нужно также проверить соответствие имени хоста сертификату и срок его действия. Сертификат от доверенного центра, выданный для другого узла, не подтверждает подлинность целевого API.
Нет. Успешный TLS лишь подтверждает защищённое соединение с аутентифицированным узлом на транспортном уровне. Отдельно нужны проверки HTTP-контракта, авторизации, формата данных и бизнес-ошибок.
Это допустимо, если такое поведение соответствует целевой среде, но тест может стать зависимым от состава и состояния конкретной машины. Для управляемой проверки часто используют отдельное тестовое хранилище с явно заданным доверенным центром, сохраняя при этом настоящую валидацию цепочки и имени хоста.