Nova Uptime
Отраслевые гайдыSaaSSSL-certificatessecurity

Мониторинг SSL-сертификатов для SaaS: предотвращение истечения, которое убивает доверие клиентов

Истёкший SSL-сертификат превращает ваш SaaS в угрозу безопасности. Как мониторить срок сертификата, автоматизировать продления и сохранять доверие клиентов.

SN
Sumit Nova Uptime
1 марта 2026 г. · 9 min read
Share:

ЧП с истечением SSL: когда защищённый сайт становится небезопасным#

Утром во вторник клиент заходит в ваш SaaS-продукт. Браузер выдаёт пугающую ошибку: «Your connection is not secure. This site’s certificate has expired».

Первая мысль клиента: «Мои данные в безопасности? Их взломали?» Он закрывает вкладку и не возвращается.

Для SaaS-компании истечение SSL — это не просто техническая проблема, это катастрофа доверия клиентов. Один просроченный сертификат может за минуты испортить месяцы работы над брендом.

Масштаб: 65% сайтов в какой-то момент сталкиваются с истечением SSL. Для SaaS-компаний с множеством поддоменов и регионами риск ещё выше. Каждому поддомену (api.yourdomain.com, staging.yourdomain.com, eu.yourdomain.com) нужен свой сертификат или wildcard, покрывающий их все.

Пропустите один — и ваш API становится недоверенным. Запросы клиентов падают. Их интеграции ломаются. Поддержка завалена.


Почему SSL в SaaS — это особый случай#

1. Много поддоменов и сертификатов

Обычный сайт может иметь один SSL-сертификат: yourdomain.com

У SaaS-компании их много:

  • yourdomain.com (основной сайт)
  • app.yourdomain.com (само приложение)
  • api.yourdomain.com (публичный API)
  • admin.yourdomain.com (админ-панель)
  • webhooks.yourdomain.com (приёмник вебхуков)
  • cdn.yourdomain.com (CDN-дистрибуция)
  • eu.yourdomain.com (региональный деплой)

У каждого поддомена может быть свой сертификат, или вы используете wildcard (*.yourdomain.com). В любом случае это много точек отказа.

2. Сертификаты в нескольких облаках

Многие SaaS используют сразу AWS, Google Cloud, Azure:

  • AWS Certificate Manager — для инстансов us-east-1
  • Cloudflare — для CDN
  • Let’s Encrypt — для self-hosted-компонентов
  • Внешний CA — для legacy-систем

Управлять сроками без централизованного мониторинга — хаос.

3. Сбои авто-продления тихие

Большинство сертификатов авто-продляются через сервисы вроде Let’s Encrypt. Но авто-продление может тихо упасть:

  • Let’s Encrypt шлёт запрос продления на ваш сервер
  • Ошибка DNS-валидации
  • Файрвол блокирует трафик продления
  • Хранилище сертификатов переполнено, новый не записать

Сертификат «истечёт через 5 дней», и никто не замечает, пока клиенты не сообщают «небезопасное соединение».

4. Сложность wildcard

Wildcard (*.yourdomain.com) покрывает все поддомены, но требует DNS-валидации. Если она упадёт при продлении — wildcard истечёт, и все поддомены станут недоверенными.


Каскад истечения SSL#

День 0. Сертификат вот-вот истечёт#

Сертификат истекает через 30 дней. Если есть мониторинг — алерт по email. Если нет — ничего.

Дни 0–29. Тихий обратный отсчёт#

Никто не действует. Алерт зарыт в почте. Команда инжиниринга его не видит. Не приоритет.

День 30. Сертификат истёк#

В 00:00 UTC сертификат недействителен. Браузеры показывают «небезопасно» всем.

Часы 1–2. Клиенты замечают#

Первые клиенты заходят в SaaS. Видят предупреждение. Закрывают вкладку. Льются тикеты: «Yourdomain.com взломан?»

Часы 2–4. Начинается отток#

Больше клиентов видят предупреждение. Часть пишет в поддержку. Часть просто уходит. Если оценивают ваш SaaS — это решает вопрос: они вам не доверяют.

