Когда истекает ваш SSL — умирает ваш сайт#

Вторник, 14:47. Вашему CEO звонит крупнейший клиент: «Ваш сайт не открывается. Мы видим предупреждение безопасности».

Команда разработки в панике. API в порядке. БД отвечает. Балансировщик здоров. Потом кто-то проверяет: SSL-сертификат истёк два часа назад.

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

Так происходит у команд постоянно. По свежим данным, 65% организаций сталкивались с простоями из-за SSL. Медианное время обнаружения просроченного сертификата — больше 2 часов. Медианное время исправления — 45 минут. 147 минут общего простоя для проблемы, которую автоматический мониторинг поймал бы за 90 дней.

Самое плохое: SSL-просрочка не «деградирует мягко». Браузеры показывают полные предупреждения безопасности. Пользователи решают, что сайт скомпрометирован. Доверие рушится за минуты.

Этот гайд — почему сертификаты проскакивают мониторинг, какие пробелы в текущих стратегиях и как практически реализовать алерты SSL, которые работают.

Почему SSL-сертификаты истекают незамеченными#

Слепая зона мониторинга

У большинства команд какой-то SSL-мониторинг есть. Просто не на всём.

Что мониторят:

Сертификат основного домена (example.com)
Иногда API-домен (api.example.com)
Иногда origin-сертификат CDN

А что нет:

Внутренние сертификаты (staging.internal.example.com)
Региональные CDN-сертификаты (staging, QA, production-asia)
Сертификаты non-HTTP сервисов (SMTP/TLS, соединения с БД)
Промежуточные сертификаты (CA bundle, не leaf)
Сертификаты сторонних сервисов, которыми вы владеете (клиентские API-ключи, сертификаты подписи мобильных приложений)
Wildcard, покрывающие поддомены, но индивидуально не отслеживаемые

У типичного mid-market около 12–15 сертификатов в продакшене. Мониторинг есть на 3–4.

Итог: один забытый сертификат истекает в воскресенье. В понедельник клиенты не могут попасть на сервис.

Почему текущий мониторинг пропускает сертификаты

Даже команды с SSL-мониторингом часто пропускают истечение, потому что:

Мониторят leaf, а не цепочку: Инструмент проверяет, что главный сертификат истечёт 15 марта. И не проверяет: промежуточный сертификат CA истекает 20 января. Браузеры отвергают всю цепочку, сайт лежит, инструмент всё ещё показывает «зелёное».

Разовые проверки, а не непрерывное отслеживание: Проверили месяц назад. Больше не проверяли. Сертификат заменили инфобезы — инструмент не знает. Или проверили, но затем сам инструмент простоял без присмотра месяц, и истечение случилось 2 недели назад.

Нет покрытия новой инфраструктуры: DevOps поднимает новый staging с self-signed сертификатом. Инструмент не настроен на него. Через полгода истечение. «Не знал, что мы это мониторим», говорит инженер.

Ручной календарь продлений (ненадёжен): У вас в календаре напоминание на 15 апреля продлить сертификаты. В апреле — производственный инцидент. Напоминание игнорируется. Сертификат истекает через три недели.

Неверные допущения о продлении: Вы думаете, Let’s Encrypt сам продлевает (иногда). Облачный провайдер сам продлевает (не всегда). CA шлёт предупреждения (шлёт, но на старый адрес или в спам). Вы думаете, кто-то следит (нет).

Реальная цена пропущенного истечения SSL#

Немедленный эффект: полная недоступность сервиса

В отличие от HTTP 503, истёкший SSL не показывает аккуратную ошибку. Современные браузеры дают агрессивное предупреждение: «Your connection isn’t private» с большим красным крестом.

Первая мысль пользователя: «Сайт взломан. Карту вводить не буду».

Для e-commerce: конверсия в районе нуля во время SSL-ошибок. Для SaaS: клиенты считают, что данные под угрозой. Для API: все запросы падают сразу.

Реальный пример: Платёжная компания дала сертификату истечь на 3 часа. Транзакции не проходили. Потери оценили в $180 000 по объёму. Восстановление доверия заняло недели.

Каскадные сбои: ломаются зависимости

Истечение SSL ломает не только ваш сайт. Падают зависимые сервисы:

