Мониторинг SSL-сертификатов: срок действия и доступность
Мониторинг SSL-сертификатов и их срока действия кажется задачей на один cron, пока сертификат не истечёт вечером в пятницу на поддомене, про который все забыли. Сроки сертификатов сокращаются, Let's Encrypt перестал присылать письма об истечении, а автопродление ломается тихо. Разбираем, что проверять кроме даты окончания — цепочку, имя, код и время ответа, — и как настроить алерты, чтобы узнать о проблеме за две недели, а не от клиентов.
Почему срок действия сертификата больше нельзя держать в голове?
Схема «купили на год и поставили напоминание» уходит. Весной 2025 года CA/Browser Forum принял бюллетень SC-081v3 о сокращении сроков сертификатов: максимальный срок публичных TLS-сертификатов поэтапно уменьшается с 398 до 47 дней, первый шаг — в марте 2026 года, последний — в марте 2029-го.
Let's Encrypt идёт быстрее. Сейчас его сертификаты по умолчанию живут 90 дней, с февраля 2027 года будут выдаваться на 64 дня, а с февраля 2028-го — на 45 дней, об этом сказано в объявлении Let's Encrypt о переходе с 90 на 45 дней.
Вторая перемена — уведомления. С 4 июня 2025 года Let's Encrypt больше не присылает письма о скором истечении сертификата, что подтверждено в сообщении о прекращении рассылки. Теперь сломанное автопродление первым заметит пользователь с ошибкой в браузере.
Короткий срок означает частое продление, а значит, больше шансов, что однажды оно не сработает. Типичные причины:
— изменили DNS или закрыли порт 80, и проверка домена HTTP-01 перестала проходить;
— истёк или отозван API-токен DNS-провайдера, через который шла проверка DNS-01;
— сертификат на диске обновился, а веб-сервер не перечитал конфигурацию и отдаёт старый;
— в конфигурации указан cert.pem вместо fullchain.pem, и сервер отдаёт сертификат без промежуточного;
— на одном узле за балансировщиком остался старый сертификат;
— про поддомен, почтовый сервер или API на нестандартном порту забыли.
Как проверить срок и цепочку сертификата вручную
Смотрите на то, что сервер отдаёт по сети, а не на файл на диске. Дату окончания показывает связка команд:
echo | openssl s_client -connect example.ru:443 -servername example.ru 2>/dev/null | openssl x509 -noout -subject -enddate
Параметр -servername обязателен: без SNI сервер с несколькими сайтами может отдать сертификат по умолчанию, и вы будете смотреть не на тот. Для скрипта добавьте ко второй команде -checkend 1209600: она завершится с ненулевым кодом, если сертификат истекает в ближайшие 14 дней. Имена в сертификате показывает openssl x509 -noout -ext subjectAltName: там должны быть и основной домен, и www, и нужные поддомены.
Цепочку показывает тот же s_client без перенаправления вывода: в конце будет строка Verify return code. Значение 0 (ok) означает, что цепочка собирается до доверенного корня. Ошибка verify error:num=20 и итоговый код 21 (unable to verify the first certificate) почти всегда значат, что сервер не отдаёт промежуточный сертификат.
Это самая коварная поломка: браузер такой сайт часто открывает, потому что сам подтягивает недостающий сертификат, а curl, приложения на Java и Python и интеграции партнёров падают с ошибкой проверки. Поэтому внешняя проверка должна верифицировать цепочку и имя, как самый строгий клиент.
Код ответа, время ответа и доступность: что считать «сайт работает»
Сайт с годным сертификатом может отвечать 502 или открываться пятнадцать секунд. Минимальный набор для внешней проверки:
— доступность: соединение установлено, TLS-рукопожатие прошло с проверкой цепочки и имени, ответ получен до таймаута;
— код ответа после всех редиректов: 2xx и 3xx — норма, 4xx и 5xx — проблема, бесконечная цепочка редиректов — тоже ошибка;
— время ответа целиком, а если инструмент умеет — по фазам: DNS, соединение, TLS, ожидание первого байта;
— число дней до окончания сертификата.
В связке Prometheus и blackbox_exporter это метрики probe_success, probe_http_status_code, probe_duration_seconds и probe_ssl_earliest_cert_expiry. Последняя хранит момент окончания самого раннего сертификата в цепочке в Unix-времени, поэтому правило на срок выглядит так:
(probe_ssl_earliest_cert_expiry - time()) / 86400 < 14
Для доступности — probe_success == 0 с длительностью две-три минуты, чтобы одиночный таймаут не будил дежурного.
Здесь два подвоха. Код 200 не гарантирует, что работает приложение: заглушка «сайт на обслуживании» тоже может отдавать 200, поэтому для важных страниц проверяйте ожидаемый текст или эндпоинт здоровья. И правило «осталось меньше 14 дней» молчит не только когда всё хорошо, но и когда метрики нет вовсе: проверка не получила сертификат, экспортёр не опрашивается, поменялось имя ряда. Эту ловушку мы подробно разбирали в статье о том, почему алерт молчит, когда база упала, — для сертификатов она работает так же.
Внешняя проверка видит сайт как клиенты, но не дотянется до портала во внутренней сети — для него нужна проверка изнутри. А алерт за две недели полезен, только если его кто-то прочитает: когда своего дежурного нет, это закрывает мониторинг как услуга с дежурством.
Что проверить у себя
— Список всех имён с HTTPS: сайт, www, поддомены, API, личные кабинеты, почта на портах 465 и 993 — у каждого есть проверка и ответственный?
— Командой openssl s_client с -servername посмотрите, какой сертификат отдаётся на каждом узле за балансировщиком.
— Убедитесь, что Verify return code равен 0, а веб-сервер отдаёт fullchain.pem, а не только сертификат сайта.
— После автопродления веб-сервер должен перечитать сертификат: в certbot для этого есть deploy-hook.
— Если продление запускается по фиксированному расписанию, например раз в 60 дней, пересчитайте его под сертификаты на 64 и 45 дней.
— Есть ли алерт на срок сертификата и отдельный алерт на недоступность сайта с длительностью в несколько минут?
— Сработает ли алерт, если метрики срока нет вовсе? Проверьте на тестовом адресе с закрытым портом.
— Куда приходит предупреждение и кто читает его в выходные.
За сколько дней предупреждать об истечении сертификата?
Рабочая схема — предупреждение за 14 дней и отдельный критический алерт за 3–7 дней, а для сертификатов, которые покупают вручную через закупку и согласования, порог лучше поднять до 30 дней. Certbot начиная с версии 4.0 продлевает сертификат, когда остаётся треть срока (для 90-дневного это 30 дней, для 45-дневного — 15), поэтому сигнал за 14 дней значит, что продление уже не сработало и пора разбираться. В Voltir порог по умолчанию — 14 дней, он меняется в правиле от 1 до 90 дней, как описано в документации по алертам и уведомлениям.
Если стоит автопродление, мониторинг срока ещё нужен?
Да. Автопродление — механизм, а мониторинг проверяет его результат: какой сертификат сервер отдаёт клиентам прямо сейчас. Он ловит случаи из списка выше — не прошла проверка домена, не перечитан конфиг, забыт узел. Чем короче срок сертификата, тем чаще продление и тем быстрее сломавшаяся автоматика становится аварией.
Как это сделано в Voltir
Сайт ставится на внешнюю проверку во вкладке «Порталы»: раз в минуту платформа запрашивает адрес с проверкой сертификата, пишет статус, код, время ответа и дни до окончания сертификата, а алерты «Портал недоступен» и «SSL-сертификат скоро истекает» уходят в Telegram, на почту или вебхук — подробнее в документации по мониторингу порталов.
Как выглядит дашборд сайтов, можно посмотреть на живом демо-стенде.
Сайты в тарифах Voltir считаются отдельным лимитом и хостов не расходуют.