SSL и сертификаты · 5 мин · обновлено 2026-08-28

Цепочка SSL-сертификата: почему сайт не открывается, хотя сертификат действителен

Если срок SSL еще не истек, а посетители видят ошибку HTTPS, проверьте не только домен, но и цепочку сертификата: промежуточные сертификаты, настройки CDN и совместимость клиентов.

Если SSL-сертификат еще действует, владелец сайта обычно ожидает, что HTTPS будет работать без сюрпризов. На практике ошибка может появиться не только из-за истекшего срока. Иногда проблема находится в цепочке сертификата: браузер или приложение не может построить доверенный путь от сертификата домена до корневого центра сертификации.

Такая ситуация особенно неприятна тем, что сайт может открываться у владельца, но не открываться у части клиентов: на старом смартфоне, в корпоративной сети, через отдельного провайдера или после изменений на CDN. Ниже разберем, что такое цепочка SSL-сертификата, какие признаки у этой ошибки и как проверить сайт до того, как жалобы начнут приходить от посетителей.

Почему HTTPS может сломаться при действующем сертификате

SSL-сертификат для домена не работает сам по себе. При открытии сайта сервер показывает не только сертификат example.ru, но и промежуточные сертификаты. Они помогают браузеру убедиться, что сертификат домена действительно выдан доверенным центром сертификации.

Упрощенно цепочка выглядит так:

Сертификат сайта -> промежуточный сертификат -> корневой сертификат

Если один из элементов отсутствует, выбран неправильно или не поддерживается устройством пользователя, браузер может показать ошибку HTTPS. При этом в панели хостинга сертификат будет выглядеть действующим, а автоматическое продление могло пройти без ошибок.

Что чаще всего ломается

На практике проблемы с цепочкой появляются в нескольких сценариях:

на сервер установили cert.pem вместо полного fullchain.pem;
после переезда сайта на новый хостинг скопировали только сертификат домена, но забыли промежуточные сертификаты;
CDN или прокси использует свой набор сертификатов и по-разному обслуживает разные регионы;
часть посетителей использует старые устройства, устаревшие браузеры или корпоративные прокси;
после перевыпуска сертификата изменилась цепочка доверия, а конфигурацию сервера не проверили.

Главный вывод: срок действия сертификата важен, но это не единственная проверка. Для надежного HTTPS нужно смотреть и срок, и домен, и полноту цепочки.

Инфоповод: почему о цепочке сертификата снова говорят

2 июня 2026 года на странице статуса Cloudflare был опубликован инцидент Issue with TLS certificates using Lets Encrypt CA: сервис сообщил о проблеме, которая затрагивала часть сертификатов Let's Encrypt и могла приводить к ошибкам TLS-соединения у некоторых посетителей.

Это не означает, что каждый сайт на Let's Encrypt был недоступен. Инфоповод важен по другой причине: он напоминает, что HTTPS зависит не только от вашего сервера и даты окончания сертификата. В цепочке участвуют центр сертификации, промежуточные сертификаты, CDN, браузер пользователя и доверенное хранилище операционной системы.

Как понять, что проблема именно в цепочке

Ошибка цепочки часто выглядит как обычная проблема HTTPS, поэтому ее легко спутать с истекшим сертификатом. Обратите внимание на такие признаки:

сайт открывается в одном браузере, но не открывается в другом;
на новом телефоне все работает, а на старом появляется предупреждение о недоверенном сертификате;
проверка из одного региона проходит успешно, а из другого показывает TLS-ошибку;
curl или серверный мониторинг сообщает unable to get local issuer certificate, certificate verify failed или похожую ошибку;
после смены хостинга, CDN или панели управления HTTPS начал вести себя нестабильно.

Почему HTTPS работает на Windows, но ломается у другого клиента