Истекает сертификат API → мобильные приложения не могут аутентифицироваться → пользователи не входят
Истекает сертификат вебхуков → сторонние интеграции не присылают события → синхронизация данных ломается
Истекает сертификат соединения с БД → приложения не могут подключиться → всё валится
Истекает email TLS → письма не отправляются → уведомления ломаются

Один сертификат может уронить 5+ зависимых сервисов.

Нарушения compliance: аудиты и штрафы#

Для регулируемых отраслей:

Healthcare: HIPAA требует TLS для передачи PHI. Просроченные сертификаты = нарушение. Аудиторы фиксируют. Возможны штрафы.
Финансы: PCI DSS требует валидный SSL/TLS на платёжных страницах. Просрочка = нарушение. Регулярные аудиты ловят.
Государство: FedRAMP требует валидности 24/7. Просрочка = система выводится из эксплуатации.

Пропустить SSL-истечение во время compliance-аудита особенно болезненно: и простой был, и нарушены требования безопасности во время простоя.

Репутационный ущерб: долгосрочный

SSL-ошибки запоминаются. «Я зашёл на example.com, а там написали, что взломан» расходится по сообществам, форумам поддержки, соцсетям.

Восстановление требует времени. Даже после фикса пользователи подозрительны. Доверие приходится отстраивать заново.

Как работают SSL-сертификаты: что именно ломается#

Цепочка сертификатов (то, о чём забывают)

Ваш SSL — это не один сертификат. Это цепочка:

Leaf-сертификат (ваш домен): example.com, выдан Let’s Encrypt, истекает 15 марта
Промежуточный сертификат (CA): Let’s Encrypt Authority X3, выдан ISRG, истекает 20 января 2026
Корневой сертификат (доверенный CA): ISRG Root X1, выдан ISRG, истекает 4 июня 2035

Валидным должны быть и leaf, и промежуточный. Если один из них истёк — браузер отвергает всю цепочку.

Большинство мониторят leaf (15 марта). Промежуточный (20 января) — почти никто. Ошибка в браузере приходит за 2 месяца до «своей» даты.

Типы сертификатов и где они прячутся

Доменные сертификаты:

На конкретный домен: example.com
Покрывают только этот домен
Срок: 90 дней (Let’s Encrypt), 1 год (традиционные CA)

Wildcard:

На *.example.com
Покрывают все поддомены (api.example.com, staging.example.com и т. д.)
Один сертификат на 20+ сервисов
Одно истечение бьёт по всем сервисам

Multi-domain/SAN:

Покрывают несколько доменов: example.com, example.co, cdn.example.com — в одном сертификате
Истечение бьёт по нескольким сервисам
Одно продление чинит несколько проблем

Self-signed:

Создаются локально для тестов/staging
Не выданы CA
Сроки игнорируются командами («это же для тестов»)
А потом тестовое окружение уходит в прод вместе с сертификатом

Внутренние/приватные сертификаты:

Для внутренних сервисов, БД, mTLS
Не мониторятся стандартными SSL-чекерами
Истечение даёт сбой аутентификации
Видимости у команд нет

Стратегия SSL-мониторинга: полное покрытие#

Шаг 1. Инвентаризация всех сертификатов (аудит)#

Это критично, и многие пропускают. Нельзя мониторить то, о чём не знаете.

Проведите комплексный аудит:

Для веб-сервисов:

# Scan your domains for all certificates
for domain in example.com api.example.com staging.example.com cdn.example.com; do
  openssl s_client -connect $domain:443 -showcerts 2>/dev/null | \
  openssl x509 -noout -dates -subject
done

Для облачной инфраструктуры: Проверьте AWS Certificate Manager, Google Certificate Manager, Azure Key Vault:

Какие сертификаты есть?
Какие домены покрывают?
Когда истекают?
Кто ими управляет?

Для инфраструктурных сервисов:

Сертификаты БД (RDS, MongoDB Atlas, PostgreSQL TLS)
Email TLS (SMTP/TLS у sendmail, Postfix, SendGrid)
Сертификаты балансировщиков
Сертификаты API-шлюзов
Сертификаты service mesh (Istio, Linkerd и т. д.)

Для приложений:

Сертификаты API-ключей (мобильные приложения, OAuth-ключи с сертификатами)
Сертификаты подписи JWT
Клиентские сертификаты (mTLS-аутентификация)
Сертификаты подписи кода (для дистрибуции приложения)

