Приходилось ли работать с сертификатами в автотестах?
Что проверяют
Работали ли вы с HTTPS-стендом руками или только открывали готовый адрес. За вопросом обычно стоит боль команды: тесты падают на самоподписанном сертификате, кто-то глушит проверку целиком, и стенд перестаёт отличаться от дырявого.
Как отвечать
Разложите на три случая.
- Доверие к серверу. Стенд с самоподписанным или внутренним корневым сертификатом требует, чтобы этот корень лежал в хранилище того, кто ходит: у JVM своё хранилище и
keytool -importcert, либо флаг-Djavax.net.ssl.trustStore, у браузера своё, у curl и Node свои переменные окружения. Одна машина может доверять сертификату в браузере и не доверять в тестах. - Клиентский сертификат (mTLS). Ключ и цепочка в
.p12или.jks, пароль из секретов CI, в HTTP-клиенте настраивается keystore, в Java этоSSLContextсKeyManager. - Отладка.
openssl s_client -connect host:443 -showcertsпоказывает цепочку, срок и SAN быстрее, чем гадание по стектрейсу.
Дальше скажите, что именно проверяете тестами: редирект с HTTP на HTTPS, отсутствие смешанного контента, заголовок HSTS, отказ соединения по устаревшим версиям TLS. Срок действия сертификата уместнее вынести в мониторинг, а не в UI-тесты. Про инструменты перехвата трафика добавьте, что они работают только после установки корневого сертификата прокси в доверенные.
Где спотыкаются
Глобально отключают проверку: приём небезопасных сертификатов в драйвере, игнор ошибок TLS в HTTP-клиенте. Для локального стенда это законно, но если флаг уехал в прогон против предпрода, тесты перестают ловить просроченный сертификат и неверный SAN.
Путают три разные ошибки. Невозможность построить цепочку это про хранилище доверенных корней, несовпадение имени про SAN, обрыв рукопожатия про версию протокола или набор шифров. На любую из них кандидат отвечает «добавил сертификат в систему».
Кладут .p12 и пароль к нему в репозиторий рядом с тестами. И забывают про срок: сертификат стенда протухает, красным становится весь прогон разом, а в отчёте видно только обрыв соединения.