Если SSL-сертификат еще действует, владелец сайта обычно ожидает, что HTTPS будет работать без сюрпризов. На практике ошибка может появиться не только из-за истекшего срока. Иногда проблема находится в цепочке сертификата: браузер или приложение не может построить доверенный путь от сертификата домена до корневого центра сертификации.
Такая ситуация особенно неприятна тем, что сайт может открываться у владельца, но не открываться у части клиентов: на старом смартфоне, в корпоративной сети, через отдельного провайдера или после изменений на CDN. Ниже разберем, что такое цепочка SSL-сертификата, какие признаки у этой ошибки и как проверить сайт до того, как жалобы начнут приходить от посетителей.
Почему HTTPS может сломаться при действующем сертификате
SSL-сертификат для домена не работает сам по себе. При открытии сайта сервер показывает не только сертификат `example.ru`, но и промежуточные сертификаты. Они помогают браузеру убедиться, что сертификат домена действительно выдан доверенным центром сертификации.
Упрощенно цепочка выглядит так:
```text Сертификат сайта -> промежуточный сертификат -> корневой сертификат ```
Если один из элементов отсутствует, выбран неправильно или не поддерживается устройством пользователя, браузер может показать ошибку HTTPS. При этом в панели хостинга сертификат будет выглядеть действующим, а автоматическое продление могло пройти без ошибок.
Что чаще всего ломается
На практике проблемы с цепочкой появляются в нескольких сценариях:
- на сервер установили `cert.pem` вместо полного `fullchain.pem`;
- после переезда сайта на новый хостинг скопировали только сертификат домена, но забыли промежуточные сертификаты;
- CDN или прокси использует свой набор сертификатов и по-разному обслуживает разные регионы;
- часть посетителей использует старые устройства, устаревшие браузеры или корпоративные прокси;
- после перевыпуска сертификата изменилась цепочка доверия, а конфигурацию сервера не проверили.
Главный вывод: срок действия сертификата важен, но это не единственная проверка. Для надежного HTTPS нужно смотреть и срок, и домен, и полноту цепочки.
Инфоповод: почему о цепочке сертификата снова говорят
2 июня 2026 года на странице статуса Cloudflare был опубликован инцидент `Issue with TLS certificates using Lets Encrypt CA`: сервис сообщил о проблеме, которая затрагивала часть сертификатов Let's Encrypt и могла приводить к ошибкам TLS-соединения у некоторых посетителей. В тот же период агрегатор Downflare также показывал этот инцидент среди открытых событий Cloudflare.
Это не означает, что каждый сайт на Let's Encrypt был недоступен. Инфоповод важен по другой причине: он напоминает, что HTTPS зависит не только от вашего сервера и даты окончания сертификата. В цепочке участвуют центр сертификации, промежуточные сертификаты, CDN, браузер пользователя и доверенное хранилище операционной системы.
Как понять, что проблема именно в цепочке
Ошибка цепочки часто выглядит как обычная проблема HTTPS, поэтому ее легко спутать с истекшим сертификатом. Обратите внимание на такие признаки:
- сайт открывается в одном браузере, но не открывается в другом;
- на новом телефоне все работает, а на старом появляется предупреждение о недоверенном сертификате;
- проверка из одного региона проходит успешно, а из другого показывает TLS-ошибку;
- `curl` или серверный мониторинг сообщает `unable to get local issuer certificate`, `certificate verify failed` или похожую ошибку;
- после смены хостинга, CDN или панели управления HTTPS начал вести себя нестабильно.
Как проверить цепочку SSL-сертификата вручную
Начните с простых действий. Они не требуют глубокого администрирования и помогают понять направление поиска.
1. Проверьте сайт в браузере
Откройте сайт в режиме инкогнито и нажмите на значок замка рядом с адресом. Посмотрите, на какой домен выдан сертификат, действителен ли он и есть ли предупреждения в цепочке. Если браузер показывает только общую ошибку, проверьте тот же адрес в другом браузере или на другом устройстве.
2. Проверьте полный адрес, а не только домен
Убедитесь, что HTTPS работает для всех важных вариантов:
- `https://example.ru/`;
- `https://www.example.ru/`;
- страницы после редиректа;
- поддомены, если они используются в рекламе, CRM, оплате или личном кабинете.
Иногда сертификат корректен для основного домена, но не покрывает `www` или отдельный поддомен. Для посетителя это выглядит как поломка сайта, хотя на главной странице все может быть в порядке.
3. Используйте командную проверку
Если есть доступ к терминалу, можно посмотреть, какую цепочку отдает сервер:
```bash openssl s_client -connect example.ru:443 -servername example.ru -showcerts ```
В выводе важно проверить не только дату окончания, но и наличие промежуточных сертификатов. Если вы видите только сертификат домена, а промежуточной части нет, веб-сервер может быть настроен неполно.
Для Nginx типичная ошибка выглядит так: в `ssl_certificate` указывают файл с одним сертификатом домена, хотя обычно нужен файл полной цепочки. Часто это `fullchain.pem`, но точное имя зависит от панели, хостинга и способа выпуска сертификата.
4. Проверьте CDN и прокси отдельно
Если сайт работает через CDN, важно понимать, где завершается TLS-соединение. Ошибка может быть не на origin-сервере, а на edge-уровне. Проверьте:
- какой сертификат видит посетитель снаружи;
- какой сертификат установлен на сервере-источнике;
- не включен ли режим, при котором CDN принимает нестрогую схему HTTPS до origin;
- не отличается ли поведение для разных регионов.
Чем опасна такая ошибка для сайта и SEO
Проблема с HTTPS сразу бьет по доверию. Посетитель может увидеть предупреждение браузера и закрыть страницу до загрузки контента. Для интернет-магазина это означает потерянные корзины, для сервиса - сорванную авторизацию, для корпоративного сайта - заявки, которые не дошли до формы.
Для SEO риск тоже практический. Если поисковый робот в момент обхода получает TLS-ошибку, он не может нормально забрать страницу. Один короткий сбой не обязательно приводит к санкциям, но повторяющаяся недоступность мешает стабильному сканированию и ухудшает качество сигналов о сайте.
Поэтому SSL стоит контролировать так же регулярно, как доступность главной страницы и ключевых посадочных страниц.
Почему автоматический мониторинг помогает раньше заметить проблему
Ручная проверка работает только в момент, когда вы о ней вспомнили. Автоматический мониторинг проверяет сайт регулярно и помогает поймать проблему до массовых жалоб.
Для SSL полезно отслеживать несколько вещей:
- доступен ли сайт по HTTPS;
- какой HTTP-статус возвращает страница;
- не появились ли TLS-ошибки;
- не подходит ли срок окончания сертификата;
- открываются ли важные страницы после редиректов.
В Web-Puls можно проверять доступность сайта и использовать проверку SSL, чтобы быстрее заметить проблему с HTTPS. Например, если после смены хостинга сертификат установлен неполно, мониторинг поможет увидеть ошибку не через неделю, а после очередной проверки.
Для быстрой ручной диагностики можно открыть проверку SSL или проверку доступности сайта. А если сайт важен для продаж или заявок, лучше добавить его в регулярный мониторинг, чтобы не зависеть от случайных ручных проверок.
Когда нужна профессиональная помощь
Если ошибка связана только с просроченным сертификатом, ее часто можно решить через панель хостинга. Но при проблемах с цепочкой приходится разбираться глубже: смотреть конфигурацию веб-сервера, CDN, DNS, редиректы и сертификаты на origin-сервере.
Обратитесь за помощью, если:
- ошибка видна только у части клиентов;
- сайт работает через CDN, но origin настроен отдельно;
- после перевыпуска сертификата HTTPS не восстановился;
- нет доступа к серверу или непонятно, какой файл сертификата использует веб-сервер;
- проблема влияет на оплату, формы заявок или рекламный трафик.
Если проблему нужно не только заметить, но и разобрать технически, можно отправить заявку на профессиональную поддержку через форму Web-Puls или воспользоваться контактной информацией. В заявке достаточно указать домен, описать ошибку и написать, у каких пользователей она проявляется.
Вывод
Действующий SSL-сертификат еще не гарантирует, что HTTPS работает корректно для всех посетителей. Если сайт открывается не у всех, а браузеры показывают ошибку доверия, проверьте цепочку сертификата, настройки CDN и полный набор доменов.
Лучший подход - не ждать жалоб, а регулярно проверять сайт снаружи. Так владелец быстрее видит, что HTTPS сломался, понимает масштаб проблемы и может вовремя передать задачу администратору или поддержке.
Источники для контекста
- Cloudflare Status: инцидент `Issue with TLS certificates using Lets Encrypt CA`, 2 июня 2026 года - https://www.cloudflarestatus.com/
- Downflare: агрегированная история инцидентов Cloudflare - https://downflare.online/
- Let's Encrypt: Chains of Trust - https://letsencrypt.org/certificates/
- Cloudflare SSL/TLS docs: Bundle methodologies - https://developers.cloudflare.com/ssl/edge-certificates/custom-certificates/bundling-methodologies/