Что в итоге: таблица с:

Имя/домен сертификата
Дата истечения
CA-эмитент
Процесс продления
Получатель алертов
Бизнес-критичность

Mid-market обычно находит 15–30 сертификатов. Enterprise — 100+.

Шаг 2. Тиры по критичности#

Не все истечения одинаковы. Категоризируйте:

CRITICAL (поднимать дежурного, алерт за 60 дней):

Продакшен веб-домен
Платёжный API
Сервис аутентификации
Клиентские сервисы

HIGH (Slack-алерт, за 30 дней):

API-домены (не платежи)
Edge-сертификат CDN
Email TLS (бизнес-операции)
WebSocket-домен

MEDIUM (email-дайджест, за 14 дней):

Staging (предпродакшен-тесты)
Внутренний сертификат
Админ-панель

LOW (без алерта, отслеживать на дашборде):

Dev/локальные сертификаты
Тестовые сертификаты
С авто-продлением (Let’s Encrypt)

Назначьте получателей алертов по тирам.

Шаг 3. Реализуйте мониторинг для каждого типа#

Для доменных сертификатов (HTTPS):

Используйте специализированный SSL-мониторинг, который проверяет:

Срок leaf-сертификата (главное)
Срок промежуточного (критично — часто забывают)
Валидность сертификата (не недействителен, корректно выдан)
Полнота цепочки (все промежуточные)
Сила cipher suites (алерт на слабые версии TLS)
Покрытие SAN (все ожидаемые домены в списке)

Конфиг для критичного домена:

Домен: api.example.com
Интервал: ежедневно
Алерт: <60 дней до истечения, цепочка сломана, слабые шифры
Получатели: ops-team@example.com

Для БД/внутренних сертификатов:

Большинство инструментов их не проверяют. Настройте в инфраструктуре:

AWS Certificate Manager: уведомления за 60 дней до истечения
Kubernetes: разверните cert-manager с monitoring webhook
HashiCorp Vault: дашборды мониторинга сертификатов
Вручную: скрипт, проверяющий даты OpenSSL и алертящий

Для подписи кода / ключевых сертификатов:

Они живут в системах управления ключами:

Apple Developer на iOS code signing
Android Play Console на ключи подписи
GitHub/GitLab на deploy keys
Вручную: напоминание в календаре + email-алерт за 3 месяца

Шаг 4. Каналы уведомлений (несколько слоёв)#

Не полагайтесь на один канал. SSL-истечение требует резервирования:

За 60 дней:

Уведомление на дашборде (раз в месяц проверять дашборд)
Email команде ops (ops@example.com)

За 30 дней:

Уведомление на дашборде
Slack #ops-alerts
Email ops + CTO

За 14 дней:

Всё выше плюс
SMS дежурному
Эскалация CEO (только critical)

За 7 дней:

Всё выше
Поднять дежурного (если ещё не продлено)

В день истечения:

Поднять дежурного немедленно
Объявить SEV1
Запустить экстренное продление

Такой слоёный подход не даёт пропустить.

Шаг 5. Автоматизируйте продление, где возможно#

Ручное продление — это и есть путь к истечениям. Автоматизируйте:

Let’s Encrypt (авто-продление):

# Certbot auto-renewal (runs via cron daily)
0 0 * * * certbot renew --quiet --post-hook "systemctl reload nginx"

Проверьте, что авто-продление работает:

# Check last renewal date
certbot certificates

AWS Certificate Manager (авто-продление):

Публичные сертификаты: AWS продлевает автоматически за 60 дней
Приватные: вручную, но AWS шлёт уведомления
Проверяйте статус в консоли ACM

Kubernetes (cert-manager):

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com-tls
spec:
  secretName: example-com-tls
  issuerRef:
    name: letsencrypt-prod
  renewBefore: 720h  # 30 days

cert-manager автоматически продлит до истечения.

Для всего остального: Если требуется ручное продление, запускайте его автоматически за 30 дней:

Подключите мониторинг к скрипту продления
Скрипт обновляет сертификат
Мониторинг подтверждает, что новый сертификат активен

Пошаговая реализация SSL-мониторинга#

Шаг 1. Выберите инструмент (1–2 часа)#

Оценивайте по:

