Мониторинг сертификатов и доменов: чтобы не протухло в пятницу

MAATRIX

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

Почему "настроено автопродление" — это не гарантия

Certbot, acme.sh и встроенные механизмы Caddy или Traefik действительно продлевают Let's Encrypt сертификаты автоматически в подавляющем большинстве случаев — механизм отработан и используется миллионами серверов. Но "работает в 99% случаев" на длинной дистанции означает, что рано или поздно случится тот самый 1%. Причины типичные и вполне жизненные:

• временный сбой DNS в момент challenge-проверки (провайдер, у которого арендован домен, отвалился на пару часов);
• истёкший или отозванный API-токен у DNS-провайдера, если используется DNS-01 challenge;
• смена IP сервера или неправильно перенастроенный firewall, из-за которого HTTP-01 challenge не проходит;
• упавший или зависший cron/systemd timer, который должен был запустить обновление;
• исчерпанный rate limit у Let's Encrypt из-за параллельных попыток на других доменах того же аккаунта.

Если у вас уже случалось что-то из этого списка, подробности разбора конкретных причин есть в статье про то, почему Let's Encrypt сертификат не обновляется автоматически. Здесь же важна другая мысль: сам факт настроенного автопродления — это не то же самое, что фактически действующий сертификат. Это два разных утверждения, и проверять надо второе, а не первое.

С доменом ситуация принципиально другая и в некотором смысле опаснее. SSL-сертификат, даже истёкший, — это проблема на несколько минут-часов работы: перевыпустить, поставить, перезапустить веб-сервер. Домен же не продлевается сам по себе почти никогда — это отдельное коммерческое действие: нужно, чтобы на балансе у регистратора были деньги, чтобы автосписание прошло, чтобы карта не истекла и чтобы кто-то вообще вспомнил, что домен раз в год/несколько лет требует оплаты.

Домен: чем истечение регистрации хуже истечения сертификата

Если домен просрочен и наступил so называемый grace period (льготный период), у владельца обычно есть какое-то время на восстановление регистрации — но условия сильно различаются между зонами (.com, .ru, .io, .net и так далее) и регистраторами, и рассчитывать на конкретное число дней "потому что так было в прошлый раз" — рискованно. После окончания льготного периода домен уходит на публичный аукцион или в свободную продажу, и его вполне может перехватить кто-то другой — включая тех, кто специально мониторит истекающие домены с трафиком и репутацией именно ради перепродажи или фишинга под вашим прежним именем.

Разница с сертификатом принципиальная:

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

Независимая проверка SSL: не верить настройке, проверять факт

Правильный подход — не спрашивать "настроено ли у меня автопродление", а регулярно и автоматически спрашивать "сколько реально осталось дней у сертификата, который сейчас отдаёт сайт". Это разные вопросы, и второй куда надёжнее, потому что проверяет фактическое состояние, а не намерение системы его поддерживать.

Проверить срок действия сертификата снаружи, как это видит браузер посетителя, можно одной командой:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -enddate

Вывод будет вида notAfter=03 Nov 2026 12:00:00 GMT. Чтобы получать не дату, а количество оставшихся дней и алерт при приближении к порогу, простой скрипт для cron:

#!/bin/bash
# check-cert-expiry.sh
DOMAINS=("example.com" "shop.example.com" "api.example.com")
THRESHOLD_DAYS=14

for DOMAIN in "${DOMAINS[@]}"; do
  END_DATE=$(echo | openssl s_client -servername "$DOMAIN" -connect "$DOMAIN:443" 2>/dev/null \
    | openssl x509 -noout -enddate | cut -d= -f2)

  if [ -z "$END_DATE" ]; then
    echo "ALERT: не удалось получить сертификат для $DOMAIN"
    continue
  fi

  END_EPOCH=$(date -d "$END_DATE" +%s)
  NOW_EPOCH=$(date +%s)
  DAYS_LEFT=$(( (END_EPOCH - NOW_EPOCH) / 86400 ))

  if [ "$DAYS_LEFT" -lt "$THRESHOLD_DAYS" ]; then
    echo "ALERT: сертификат $DOMAIN истекает через $DAYS_LEFT дней ($END_DATE)"
  fi
done

Ключевая деталь — этот скрипт запускается независимо от certbot/acme.sh, с внешней точки зрения (соединяется по 443 порту так же, как это делает браузер), и не полагается на состояние локальных таймеров или логов автопродления. Даже если certbot молчит, залогировал успех, но фактически не подложил сертификат туда, где его читает nginx — этот скрипт увидит правду.

Вывод скрипта стоит завести в существующую систему алертинга, а не запускать вручную и смотреть на экран раз в квартал. Если алерты в Telegram у вас ещё не настроены, шаги описаны в статье как установить и настроить алерты в Telegram на VPS — туда же можно подключить и cron-задачу с проверкой сертификатов через curl к Bot API при срабатывании порога.

