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

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

Технически backend может работать нормально, HTTP-статус может быть доступен, но бизнес-сценарий уже повреждён. Поэтому SSL-инцидент нужно считать проблемой доступности, а не мелкой настройкой.

Календарь помогает, если сайтов мало и все сертификаты продлеваются вручную. Но в реальной поддержке несколько доменов, поддоменов, www-версии, staging, разные хостинги и балансировщики. Дату легко пропустить, особенно если сертификат выпускал подрядчик или предыдущий администратор.

Автоматическое продление тоже не гарантирует отсутствие проблем. ACME-клиент может не обновить сертификат из-за DNS, rate limit, неправильного webroot, firewall, ошибки прав или изменения конфигурации. Поэтому важно проверять не только “должно продлиться”, а фактический сертификат, который отдаёт сайт.

Практичный подход — несколько зон риска. Если до окончания больше 30 дней, ситуация нормальная. Если осталось 7-30 дней, стоит проверить автопродление и ответственных. Если меньше 7 дней, это уже срочная задача. Если сертификат истёк, это инцидент, который требует немедленной реакции.

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

После выпуска нового сертификата нужно убедиться, что именно он отдаётся пользователю. Проверьте дату окончания, домен, цепочку, intermediate certificates, www-версию, редиректы и балансировщик. Если инфраструктура распределённая, проверьте все узлы, а не только один сервер.

Иногда сертификат обновляется на сервере, но proxy или CDN продолжает отдавать старый. Иногда обновили основной домен, но забыли поддомен API или личного кабинета. Поэтому после продления полезна внешняя проверка, которая смотрит на сайт так же, как пользователь.

Мониторинг SSL снимает с команды ручную обязанность помнить даты. Он регулярно проверяет сертификат, фиксирует срок, предупреждает заранее и показывает историю. Для веб-студии это особенно полезно: можно контролировать сертификаты клиентских сайтов и не ждать сообщения “у нас браузер ругается”.

Важно, чтобы SSL не был отдельной забываемой проверкой. Он должен быть рядом с мониторингом доступности, HTTP-статуса, TTFB и домена. Тогда состояние сайта видно целиком: сайт отвечает, сертификат валиден, скорость нормальная, уведомления настроены.

Самая частая ошибка — считать, что автопродление решает всё. На практике сертификат может обновиться на одном сервере, но не попасть на балансировщик, CDN или второй узел. Другая частая проблема — разные сертификаты для основного домена, www, API и поддоменов личного кабинета.

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

Нужно учитывать и цепочку сертификатов. Иногда срок основного сертификата в порядке, но промежуточный сертификат, CDN-настройка или SNI-конфигурация создают ошибку у части пользователей. Для SEO это особенно неприятно: поисковый робот может получить ошибку безопасности на странице, которая технически “работает” из панели администратора.

На проектах с несколькими доменами полезно вести отдельный список контролируемых HTTPS-точек: основной домен, www, поддомены, API, CDN, промостраницы и клиентские кабинеты. После изменения DNS, переезда на другой хостинг или подключения proxy этот список нужно пересматривать, иначе часть сертификатов выпадет из контроля и рекламных кампаний.