Успешное открытие сайта на одном компьютере не доказывает, что сервер отдает полную цепочку. TLS-клиент строит путь доверия из сертификатов, полученных от сервера, и собственного хранилища. На одном устройстве нужный промежуточный или корневой сертификат уже может быть доступен в локальном хранилище, а на другом — нет. В результате один клиент строит доверенный путь, а другой останавливается на ошибке проверки.

Есть и другая причина расхождения: для одного сертификата иногда существует несколько допустимых цепочек через разные корневые сертификаты. Let's Encrypt отдельно описывает такие варианты и указывает, что совместимость зависит от устройств и trust stores. Поэтому сравнивайте не только браузеры, но и фактически построенную цепочку.

Практический порядок проверки:

Получите цепочку от сервера с правильным SNI через openssl s_client.
Убедитесь, что сервер отдает сертификат домена и необходимые промежуточные сертификаты, а не рассчитывает на кеш клиента.
Отдельно выполните fail-closed проверку доверия и имени хоста. Чистый профиль браузера не очищает системное хранилище сертификатов, поэтому он подходит только как дополнительный тест.
Повторите проверку с мобильного устройства, независимого серверного probe и, при необходимости, с явно заданным OpenSSL-хранилищем через -CAfile или -CApath.
Если результаты различаются, запишите клиент, ОС, время, hostname и текст ошибки; не заменяйте это выводом «у меня открывается».
После исправления повторите тест на клиентах, где ошибка была видна, и проверьте CDN/origin раздельно.

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

Как проверить цепочку SSL-сертификата вручную

Начните с простых действий. Они не требуют глубокого администрирования и помогают понять направление поиска.

1. Проверьте сайт в браузере

Откройте сайт в режиме инкогнито и нажмите на значок замка рядом с адресом. Посмотрите, на какой домен выдан сертификат, действителен ли он и есть ли предупреждения в цепочке. Если браузер показывает только общую ошибку, проверьте тот же адрес в другом браузере или на другом устройстве.

2. Проверьте полный адрес, а не только домен

Убедитесь, что HTTPS работает для всех важных вариантов:

https://example.ru/;
https://www.example.ru/;
страницы после редиректа;
поддомены, если они используются в рекламе, CRM, оплате или личном кабинете.

Иногда сертификат корректен для основного домена, но не покрывает www или отдельный поддомен. Для посетителя это выглядит как поломка сайта, хотя на главной странице все может быть в порядке.

3. Используйте командную проверку

Если есть доступ к терминалу, сначала посмотрите, какие сертификаты отдает сервер:

openssl s_client -connect example.ru:443 -servername example.ru -showcerts </dev/null

Опция -showcerts отвечает только на вопрос «что прислал сервер». Она не доказывает, что клиент построил доверенную цепочку и проверил имя хоста. Для fail-closed проверки добавьте остановку при ошибке и проверку hostname:

openssl s_client -connect example.ru:443 \
  -servername example.ru -showcerts \
  -verify_return_error -verify_hostname example.ru </dev/null

По умолчанию команда использует доступное OpenSSL хранилище доверия. Чтобы воспроизвести конкретную среду, явно задайте -CAfile или -CApath. В выводе проверяйте код верификации, имя хоста и наличие промежуточных сертификатов. Если сервер присылает только сертификат домена, конфигурация может быть неполной, даже если отдельный браузер открывает сайт.

Для Nginx типичная ошибка выглядит так: в ssl_certificate указывают файл с одним сертификатом домена, хотя обычно нужен файл полной цепочки. Часто это fullchain.pem, но точное имя зависит от панели, хостинга и способа выпуска сертификата.

4. Проверьте CDN и прокси отдельно

Если сайт работает через CDN, важно понимать, где завершается TLS-соединение. Ошибка может быть не на origin-сервере, а на edge-уровне. Проверьте:

какой сертификат видит посетитель снаружи;
какой сертификат установлен на сервере-источнике;
не включен ли режим, при котором CDN принимает нестрогую схему HTTPS до origin;
не отличается ли поведение для разных регионов.