Часы 4–8. Команда обнаруживает#

Инжиниринг наконец замечает проблему (по жалобам клиентов или попытке зайти в прод). Срочно продлевают сертификат.

Часы 8–12. Продлено и развёрнуто#

Сертификат продлён. Но распространение его на все балансировщики, edge-узлы CDN и API занимает время. Разные регионы покрываются в разные моменты.

Часы 12–24. Ущерб репутации#

Даже после продления клиенты помнят пугающий момент. Доверие подорвано. Появляются посты в соцсетях: «Можно ли доверять [SaaS]? Они дали SSL истечь».


Почему истечение случается в SaaS-окружениях#

Причина 1. Ручные продления#

Сертификаты требуют ручного продления раз в 1–2 года. Кто-то должен помнить. Этот человек уволился, ушёл в отпуск или повышен, когда подходит срок.

Причина 2. Сбои авто-продления#

Авто-продление Let’s Encrypt тихо падает, если:

  • DNS-валидация не достучалась до эндпоинта
  • Файрвол блокирует
  • На сервере кончилось место
  • Не те права на хранилище сертификатов

Продление не прошло, никто не уведомлён, сертификат истекает.

Причина 3. Мульти-облачная сложность#

Вы управляете сертификатами в AWS (ACM авто-продлевает), Cloudflare (отдельное продление), Let’s Encrypt (ещё одна система). Они продляются в разное время. Единого места отслеживания нет.

Причина 4. Забытые поддомены#

Вы мониторите app.yourdomain.com и api.yourdomain.com. А webhooks.yourdomain.com — новый поддомен, созданный в прошлом квартале. У него свой сертификат, о котором забыли. Он истекает.

Причина 5. Сбой продления wildcard#

Продление wildcard требует DNS-валидации. Если она упадёт (неверная DNS-запись, файрвол блокирует) — продление падает тихо.


Жизненный цикл сертификата в SaaS: лучшие практики#

1. Инвентаризация всех сертификатов

Создайте мастер-список:

Домен                           Провайдер       Истечение       Авто-продление?
yourdomain.com                  AWS ACM         2027-03-15      Да
app.yourdomain.com              AWS ACM         2027-03-15      Да
api.yourdomain.com              AWS ACM         2027-03-15      Да
*.eu.yourdomain.com             Cloudflare      2026-08-20      Да
cdn.yourdomain.com              Let’s Encrypt   2026-04-10      Да
webhooks.yourdomain.com         Let’s Encrypt   2026-06-05      Да
old-api.yourdomain.com          GoDaddy         2025-09-01      Нет (*)

(*) Старый API ещё активен, но через 3 месяца выводится из эксплуатации. Авто-продление выключено, потому что EOL.

2. Централизуйте мониторинг истечений

Не полагайтесь на email-алерты от каждого провайдера. Сделайте единую панель:

# Check certificate expiry
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com | \
  openssl x509 -noout -dates

Или используйте инструменты, которые ежедневно проверяют все домены.

3. Многоуровневые алерты

Алертите на разных интервалах:

  • За 90 дней: планировочный (низкий приоритет)
  • За 30 дней: требуется действие (средний)
  • За 14 дней: срочно (высокий, назначить владельца)
  • За 7 дней: критично (поднять кого-то)
  • За 1 день: аварийно (если ещё не продлено)

4. Тестируйте процесс продления раз в квартал

Не ждите дня истечения, чтобы тестировать. Каждый квартал:

1. Продлите тестовый сертификат вручную
2. Деплой в тестовое окружение
3. Проверьте, что HTTPS работает корректно
4. Проверьте полноту цепочки
5. Зафиксируйте найденные проблемы
6. Обновите runbook’и при необходимости

5. Внедрите автоматическое продление

Используйте сервисы с авто-продлением:

  • AWS Certificate Manager: авто-продление за 60 дней
  • Cloudflare: авто-продление сертификатов
  • Let’s Encrypt: настройте авто-продление (certbot + cron)
  • ZeroSSL: авто-продление есть