Покрытию (только web или БД/внутренние тоже?)
Гранулярности алертов (60/30/14 дней раздельно?)
Интеграциям (Slack, email, PagerDuty?)
Цене (хватает ли free tier? Enterprise-цены?)
Автоматизации продления (автоматизирует или только алертит?)

Сравните:

Nova Uptime: домены + email health + SSL-алерты, плоская цена, простой UI
SSL Labs: бесплатно, всеобъемлюще, без алертов (только дашборд)
Better Stack: SSL-мониторинг + uptime + логирование, от $50/мес
Hyperping: все-в-одном, $24/мес, есть SSL
Datadog: enterprise, всё, очень дорого

Решение: для большинства команд — специализированный SSL-мониторинг (Nova Uptime, Better Stack, Hyperping) + автоматизация через Let’s Encrypt/ACM.

Шаг 2. Инвентаризация и настройка (2–4 часа)#

Аудит сертификатов (см. Шаг 1 выше)
Внесите каждый сертификат в инструмент
Пороги: 60, 30, 14 дней
Тестируйте алерты (что приходят в Slack/email)
Зафиксируйте в таблице

Шаг 3. Slack-интеграция (30 минут)#

Настройте отправку алертов в #ops-alerts:

Шаблон Slack-сообщения:

Домен сертификата
Дата истечения
Дней осталось
Ссылка/инструкции по продлению
Бизнес-влияние при истечении

Шаг 4. Создайте runbook (30 минут)#

По каждому тиру задокументируйте:

Где живёт сертификат? (AWS ACM, Let’s Encrypt, свой сервер)
Кто отвечает за продление? (DevOps, SRE, подрядчик)
Как продлевать? (команда Certbot, консоль AWS, вендорский портал)
Как убедиться, что активен? (SSL-чекер, тестовый HTTPS-запрос)
Кого уведомить по завершении? (Тимлид, монитор)
Сколько обычно занимает? (5 минут? 30? 24 часа?)

Пример runbook:

Сертификат: api.example.com (AWS ACM)
Ответственные: DevOps
Процесс продления:
  1. Открыть AWS Certificate Manager
  2. «Request certificate»
  3. Выбрать «Domain validation»
  4. Дождаться валидации по email (2–4 часа)
  5. Подтвердить в письме
  6. Обновить балансировщик на новый сертификат
  7. Тест: curl https://api.example.com -v
  8. Уведомить: канал #ops-alerts

Типичное время: 30 минут (4 часа, если email медленный)

Шаг 5. Тестируйте систему (1 час)#

Не узнавайте про мониторинг во время реального истечения.

Тест 1. Доставка алерта

Триггерните тестовый алерт
Email приходит за 2 минуты
Slack-уведомление за 1 минуту
SMS за 3 минуты (если настроено)

Тест 2. Процесс продления

Не ждите 14 дней до истечения
Симулируйте продление на некритичном
Идите по runbook
Убедитесь, что новый сертификат активен
Убедитесь, что инструмент обновился

Тест 3. Эскалация

Если алерт не подтверждён за 1 час, кто эскалирует?
Поднимается ли дежурный?
Прогоните полный поток эскалации

Типичные ошибки

Ошибка 1. Мониторинг только leaf#

Вы проверяете, когда истечёт доменный сертификат (15 марта). Игнорируете промежуточный (истекает 20 января).

Итог: браузеры отвергают цепочку 20 января, сайт лежит, ваш мониторинг не сработает до февраля.

Фикс: инструмент должен проверять всю цепочку, не только leaf.

Ошибка 2. «Let’s Encrypt сам разберётся»#

Let’s Encrypt авто-продлевает, можно забыть, верно?

Неверно. Авто-продление падает, если:

Неверно настроен renewal hook (сертификат продлён, но сервер не перезагружен)
Падает DNS-валидация (домен не верифицируется)
Достигнут rate limit Let’s Encrypt
Сервер выключен в окне продления

«Поставил и забыл» — путь к просрочкам.

Фикс: мониторьте статус продления Let’s Encrypt. Certbot не упадёт «громко» — придётся смотреть логи.

Ошибка 3. Сертификаты в нескольких местах, мониторинг — в одном#

Сертификаты у вас в:

AWS ACM (балансировщик)
секретах Kubernetes (поды приложения)
локальных файлах на сервере (бэкап)

