В этом материале
HTTPS может работать на хосте и падать в контейнере из-за разных trust stores. Проверьте CA bundle образа и серверную цепочку, включая intermediates. Установка сертификата на хост не гарантирует доверие внутри приложения, а verify=false лишь скрывает необходимую проверку.
HTTPS может работать на хосте и падать в контейнере из-за разных trust stores. Проверьте CA bundle образа и серверную цепочку, включая intermediates. Установка сертификата на хост не гарантирует доверие внутри приложения, а verify=false лишь скрывает необходимую проверку.
Установите точную ошибку
Сохраните имя сервиса, время, клиентскую библиотеку и текст ошибки. Отличите неизвестный issuer, несовпадение имени, просроченный сертификат и сетевой timeout. Сравнение проводите к одному endpoint из хоста и контейнера, учитывая proxy settings. В корпоративной сети TLS может завершаться на проверяющем proxy с собственным CA. Его использование требует доверенного основания, а не импорта любого сертификата, который удалось скачать из неуспешного соединения.
Проверьте trust store образа
Минимальный образ может не содержать пакет CA certificates или использовать устаревший bundle. Некоторые приложения используют отдельное хранилище, отличное от системного. Найдите documented trust configuration конкретного клиента, не подменяя её предположением о пути Linux. Сохраните базовый image digest и источник обновления CA. Runtime-добавление сертификата в контейнер может помочь диагностике, но исчезает при пересоздании; устойчивое исправление должно быть частью управляемого образа или предусмотренного механизма конфигурации.
Сравните серверную цепочку
Сервер должен передавать подходящую цепочку промежуточных сертификатов в нужном порядке. Хостовый клиент иногда располагает недостающими intermediates, которых нет в минимальной среде; это не делает неполную server chain корректной. В учебном тесте один клиент успешно строит доверие, другой сообщает unknown issuer. Сначала сравните полученные leaf и intermediates, затем доверенные roots. Не устанавливайте leaf как универсально доверенный root только ради быстрого исчезновения сообщения.
| Артефакт | Назначение |
|---|---|
| Peer chain | Что действительно отправил сервер |
| CA bundle source | Откуда взялось доверие клиента |
| Image digest | Какая среда проверена |
| Proxy configuration | Нет ли другого TLS peer |
Исправьте управляемую сторону
Если дефект в server chain, восстановите intermediates на TLS endpoint. Если нужен внутренний доверенный CA, добавьте проверенный сертификат в соответствующий trust store и обновите bundle документированным способом для выбранного образа. Пример Docker с apt относится к Ubuntu-подобной среде и не переносится буквально на любой дистрибутив. Секретный private key сервера для этой операции не требуется. Проверьте, что приложение действительно использует обновлённое хранилище, а не собственный старый файл.
Проверьте пересоздание
Создайте новый контейнер из исправленного image/configuration и выполните запрос с включённой проверкой имени и цепочки. Сохраните результат и причину выбора CA без раскрытия лишних внутренних данных. Затем повторите обычный deployment lifecycle: исправление не должно зависеть от ручной команды в давно живущем контейнере. Если ошибка остаётся только у одного клиента, исследуйте его trust settings отдельно. Успешный host curl служит контрольным наблюдением, но не доказательством идентичной конфигурации всех контейнерных приложений.
Связанные разборы: gpu containers vs vms; software stack reproducibility.