Аудит устаревших SSL/TLS-цепочек на сайте в 2026

В 2026 году аудит устаревших SSL/TLS-цепочек на сайте — это уже не формальность, а нормальная часть технической гигиены. Я регулярно вижу ситуацию, когда сам сертификат свежий, а цепочка доверия собрана криво: старый intermediate, лишний дубль, неполный bundle или вообще цепочка, которая нормально открывается в одном браузере и ломается в другом.

Почему старые цепочки всё ещё ломают сайты

На деле проблема обычно не в HTTPS как таковом, а именно в том, как сервер отдаёт сертификат. Браузер и часть клиентов пытаются собрать цепочку доверия сами. Если сервер не отдал нужный промежуточный сертификат, начинаются ошибки вида unable to get local issuer certificate, certificate chain incomplete или просто предупреждение о небезопасном соединении.

У меня был клиент на Nginx с PHP 8.2 и MySQL 8.0, у которого всё работало в Chrome на десктопе, но мобильные WebView и часть старых клиентов падали на HTTPS. Причина оказалась банальной: в конфиге лежал старый fullchain, собранный ещё под предыдущий выпуск сертификата, и сервер раздавал цепочку не полностью. Сайт не падал, но часть трафика терялась молча.

Что обычно устаревает

• старые intermediate CA, которые больше не используются;
• цепочки с лишними сертификатами, которые сервер отдает подряд;
• RSA-цепочки там, где уже нужен нормальный ECDSA-вариант для части клиентов;
• сертификаты, выпущенные под старые правила валидации;
• необновлённые bundle-файлы после перевыпуска сертификата.

Что проверять в аудите

Я обычно начинаю с простой проверки: что именно сервер отдает на 443 порту и как это видят внешние инструменты. Дальше уже смотрю, нет ли расхождений между тем, что лежит в конфиге, и тем, что реально уходит в ответе.

• полноту цепочки: leaf + intermediate + root, где это уместно;
• корректность fullchain.pem или аналога в панели хостинга;
• сроки действия всех звеньев цепочки;
• поддерживаемые протоколы: TLS 1.2 и TLS 1.3;
• наличие старых шифров и слабых параметров, если сервер ещё их отдает;
• совместимость с браузерами, ботами, API-клиентами и почтовыми проверками, если HTTPS используется не только для сайта.

По опыту, отдельное внимание стоит уделять сайтам на Bitrix и WordPress после переезда на новый хостинг. Там цепочка может сломаться не в CMS, а на уровне панели, прокси или автоподстановки сертификата. И если сайт работает через CDN, проверять нужно ещё и edge-сертификат, а не только origin.

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

Для базовой диагностики я обычно использую сочетание браузера, командной строки и внешнего сканера. Этого хватает, чтобы понять, где именно проблема: на сервере, в CDN или уже на стороне клиента.

Что можно посмотреть без глубокой настройки

1. Открыть сайт в браузере и посмотреть сведения о сертификате.
2. Проверить ответ сервера через openssl s_client.
3. Сравнить, какой сертификат реально отдает Nginx или Apache.
4. Прогнать проверку через внешние SSL-сервисы и посмотреть цепочку.

Если нужен быстрый ручной тест, я обычно запускаю такую команду:

openssl s_client -connect example.com:443 -servername example.com -showcerts

В выводе смотрю на несколько вещей сразу: количество сертификатов, порядок их передачи, issuer у каждого звена и отсутствие явных ошибок валидации. Если сервер отдает только leaf-сертификат, а intermediate не прикладывает, это плохая идея. Да, иногда браузер “догадается” сам. Но полагаться на это нельзя.

Откуда берутся проблемы с устаревшими цепочками

Чаще всего причина одна из четырёх. И почти всегда это человеческий фактор или старый автоматизм в настройке.

• Не обновили bundle после перевыпуска сертификата. Сертификат новый, а цепочка осталась старой.
• Сменили провайдера или панель управления. Новый хостинг по-другому собирает fullchain.
• Поставили CDN поверх сайта. На origin всё чисто, а на edge осталась старая цепочка.
• Ручной конфиг после переезда. В nginx.conf или виртуальном хосте прописали не тот файл.

На сайтах с высокой нагрузкой это бьёт ещё и по аналитике. Часть пользователей просто не дойдет до страницы, а часть будет получать предупреждения и уходить. Если у вас интернет-магазин, это уже вопрос денег, а не “красоты”.

Что делать после нахождения проблемы

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

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

Если сайт на WordPress или Bitrix, я заодно смотрю, нет ли смешанного контента и старых HTTP-ссылок на ресурсы. Это уже соседняя проблема, но часто она всплывает одновременно. Иначе получается странная картина: сертификат исправили, а браузер всё равно ругается.

Как встроить аудит в регулярную поддержку

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

Минимальный набор для контроля выглядит так:

• мониторинг срока действия сертификата;
• проверка полноты цепочки;
• проверка HTTPS на основном домене, www и поддоменах;
• логирование ошибок TLS на уровне сервера;
• уведомление, если цепочка изменилась или стала неполной.

Если вам уже приходилось разбирать связанные проблемы — например, редиректы на HTTPS, HSTS или смешанный контент — полезно держать рядом и соседние материалы: как настроить HTTP→HTTPS и канонические URL, SSL без ошибок Mixed Content, автопродление SSL-сертификата.

И да, если у вас сайт на стабильной версии PHP 8.1, 8.2 или 8.3, это не значит, что HTTPS-часть настроена правильно автоматически. TLS — отдельный слой, и он живет по своим правилам. Однозначно стоит проверять его отдельно, особенно после переездов, обновлений панели и смены провайдера.