Браузер доверяет сайту, curl нет: проверяем неполную цепочку TLS

После обновления сертификата сайт открывается в браузере, а серверный curl сообщает о невозможности проверить издателя. Копировать сертификат сайта в доверенные корни рано. Веб-сервер мог отправлять только конечный сертификат без промежуточного. Браузер иногда уже имеет недостающий intermediate, а минимальный клиент — нет.

Получите то, что отправляет сервер

openssl s_client -connect app.example:443 -servername app.example -showcerts -verify_return_error -verify_hostname app.example

servername передаёт имя для выбора виртуального TLS-хоста. verify_hostname задаёт проверку имени, а verify_return_error позволяет прервать соединение при ошибке проверки. Обычный s_client без строгих параметров может продолжить работу после диагностического сообщения, поэтому сам факт установленного сеанса ещё не означает успешное доверие.

showcerts выводит сертификаты, присланные сервером. Это не готовая доказанная цепочка и не весь набор доверенных сертификатов клиента. Посмотрите subject и issuer каждого элемента. Конечный сертификат должен связываться с нужным intermediate, а далее — с доверенным корнем клиента.

Различите две причины

Если конечный сертификат выдан промежуточным центром, но соответствующего сертификата в серверной выдаче нет, проверьте настройку full chain у владельца сервера. Корневой сертификат обычно не требуется отправлять: доверие к нему должно уже существовать у клиента. Добавление корня в серверную цепочку не заставляет клиента ему доверять.

Если промежуточные сертификаты отправляются правильно, а центр частный, клиенту может требоваться утверждённый корпоративный корень. Для точечной проверки используйте CA-файл, полученный по доверенному каналу:

curl --cacert company-root.pem --connect-timeout 5 --max-time 15 https://app.example/health

Не скачивайте «доверенный корень» с того же непроверенного сайта и не принимайте его автоматически. Иначе вы используете сомнительную сторону для подтверждения её собственной подлинности. Источник CA-файла должен быть частью управляемой инфраструктуры организации.

Исправьте сторону, которая нарушает контракт

Неполную серверную цепочку исправляют на точке TLS-терминации. Частный доверенный центр добавляют в предназначенное клиентское хранилище либо задают приложению явно. Отдельно проверьте срок действия и имя: корректная цепочка не исправляет просроченный сертификат или несовпадение домена.

Уточните, какой TLS-backend использует curl и какое хранилище CA он читает. На разных системах браузер, OpenSSL и curl могут иметь разные наборы доверия. Сравнивать их результаты полезно, но нельзя считать браузер окончательным доказательством полноценной серверной выдачи.

После исправления повторите строгую проверку s_client и curl без временных обходов. Убедитесь, что тест попал на тот же внешний вход: балансировщик и backend могут отдавать разные сертификаты. Сохраните fingerprints и дату проверки для следующей ротации.

Продолжите от сертификата к диагностике всего HTTP-пути. Откройте программу Linux и Bash для DevOps-инженеров. Практика сети, DNS и HTTP помогает проверять сервис по слоям и выбирать исправление на той стороне, где возникла причина.

Ещё по теме

• Тестируем отдельный backend по HTTPS: curl --connect-to сохраняет имя сервиса
• mTLS в curl: где сертификат клиента, где ключ, а где доверие к серверу