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

Что происходит, когда SSL истёк

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

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

• браузер показывает предупреждение безопасности
• пользователь может не попасть на сайт
• доверие к формам и оплате падает
• часть интеграций может отказаться от соединения

Почему календарного напоминания недостаточно

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

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

• сертификат мог продлиться, но не установиться
• www и non-www могут отдавать разные сертификаты
• балансировщик может держать старый сертификат
• автопродление может сломаться без явного уведомления

Когда начинать реагировать на срок SSL

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

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

• больше 30 дней — штатное состояние
• 7-30 дней — пора проверить продление
• меньше 7 дней — срочная задача
• истёк — инцидент доступности

Что проверить после продления

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

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

• дата окончания изменилась на новую
• сертификат выпущен на нужный домен
• цепочка доверия корректна
• www, API и важные поддомены проверены
• CDN или proxy не отдаёт старый сертификат

Как мониторинг SSL помогает поддержке

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

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

• уведомления заранее уменьшают риск просрочки
• история помогает доказать, когда сертификат истёк
• проверка после продления подтверждает результат
• SSL лучше контролировать вместе с доступностью сайта

Типовые ошибки при работе с SSL

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

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

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

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

• проверяйте фактический сертификат снаружи
• не забывайте www и важные поддомены
• контролируйте CDN, proxy и балансировщики
• после продления проверяйте цепочку и дату окончания