Порог в 14 дней — разумный ориентир для сертификатов на 90 дней (Let's Encrypt), но это не измеренное число, а практика "достаточно времени на ручное вмешательство, если автоматика подвела" — для вашей ситуации может быть уместнее 7 или 21 день, в зависимости от того, как быстро вы физически можете отреагировать на алерт.

Отслеживание сроков доменов: не полагаться на память

С доменами задача формально проще технически (не нужен openssl, нужен просто whois), но организационно сложнее — потому что событие редкое (обычно раз в год), а расписание регистраторов у разных зон отличается.

Быстрая проверка вручную:

whois example.com | grep -iE "expir|paid-till"

Для доменов в кириллических и некоторых национальных зонах формат вывода whois может отличаться или вовсе не отдавать дату истечения в понятном виде — тогда надёжнее свериться напрямую в личном кабинете регистратора. Не все whois-серверы отдают данные в одинаковом формате, и парсинг регуляркой может сработать для .com/.net, но не сработать для .io — это стоит один раз проверить руками для каждой используемой зоны, прежде чем автоматизировать.

Практический подход, который реально работает на долгой дистанции:

1. Завести отдельный список всех используемых доменов с датами истечения — таблицу в трекере, файл в репозитории инфраструктуры, что угодно, лишь бы не "в голове".
2. Включить у регистратора автопродление с привязанной картой, если это в принципе поддерживается зоной и регистратором, — это первый рубеж защиты, но не единственный.
3. Поставить напоминание за 30-45 дней ДО даты истечения, а не за 3 дня — потому что если автосписание не прошло (карта истекла, недостаточно средств, банк заблокировал платёж как подозрительный), должно остаться время разобраться руками.
4. Не полагаться на грейс-период как на план Б — если он есть, считайте его подушкой безопасности, а не частью основного плана.

Автоматизировать шаг с whois можно тем же принципом, что и для сертификатов, — периодической проверкой из скрипта, если формат ответа для нужной зоны стабилен:

#!/bin/bash
# check-domain-expiry.sh
DOMAIN="example.com"
THRESHOLD_DAYS=30

EXPIRY=$(whois "$DOMAIN" | grep -iE "^(Registry Expiry Date|paid-till)" | head -1 | awk '{print $NF}')

if [ -z "$EXPIRY" ]; then
  echo "ALERT: не удалось распарсить дату истечения для $DOMAIN, проверьте вручную"
  exit 1
fi

END_EPOCH=$(date -d "$EXPIRY" +%s 2>/dev/null)
NOW_EPOCH=$(date +%s)

if [ -z "$END_EPOCH" ]; then
  echo "ALERT: не удалось разобрать дату '$EXPIRY' для $DOMAIN"
  exit 1
fi

DAYS_LEFT=$(( (END_EPOCH - NOW_EPOCH) / 86400 ))
if [ "$DAYS_LEFT" -lt "$THRESHOLD_DAYS" ]; then
  echo "ALERT: домен $DOMAIN истекает через $DAYS_LEFT дней"
fi

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

Готовые инструменты, чтобы не изобретать велосипед

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

• Uptime Kuma — self-hosted инструмент, у которого мониторинг HTTPS-эндпоинта из коробки включает проверку срока действия сертификата с настраиваемым порогом алерта (по умолчанию предупреждает за 21 день). Если сайт уже мониторится через Uptime Kuma на доступность, включить у него же контроль сертификата — минимальная дополнительная работа. Подробная настройка описана в статье про мониторинг доступности сайта и сервера через Uptime Kuma.
• healthchecks.io и аналоги (dead man's switch) — подходят не для самого сертификата, а для контроля того, что задача автопродления вообще запускалась и завершилась успешно: cron дергает healthchecks.io ping после успешного certbot renew, и если пинга долго нет — приходит алерт. Это дополняет, а не заменяет прямую проверку сертификата снаружи.
• SSL Labs API (api.ssllabs.com) — если помимо срока действия важно ещё и качество конфигурации TLS (протоколы, шифры, цепочка доверия), можно периодически дергать публичный API и следить за оценкой, но это тяжелее по времени выполнения и не предназначено для проверки каждые несколько минут.
• Коммерческие SaaS-мониторинги (UptimeRobot, StatusCake, Pingdom и похожие) — почти у всех есть встроенный контроль срока сертификата как часть обычной HTTPS-проверки, без необходимости поднимать что-то у себя. Разумный вариант, если не хочется держать собственную инфраструктуру мониторинга ради одной этой функции.
• Для доменов специализированных SaaS-инструментов заметно меньше — чаще всего это либо встроенное напоминание от самого регистратора (не всегда надёжное — письма легко теряются в спаме), либо ручной трекер с датами, о котором шла речь выше.

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

Главный практический вывод один: какой бы инструмент вы ни выбрали, настроить его нужно один раз и забыть, а не полагаться на то, что кто-то из команды раз в год вспомнит проверить дату вручную. Человеческая память плохо работает именно с редкими, но критичными событиями — а автоматическое напоминание не забывает и не уходит в отпуск.

Частые вопросы