Если Cloudflare в режиме Full (strict) доходит до origin, но не может подтвердить его сертификат, проверьте отдельную инструкцию про ошибку 526 Invalid SSL Certificate.

Чем опасна такая ошибка для сайта и SEO

Проблема с HTTPS сразу бьет по доверию. Посетитель может увидеть предупреждение браузера и закрыть страницу до загрузки контента. Для интернет-магазина это означает потерянные корзины, для сервиса - сорванную авторизацию, для корпоративного сайта - заявки, которые не дошли до формы.

Для SEO риск тоже практический. Если поисковый робот в момент обхода получает TLS-ошибку, он не может нормально забрать страницу. Один короткий сбой не обязательно приводит к санкциям, но повторяющаяся недоступность мешает стабильному сканированию и ухудшает качество сигналов о сайте.

Поэтому SSL стоит контролировать так же регулярно, как доступность главной страницы и ключевых посадочных страниц.

Почему автоматический мониторинг помогает раньше заметить проблему

Ручная проверка работает только в момент, когда вы о ней вспомнили. Автоматический мониторинг проверяет сайт регулярно и помогает поймать проблему до массовых жалоб.

Для SSL полезно отслеживать несколько вещей:

доступен ли сайт по HTTPS;
какой HTTP-статус возвращает страница;
не появились ли TLS-ошибки;
не подходит ли срок окончания сертификата;
открываются ли важные страницы после редиректов.

В Web-Puls можно проверять доступность сайта и использовать проверку SSL, чтобы быстрее заметить проблему с HTTPS. Например, если после смены хостинга сертификат установлен неполно, мониторинг поможет увидеть ошибку не через неделю, а после очередной проверки.

Для ручной диагностики полезно сопоставить результат проверки SSL с ответом проверки доступности сайта: первая показывает состояние сертификата, вторая — доступность конкретного HTTPS-адреса и редиректы.

Когда нужна профессиональная помощь

Если ошибка связана только с просроченным сертификатом, ее часто можно решить через панель хостинга. Но при проблемах с цепочкой приходится разбираться глубже: смотреть конфигурацию веб-сервера, CDN, DNS, редиректы и сертификаты на origin-сервере.

Обратитесь за помощью, если:

ошибка видна только у части клиентов;
сайт работает через CDN, но origin настроен отдельно;
после перевыпуска сертификата HTTPS не восстановился;
нет доступа к серверу или непонятно, какой файл сертификата использует веб-сервер;
проблема влияет на оплату, формы заявок или рекламный трафик.

Для диагностики подготовьте домен, точный текст TLS-ошибки, проблемные клиенты и вывод проверки цепочки. Эти данные позволяют отличить неполный bundle от несовместимой цепочки, ошибки CDN или неверного сертификата на origin.

Вывод

Действующий SSL-сертификат еще не гарантирует, что HTTPS работает корректно для всех посетителей. Если сайт открывается не у всех, а браузеры показывают ошибку доверия, проверьте цепочку сертификата, настройки CDN и полный набор доменов.

Если HTTPS по-прежнему работает не у всех, передайте цепочку на техническую диагностику Web-Puls. Приложите hostname, время, проблемную ОС или браузер и вывод openssl s_client без приватных ключей — этого достаточно для первого разбора.

Источники для контекста

Cloudflare Status: инцидент Issue with TLS certificates using Lets Encrypt CA, 2 июня 2026 года - https://www.cloudflarestatus.com/incidents/j17t8xz91xs0
Let's Encrypt: Chains of Trust - https://letsencrypt.org/certificates/
OpenSSL: Verification options - https://docs.openssl.org/master/man1/openssl-verification-options/
Cloudflare SSL/TLS docs: Bundle methodologies - https://developers.cloudflare.com/ssl/edge-certificates/custom-certificates/bundling-methodologies/