Знакомая ситуация: вы открываете сайт в Chrome или Safari — всё в порядке, замок закрыт, страница грузится. А мониторинг в это же время пишет «сертификат не доверен», и пара клиентов жалуется, что их приложение не может к вам подключиться. Кто прав?
Чаще всего правы оба. Браузер действительно открывает сайт. И мониторинг действительно видит проблему. Просто они проверяют сертификат по-разному. Разберёмся, почему так выходит, как это проверить самому и как починить за несколько минут.
Почему браузер «прощает», а мониторинг — нет
Сертификат сайта подписан не напрямую корневым удостоверяющим центром, а через промежуточный. Чтобы клиент поверил вашему сертификату, сервер должен отдать всю цепочку: ваш сертификат → промежуточный → (дальше клиент сам найдёт корневой в своём хранилище). Это и называется полной цепочкой.
Если сервер настроен так, что отдаёт только ваш сертификат без промежуточного, цепочка получается неполной. И тут начинается самое интересное.
Браузеры умеют выкручиваться. Получив сертификат без промежуточного, Chrome, Safari и Edge сами догружают недостающее звено по ссылке, зашитой внутри сертификата. Посетитель ничего не замечает — сайт открывается.
А вот строгие клиенты так не делают. Ваш мониторинг, утилита openssl, многие мобильные приложения, серверный код на Java, Python, Go, платёжные шлюзы и API-интеграции просто говорят «не могу построить цепочку доверия» и обрывают соединение. Типичная ошибка, которую они показывают, — certificate signed by unknown authority.
Чем это грозит на самом деле
Соблазн махнуть рукой: «в браузере же работает, значит и проблемы нет». Но неполная цепочка — это скрытая проблема, а не косметика.
Браузер у каждого посетителя разный. Кто-то заходит со свежего телефона, где недостающий промежуточный сертификат уже встречался раньше и сохранён в кэше, — у него всё открывается. А кто-то заходит с устройства, где этого звена нет, и докачать его по какой-то причине не удалось, — и он видит страшную красную страницу «подключение не защищено».
Ещё хуже с не-браузерным трафиком. Мобильное приложение, которое стучится в ваш API. Платёжный провайдер, который шлёт webhook. Партнёрская интеграция. Для них неполная цепочка — это глухая стена. Они не «выкручиваются», как браузер, а просто не подключаются. И жалобы прилетают не вам, а тому, кто пытался к вам достучаться.
Так что мониторинг, который видит ошибку, не врёт. Он показывает ровно то, что увидит строгий клиент. Просто он честнее браузера.
Как проверить свой сайт
Самый быстрый способ — одна команда в терминале:
openssl s_client -connect example.com:443 -servername example.com </dev/null
Подставьте свой домен вместо example.com. В ответе ищите строку про результат проверки. Если цепочка неполная, будет примерно так:
Verify return code: 20 (unable to get local issuer certificate)
Код 20 (или соседний 21 «unable to verify the first certificate») и текст unable to get local issuer certificate — это и есть «не хватает промежуточного сертификата». Если же всё в порядке, увидите Verify return code: 0 (ok).
Не любите терминал — подойдёт любой онлайн-чекер SSL. На неполной цепочке он напишет что-то вроде «chain is incomplete» или «extra download». Это тот же диагноз.
Как починить: добавить промежуточный сертификат
Чинится это на стороне сервера и обычно занимает пять минут. Идея простая: положить в один файл и ваш сертификат, и промежуточный — по порядку, сверху ваш.
Промежуточный сертификат даёт ваш удостоверяющий центр: он есть в письме о выпуске или в личном кабинете, где вы покупали сертификат. У Let's Encrypt такой файл уже идёт в комплекте и называется fullchain.pem — используйте именно его, а не cert.pem.
Если собираете вручную, склейте файлы по порядку:
cat your_domain.crt intermediate.crt > fullchain.crt
Дальше укажите получившийся файл в конфигурации сервера.
Для nginx — в директиве сертификата должна быть полная цепочка:
ssl_certificate /etc/ssl/fullchain.crt;
ssl_certificate_key /etc/ssl/private/your_domain.key;
Для Apache промежуточный сертификат указывают отдельно (в старых версиях) либо тоже одним файлом:
SSLCertificateFile /etc/ssl/your_domain.crt
SSLCertificateChainFile /etc/ssl/intermediate.crt
После правки перезагрузите веб-сервер и проверьте результат той же командой openssl — должно появиться Verify return code: 0 (ok).
Заодно стоит держать в курсе и срок действия сертификата, чтобы не ловить вторую беду на ровном месте. Про это — отдельный материал про оповещения об истечении сертификата.
Два режима проверки в Tracker.ru
Раньше любой строгий клиент (наш мониторинг в их числе) на неполной цепочке честно падал — и монитор уходил в «недоступен». Технически верно, но для владельца сайта это выглядело как ложная тревога: «у меня же открывается».
Теперь у каждого монитора есть выбор, как проверять сертификат. Настройка живёт в карточке монитора, в его параметрах.
Как в браузере — это режим по умолчанию. Монитор ведёт себя так же, как Chrome: догружает недостающее звено и не считает сайт упавшим только из-за неполной цепочки. Но он не молчит о проблеме. На карточке монитора появляется спокойный бейдж «проблема с сертификатом» — сайт зелёный, тревоги нет, а вы при этом видите, что есть что подкрутить.
Строгая — для тех, кому важны именно не-браузерные клиенты: мобильные приложения, API, интеграции. В этом режиме неполная цепочка считается отказом: монитор уходит в «недоступен» и присылает уведомление о падении выбранным каналом. Логика та же, что у строгого клиента: «не построил цепочку — значит, недоступен».
Важно понимать, что от настоящих проблем режим «как в браузере» не прячет. Истёкший сертификат, сертификат на чужой домен, самоподписанный или выписанный неизвестным центром — всё это уводит монитор в «недоступен» в обоих режимах. «Как в браузере» закрывает глаза только на ту единственную ситуацию, которую и браузер прощает, — на неполную, но достраиваемую цепочку.
Пример: монитор две недели «врал»
Реальный сценарий. Владелец сайта добавил его в мониторинг и две недели подряд видел сплошной «недоступен» — тысячи проверок, ни одной успешной. А в браузере сайт открывался без единого нарекания. Со стороны это выглядело как «ваш мониторинг сломан».
На деле сервер отдавал неполную цепочку: листовой сертификат без промежуточного. Браузеры это маскировали, наш мониторинг — нет.
Как только для монитора включили режим «как в браузере», картина встала на место. Монитор снова показал «работает» — но с честной пометкой о сертификате, чтобы проблему было видно. А владельцу пришло письмо о восстановлении: сайт снова в строю. Дальше уже его выбор — починить цепочку на сервере или оставить как есть, раз обычные посетители не страдают.
Попробуйте
Откройте список своих мониторов, зайдите в любой и найдите настройку проверки сертификата. По умолчанию там уже стоит «как в браузере» — тот режим, который совпадает с тем, что видят ваши посетители. Если среди ваших клиентов есть мобильные приложения или API-интеграции, имеет смысл переключить такой монитор на «строгую».
А чтобы вообще не возвращаться к этой теме внезапно, подключите мониторинг SSL-сертификата — он следит и за сроком действия, и за целостностью цепочки.
Частые вопросы
Если в браузере всё открывается, проблему вообще можно игнорировать?
Можно, если у вас только браузерные посетители и вы готовы к тому, что у части из них на новых устройствах сайт иногда не откроется. Но если к вам ходят мобильные приложения, API-клиенты или платёжные шлюзы — нет: для них неполная цепочка означает обрыв соединения.
Почему один и тот же сайт у одних работает, а у других нет?
Из-за кэша. Браузер, который недавно уже встречал нужный промежуточный сертификат, подставит его из памяти, и сайт откроется. Браузер «с чистого листа» докачать звено может не успеть или не суметь — и покажет ошибку. Полная цепочка убирает эту лотерею.
Режим «как в браузере» прячет реальные проблемы с сертификатом?
Нет. Истёкший сертификат, неверный домен, самоподписанный или недоверенный — это «недоступен» в любом режиме. «Как в браузере» закрывает глаза только на неполную, но достраиваемую цепочку, ровно как это делает сам браузер.
Чем «строгая» проверка отличается от обычного мониторинга?
Обычный мониторинг проверяет, что сайт отвечает. Строгая проверка сертификата дополнительно требует, чтобы цепочка доверия собиралась полностью, без догрузки. Это ближе к тому, как видят ваш сайт не-браузерные клиенты.
См. также
- Мониторинг SSL-сертификата — проверка срока действия и целостности цепочки при каждой проверке сайта.
- Из чего складывается время ответа сайта — про этап TLS-рукопожатия и другие стадии соединения.
- Что делать, если сайт недоступен — как мониторинг отличает реальное падение от ложной тревоги.