Мониторинг SSL-сертификатов: практическое руководство на 2026 год

Истёкшие SSL-сертификаты — самый предотвратимый тип сбоев в индустрии. Сертификат был действителен вчера, ваш мониторинг молчал, а сегодня утром каждый браузер показывает красную страницу с предупреждением. Автоматическое продление даёт сбои чаще, чем принято признавать, а 90-дневный сертификат Let's Encrypt оставляет небольшой запас на случай пропущенной задачи продления. В этом руководстве разбирается, как на самом деле работает мониторинг SSL, на что настраивать оповещения и как не дать сертификатам застать вас врасплох.

Почему SSL-сбои продолжают случаться в эпоху авто-продления

Автоматическое продление не решило проблему истечения SSL. Оно лишь сместило точку отказа. Задача certbot или acme.sh отрабатывает, но новый сертификат так и не загружается в nginx, потому что шаг перезагрузки был отключён. Ingress в Kubernetes продлевает сертификат, но секрет так и не доходит до пода, который продолжает обслуживать старый сертификат. SAN-сертификат с несколькими доменами обновляется, но одно из имён было удалено из запроса и теперь обслуживает истёкший альтернативный сертификат.

Внешний мониторинг ловит все эти случаи, потому что не доверяет вашему внутреннему состоянию. Он видит то же, что видит реальный браузер: сертификат, отдаваемый на публичном имени хоста, на публичном порту, в реальном TLS-рукопожатии. Если отдаётся неправильный сертификат, монитор это узнает, независимо от того, что говорят ваши cron-логи.

Что на самом деле проверяет монитор SSL

Хорошо построенный SSL-монитор делает шесть вещей при каждой проверке. Большинство инструментов выводят как оповещения только часть из них, а остальное прячут.

• Количество дней до истечения — ключевая метрика, отображаемая с настраиваемым окном предупреждения.
• Соответствие имени хоста — сертификат, действительный для example.com, но отдаваемый на api.example.com, срабатывает немедленно.
• Проверка цепочки сертификатов — выявляет отсутствующие промежуточные сертификаты, которые работают в одних браузерах, но дают сбой на мобильных.
• Обнаружение самоподписанных сертификатов и недоверенных издателей для тестовых окружений, которые случайно получают реальный сертификат.
• Версия TLS — устаревшие протоколы (TLS 1.0, TLS 1.1) помечаются до того, как браузеры полностью от них откажутся.
• Список альтернативных имён субъекта — полезно для SAN-сертификатов, которые во время продления могут незаметно потерять одно из имён.

Как задать окна предупреждения, которые действительно работают

Окно в 7 дней слишком короткое. Окно в 90 дней приводит к усталости от оповещений. На практике хорошо работают 30 дней для первого предупреждения и 7 дней для эскалации.

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

Операционные привычки, предотвращающие SSL-сбои

Три привычки в порядке приоритета уберут SSL из ваших отчётов об инцидентах.

• Мониторьте каждый публичный хост по отдельности. Wildcard-сертификат не заменяет мониторинг каждого использующего его поддомена, потому что всё, что отдаёт не тот сертификат (неправильно настроенный прокси, устаревший кэш CDN), не проявится при проверке wildcard.
• Проверяйте процесс продления по расписанию. Ежемесячный пробный прогон продления в тестовой среде намного дешевле, чем обнаружить на 90-й день, что задача продления успела сгнить.
• Заверните SSL-оповещения в тот же канал, что и уведомления о деплоях. Баги с SSL почти всегда уходят корнями в деплой, изменивший путь к сертификату, команду перезагрузки или имя секрета.

Когда автоматизации недостаточно

Есть три ситуации, требующие участия человека, и никакая автоматизация их не исключает.

Первая — перенос домена или смена регистратора. Задача продления аутентифицируется у старого регистратора, тихо падает, и срок сертификата истекает. Вторая — смена провайдера CDN. Новый CDN отдаёт сертификат по умолчанию, пока вы не загрузите свой. Третья — мультирегиональные конфигурации, где задача продления выполняется в одном регионе, а сертификат должен быть развернут во всех. Мониторинг SSL ловит все три случая на уровне симптома (отдаётся не тот сертификат) раньше, чем это заметит клиент.

Собираем всё вместе

Добавьте по одному SSL-монитору для каждого публичного хоста, которым вы владеете. Установите предупреждение на 30 дней. Направьте оповещение в тот же канал, куда приходят уведомления о деплоях. Добавьте эскалацию на 7 дней, вызывающую дежурного. Раз в месяц проводите пробный прогон продления. С этими четырьмя пунктами SSL перестанет быть повторяющимся типом инцидентов.