6. Мониторьте успешность авто-продления

Авто-продление работает только если оно реально проходит. Настройте мониторинг:

// Monitor auto-renewal success
Daily check:
  1. Query certificate details
  2. Compare renewal_date to current_date
  3. If renewal_date is stale (hasn't changed in 30+ days), alert
  4. If certificate expiry is < 30 days and renewal_date hasn't updated, alert

Это ловит тихие сбои продления до истечения.


Реальный кейс сбоя SSL#

Компания: B2B SaaS, 500 enterprise-клиентов, $5M ARR

Конфигурация: три поддомена:

  • app.company.com (основной SaaS)
  • api.company.com (публичный API)
  • webhooks.company.com (приёмник вебхуков)

Все три сертификата управляются AWS Certificate Manager с авто-продлением.

Проблема: сертификат api.company.com истёк во вторник утром.

Почему так получилось:

  • AWS ACM попытался авто-продлить за 60 дней
  • DNS-валидация для api.company.com упала из-за недавней миграции DNS
  • Поддомен валидации (_acme-challenge.api.company.com) после миграции не существовал
  • AWS тихо провалил продление без алертов
  • Через 60 дней сертификат истёк

Эффект:

  • Все API-вызовы из клиентских приложений начали возвращать «certificate validation failed»
  • Интеграции клиентов сломались
  • Клиенты не могли синхронизировать данные с SaaS
  • Поддержку залило жалобами «API лежит»
  • Выручка фактически встала (клиенты не могут пользоваться)

Обнаружение: команда поддержки заметила через 4 часа, расследуя жалобы.

Фикс:

  • Продлили сертификат вручную
  • Починили DNS-записи валидации
  • Добавили мониторинг для всех трёх сертификатов
  • Стали тестировать процесс авто-продления раз в квартал

Урок: «Мы думали, авто-продление AWS пуленепробиваемо. И оно было — пока DNS не сменили. Нам нужен был мониторинг, который реально проверяет факт продления, а не предполагает, что оно прошло».


Чек-лист мониторинга сертификатов

До деплоя

☐ Все домены и поддомены в инвентаре сертификатов
☐ Провайдер сертификатов выбран и настроен
☐ Авто-продление протестировано и работает
☐ Мониторинг успешности продления внедрён
☐ Получатели алертов настроены (engineering + ops)
☐ Цепочка сертификата валидирована (cert + промежуточный + root)
☐ HTTPS работает на всех доменах (без mixed content)

В эксплуатации

☐ Ежедневно: мониторинг авто-продления (продления реально проходят)
☐ Еженедельно: ревизия инвентаря (новые поддомены добавлены)
☐ Ежемесячно: проверка оценки SSL Labs (держим A+)
☐ Ежеквартально: ручной тест процесса продления (ловим проблемы заранее)
☐ Ежегодно: аудит провайдера (всё ещё лучший вариант?)

Аварийный протокол

Если сертификат истёк:
  1. Поднять дежурного немедленно
  2. Продлить сертификат через панель провайдера
  3. Деплой в продакшен
  4. Проверить HTTPS curl/браузером
  5. Проверить SSL Labs (должно быть A+)
  6. Уведомить клиентов (прозрачность)
  7. Постмортем: почему мониторинг это пропустил?

Особенности SSL в SaaS#

1. Региональные сертификаты vs wildcard

Wildcard (*.yourdomain.com):

  • Плюсы: один сертификат на все поддомены
  • Минусы: сбой продления = все поддомены недоверены

Региональные сертификаты:

  • Плюсы: сбой изолирован одним регионом
  • Минусы: больше сложности, больше сертификатов в управлении

Рекомендация: wildcard для большинства, региональные — только для критичной географической изоляции.

2. Subject Alternative Names (SANs)

Вместо одного сертификата на каждый домен — SAN, покрывающий несколько в одном:

Certificate Subject: yourdomain.com
Subject Alt Names:
  - app.yourdomain.com
  - api.yourdomain.com
  - webhooks.yourdomain.com
  - eu.yourdomain.com

Один сертификат на несколько поддоменов, проще управлять.

3. Certificate pinning (продвинуто)

Высокобезопасные SaaS могут реализовать pinning:

Мобильное приложение знает ожидаемый сертификат заранее.
Если сервер отдаёт другой — соединение падает.
Защита от MITM.

Но pinning требует аккуратной ротации ключей — закреплённые сертификаты нельзя ротировать без обновления приложения.

4. Custom-домены

Если ваш SaaS позволяет клиентам использовать свои домены (например, dashboard.customer.com), вам нужно:

  • Механизм, чтобы клиенты добавляли CNAME-записи
  • Автоматическое создание сертификатов (Let’s Encrypt ACME DNS-валидация)
  • Автоматическое продление
  • Мониторинг сертификатов всех клиентских доменов

Это сильно усложняет операции. Планируйте аккуратно.


Автоматизация мониторинга сертификатов

Вариант 1. Инструменты мониторинга#

Сервисы:

  • SSL Labs: бесплатное API, проверяет грейд
  • crt.sh: логи certificate transparency (бесплатный мониторинг)
  • Certly: специализированный мониторинг
  • Nova Uptime: интегрированный SSL-мониторинг (входит в uptime)

Вариант 2. Самодельный мониторинг#

#!/bin/bash
# Check certificate expiry for critical domains

DOMAINS=("yourdomain.com" "app.yourdomain.com" "api.yourdomain.com")
ALERT_DAYS=30

for domain in "${DOMAINS[@]}"; do
  expiry=$(openssl s_client -connect $domain:443 \
    -servername $domain 2>/dev/null | \
    openssl x509 -noout -dates | \
    grep "notAfter" | cut -d= -f2)

  expiry_epoch=$(date -d "$expiry" +%s)
  current_epoch=$(date +%s)
  days_remaining=$(( ($expiry_epoch - $current_epoch) / 86400 ))

  if [ $days_remaining -lt $ALERT_DAYS ]; then
    echo "ALERT: $domain expires in $days_remaining days"
    # Send to monitoring system
  fi
done

Запускайте этот скрипт ежедневно через cron, шлите результат в ваш дашборд.


SSL-мониторинг в Nova Uptime#

Nova Uptime объединяет SSL-мониторинг с мониторингом доступности:

  1. Автоопределение сертификатов: находит все SSL на ваших доменах
  2. Алерты истечения: предупреждает за 30, 14, 7 и 1 день
  3. Валидация цепочки: проверяет полную цепочку (cert + промежуточные + root)
  4. Отслеживание грейда: мониторинг A+ от SSL Labs
  5. Историческое отслеживание: история статуса за 90 дней

С Nova Uptime автоматический SSL-мониторинг встроен в проверки uptime — отдельный инструмент не нужен.


Итог: защищаем SaaS мониторингом SSL#

Истечение SSL тихое, но эффект катастрофический. Один просроченный сертификат может разрушить доверие клиентов и выручку за часы.

План действий:

  1. Инвентаризируйте все сертификаты: каждый домен и каждый сертификат под управлением
  2. Включите авто-продление: Let’s Encrypt, AWS ACM или провайдерское авто-продление
  3. Проверяйте успешность продления: не верьте на слово — мониторьте
  4. Многоуровневые алерты: 90/30/14/7/1 день
  5. Тестируйте раз в квартал: вручную проходите процесс продления
  6. Централизуйте мониторинг: используйте инструменты вроде Nova Uptime, чтобы видеть все сертификаты в одном месте

Ваши SSL-сертификаты — фундамент клиентского доверия. Не давайте им истекать тихо. Используйте бесплатный тариф Nova Uptime для мониторинга SSL по всем вашим доменам, интегрированного с мониторингом доступности для полной видимости инфраструктуры.

Один сертификат, продлённый слишком поздно, = доверие клиентов разрушено навсегда.

Monitor Your Website Before It Goes Down

Get uptime monitoring, SSL tracking, domain expiry alerts, and email health checks. Free plan — no credit card required.

Start Monitoring Free

Похожие статьи