SSL и сертификаты · 3 мин · обновлено 2026-10-15

После продления SSL часть клиентов видит старый сертификат

Новый сертификат выпущен, но часть посетителей получает прежний. Разбираем проверку каждого TLS-узла и критерии, по которым можно подтвердить исправление.

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

Начните с точного имени сайта и сертификата из проблемного соединения. Затем сравните выдачу каждого доступного адреса с тем же именем в TLS-запросе — так можно найти отставший узел, не меняя настройки наугад.

1. Зафиксируйте, какой сертификат видит клиент

Попросите открыть сведения о сертификате и записать адрес страницы, время с часовым поясом, срок действия, издателя и SHA-256-отпечаток. Отпечаток позволяет сравнивать конкретные сертификаты; одинаковый издатель или домен для этого недостаточны.

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

Уточните имя до символа: example.com, www.example.com и поддомен могут обслуживаться отдельно. Даже адрес, который сразу перенаправляет посетителя, должен успешно установить HTTPS-соединение до редиректа.

2. Соберите адреса и точки завершения TLS

Для своего домена получите A- и AAAA-записи:

dig +short A example.com
dig +short AAAA example.com

Повторите запросы в сети, где есть сбой, и в сети, где сайт работает. Разные ответы — повод проверить DNS и оставшиеся старые адреса, а не доказательство ошибки сертификата. Если недавно был переезд, проверьте и прежний сервер, на который ещё могут попадать клиенты.

Составьте короткую таблицу наблюдений:

| Имя сайта | IP и сеть проверки | Где завершается TLS | Отпечаток и срок | | --- | --- | --- | --- | | Основной домен | Каждый A и AAAA | CDN, балансировщик или веб-сервер | Фактически полученные значения | | www и нужные поддомены | Их собственные адреса | Соответствующий узел | Фактически полученные значения |

Сертификат нужен там, где расшифровывается TLS-соединение. Если балансировщик только передаёт зашифрованный трафик дальше, проверяйте серверы за ним; если завершает TLS сам — его настройки.

За CDN есть два соединения: посетитель → CDN и CDN → исходный сервер. Например, у Cloudflare edge-сертификат относится к первому. Продление сертификата только на исходном сервере не обновляет сертификат, который показывает браузер.

3. Проверьте каждый IP с правильным SNI

SNI — имя сайта, которое клиент передаёт при установке TLS. Без него сервер с несколькими сайтами может вернуть сертификат другого виртуального хоста; открытие IP в браузере не заменяет такую проверку. Роль имени описана в документации nginx.

На компьютере с OpenSSL подставьте свой домен и один из его адресов. Приведённый IP — только пример:

openssl s_client -connect 192.0.2.10:443 \
  -servername example.com -showcerts </dev/null |
openssl x509 -noout -dates -serial -issuer -fingerprint -sha256

Для IPv6 используйте -connect '[2001:db8::10]:443', сохранив -servername example.com. Повторите команду для каждого адреса и имени; если соединение зависло, прервите его и отметьте таймаут отдельно.

Здесь s_client получает сертификаты сервера, а x509 выводит сведения о первом, конечном сертификате. Команда сравнивает выдачу и не является полной проверкой доверия или соответствия имени.

Как читать расхождения

Один адрес выдаёт старый сертификат. Проверьте установку и загрузку конфигурации на связанном узле. Если за IP несколько серверов, повторные новые соединения могут показать чередование выдачи.
IPv4 выдаёт новый, IPv6 — старый. Проверьте отдельный IPv6-маршрут и HTTPS-конфигурацию, прежде чем удалять AAAA-запись.
Внешний адрес новый, исходный сервер старый. Обновите соответствующий слой; исправный сертификат CDN не подтверждает исправность TLS до исходного сервера.
Отпечатки разные, но сертификаты действительны. Это само по себе не ошибка: узлы могут использовать отдельные корректные сертификаты. Ищите просроченную или неверную выдачу.

Один IP CDN может вести в разные точки присутствия в зависимости от сети. Поэтому проверка из одного места не охватывает все узлы провайдера: при региональном расхождении передайте ему имя, время, сеть и полученный отпечаток.

4. Исправьте найденный слой и проверьте выдачу заново

На своём сервере сверяйте активный виртуальный хост, путь к сертификату, симлинк и файл внутри контейнера. Автопродление могло заменить файл на хосте, тогда как контейнер использует прежнюю копию.

Проверьте конфигурацию штатной командой сервера и примените её предусмотренным способом. Для nginx это обычно проверка nginx -t и reload через менеджер службы; убедитесь по результату и журналу, что загрузка прошла успешно. На управляемом хостинге используйте процедуру панели или обращение к провайдеру.

Повторите ту же матрицу внешних проверок. Критерий исправления — на проверенных путях нет старого недействительного сертификата, а новые соединения из проблемной сети проходят без прежней ошибки.

Если расхождение осталось только на устройстве

Закройте браузер полностью и создайте новое соединение, затем сравните результат в другой сети. Очистка кэша страниц не исправит сертификат, который сервер выдаёт при TLS-соединении.

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

Регулярный контроль SSL в Web-Puls помогает следить за сроком сертификата. Но успешная проверка одного URL не заменяет сверку всех TLS-узлов после продления.

Если отставший узел найти не удалось, отправьте заявку на профессиональную поддержку: укажите публичный домен, время сбоя и результаты сравнения без ключей, паролей и cookies. Эти данные помогут определить объём диагностики; формат и стоимость работ согласуются до начала.