Мониторите только ACM. Кто-то обновляет локальный файл и забывает ACM-версию — локальный истекает, приложение использует старый, алерт не уходит.

Фикс: инвентаризация всех сертификатов. Мониторить каждый отдельно. Деплой сертификата должен обновлять все места одновременно.

Ошибка 4. Alert fatigue на сертификатах#

Алертите за 60, 30, 14 и 7 дней.

Команда видит 4 алерта на один сертификат, перестаёт реагировать, пропускает реальное окно продления.

Фикс: алертите только в ключевых точках (60 и 7 дней). На 30/14 — задачи-напоминания, не алерты.

Ошибка 5. Непонятная ответственность за продление#

«Кто продлевает этот сертификат?» Никто не знает.

Двое думают, что справится другой. Сертификат истекает.

Фикс: явный владелец на каждый сертификатный тир. Резервный владелец. Эскалация, если основной не подтверждает алерт.

Ошибка 6. Self-signed в продакшене#

Команда делает self-signed для staging. Локально работает. Потом «временно» копируется в прод. Через полгода никто не помнит. Истекает. Прод лежит.

Фикс: self-signed никогда не уходит в прод. Точка. Закрепите в правилах деплоя.

Как Nova Uptime защищает от истечения SSL#

Nova Uptime объединяет мониторинг SSL, отслеживание истечения домена и проверку email health — комплексный мониторинг инфраструктуры в одном месте:

Автоматическая SSL-валидация в каждом health-чеке:

Каждая проверка домена в Nova Uptime валидирует SSL-сертификат
Обнаруживает истёкшие, невалидные или сломанные сертификаты и сразу алертит
Отдельные типы уведомлений: предупреждение об истечении SSL и состояние «SSL невалиден/сломан»

Уровневые алерты истечения:

Настраиваемые алерты на нескольких интервалах до истечения
Email-уведомления владельцу домена с днями до конца
SSL-алерты дедуплицируются в течение 24 часов, чтобы не спамить

Единая панель мониторинга:

В одном месте: uptime, статус SSL, истечение регистрации домена, email health
Статус сертификата виден прямо на карточках доменов
Еженедельные отчёты сводят статус мониторинга

Отслеживание истечения домена включено:

RDAP- и WHOIS-запросы отслеживают, когда истекает регистрация
Подтверждение продления: вы можете отметить, что продлили
Не даёт упустить ни SSL, ни регистрацию домена

Итог и план действий

Истечение SSL предотвратимо. Это не техническая проблема — это операционная, она решается видимостью и автоматизацией.

Ваш план:

На этой неделе: проведите полный аудит сертификатов. Инвентаризация всех доменов, внутренних сервисов, БД, code signing. Соберите таблицу.
Неделя 2: распределите по тирам. Назначьте получателей алертов и владельцев продления.
Неделя 3: настройте инструмент SSL-мониторинга. Внесите все сертификаты. Алерты на 60/30/14/7 дней.
Неделя 4: runbook’и для каждого типа. Шаги, ответственные, как проверить.
Неделя 5: тестируйте систему. Триггер тестовых алертов. Симулируйте процесс продления. Проверьте эскалацию.
Постоянно: ежемесячно сверяйте инвентарь сертификатов. Добавляйте новые по мере роста инфраструктуры. Тестируйте процесс продления раз в квартал.

Каждый сертификат, который вы мониторите, — это сертификат, который не истечёт незаметно. Каждая автоматизация — задача, которую не нужно помнить вручную.

Связанные материалы

Гид по мониторингу SSL-сертификатов — глубже в практики мониторинга SSL и стратегии автоматизации.
Alert fatigue: почему вы тонете в алертах — как настроить алерты, чтобы SSL-предупреждения не терялись в шуме.
Мониторинг истечения домена: предотвращение сбоев — мониторьте не только SSL, но и регистрацию домена.
Что такое мониторинг доступности? — как мониторинг uptime и SSL работают вместе.
Калькулятор стоимости простоя — посчитайте, во сколько обходится SSL-простой.

Готовы больше никогда не пропускать истечение сертификата? Включите мониторинг SSL-сертификатов в Nova Uptime и получайте алерты заранее, с единым мониторингом домена, SSL и email health. Запускайтесь сегодня.

Предотвращение истечения SSL-сертификата: больше никогда не пропускайте продление