Максимальный срок публичных сертификатов с марта этого года сократился с 398 до 200 дней. С 2029 года они будут действительны всего 47 дней, а забыть о продлении проще простого, ведь есть и более важные дела. Под катом собрал семь способов удобно следить за сроками SSL.
SSL-сертификат — это то, что даёт вашему сайту тот самый «замочек» в адресной строке. Если серьёзнее, то он даёт браузеру установить с сайтом защищенное HTTPS-соединение и проверить, что сертификат выдан для нужного домена. У сертификата есть срок годности, и когда он кончается, браузер начинает показывать посетителям красное предупреждение про небезопасное соединение…
Какие бывают сертификаты
Раз уж заговорили про перевыпуск, кратко разложу по полочкам, что вообще продаётся на рынке. Сертификаты отличаются по трём осям.
Первая — глубина проверки. Domain Validation (DV) подтверждает контроль над доменом и подходит для большинства обычных сайтов. Organization Validation (OV) дополнительно проверяет сведения об организации. EV идёт ещё дальше в проверке компании, хотя современные браузеры больше не выделяют такие сертификаты отдельной заметной плашкой в адресной строке.
Вторая — покрытие:
Single-domain защищает один домен.
Wildcard вида *.site.ru закрывает основной домен и все его поддомены первого уровня, site.ru и хоть api.site.ru, хоть grafana.site.ru. Сам site.ru должен быть указан в сертификате отдельно.
Multi-domain позволяет включить в один сертификат несколько разных доменных имён через поле SAN.
Третья — как подтверждается владение. Классически удостоверяющий центр кладёт вам файл, вы размещаете его по специальному пути, робот приходит и проверяет. Как альтернативу можно использовать DNS-запись — добавляете TXT в зону и не трогаете файлы сайта, что удобно, когда сайт на конструкторе.
Почему за сертификатами теперь придётся смотреть чаще
Если раньше сертификаты надо было перевыпускать раз в год, то сейчас уже раз в 200 дней, с 2027 года — раз в 100 дней, а с 2029 года, как я уже сказал, раз в полтора месяца. Всё это из-за того, что в апреле 2025 года CA/Browser Forum принял бюллетень SC-081v3. Напоминалки тут не работают — нужен постоянный мониторинг.
Прежде чем строить системы, полезно изучить базовую команду, которая показывает сроки любого сертификата:
openssl s_client \ -servername example.com \ -connect example.com:443 \ </dev/null 2>/dev/null \ | openssl x509 -noout -dates -subject -ext subjectAltName
В ответ прилетят notBefore, notAfter, Subject и список имен из SAN. Этого хватает, чтобы проверить один сайт за несколько секунд.
Помните, что сертификаты живут не только на 443-м порту. Протухший сертификат на почтовом сервере может сломать подключения клиентов и взаимодействие с другими системами. Та же openssl-команда работает и там, просто добавляется ключ -starttls:
openssl s_client \ -starttls smtp \ -servername mail.example.com \ -connect mail.example.com:25 \ </dev/null 2>/dev/null \ | openssl x509 -noout -dates
И раз с самим сертификатом разобрались, теперь перейдём к тому, как не забыть его продлить. Дальше к мониторингу.
Способ 1. Скрипт на bash, который пишет в TG
Для чего: поднять мониторинг через bash и видеть оповещения в телеге.
Для тех, кто не хочет поднимать лишние сервисы, классика жанра — скрипт в кроне. Openssl умеет отвечать кодом возврата, на этом всё и строится:
#!/bin/bash set -uo pipefail PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin TOKEN="123456:ABC_токен_бота" CHAT_ID="123456789" DAYS=14 for DOMAIN in site1.ru site2.ru shop.site1.ru; do if ! CERT=$( timeout 15 openssl s_client \ -servername "$DOMAIN" \ -connect "$DOMAIN:443" \ </dev/null 2>/dev/null \ | openssl x509 -outform PEM 2>/dev/null ); then echo "Не удалось получить сертификат $DOMAIN" >&2 continue fi if ! printf '%s\n' "$CERT" \ | openssl x509 \ -noout \ -checkend "$((DAYS * 86400))" \ >/dev/null 2>&1 then MSG="⚠️ У $DOMAIN сертификат протухнет в ближайшие $DAYS дней (или уже протух)" curl -fsS \ --max-time 10 \ -X POST \ "https://api.telegram.org/bot${TOKEN}/sendMessage" \ --data-urlencode "chat_id=${CHAT_ID}" \ --data-urlencode "text=${MSG}" \ >/dev/null fi done
Кладём в:
sudo nano /usr/local/bin/ssl-watch.sh
Делаем исполняемым:
sudo chmod +x /usr/local/bin/ssl-watch.sh
Проверяем:
/usr/local/bin/ssl-watch.sh
И вешаем на 09:00 каждый день:
0 9 * * * /usr/local/bin/ssl-watch.sh
Раз в день скрипт проходит по списку доменов, и если сертификат истекает — сигналит сообщением. Бот заводится через @BotFather за пару минут, токен и ID чата подставляются в начало скрипта.
Минус — всё живёт на одном сервере, и если упадёт он сам, письмо счастья не придёт. Лечится просто, запускайте скрипт с соседнего сервера или добавьте мёртвую руку вроде healthchecks.io.
Способ 2. Uptime Kuma
Для чего: следить за сроком сертификата через простой веб-интерфейс.
Самый быстрый путь к нормальному мониторингу, когда у вас до пяти сайтов — поднять Uptime Kuma, самохостенную «панель доступности» с очень приятным интерфейсом:
docker run -d \ --restart=always \ -p 3001:3001 \ -v uptime-kuma:/app/data \ --name uptime-kuma \ louislam/uptime-kuma:2
Дальше добавляете HTTP(s)-монитор, указываете адрес сайта, и Kuma начинает показывать по каждому домену срок жизни сертификата в днях. Не забудьте в настройках поставить галочку для отправки уведомлений об истечении срока.
Письма счастья отправляются в TG, Slack, Discord, на почту и в некоторые сторонние сервисы. Заодно Kuma проверяет сами сайты, поэтому одним монитором также закрываются доступность и TLS.
Минус — Kuma это отдельный сервис, который сам надо мониторить. Если у вас три домена — отличный вариант, а если триста, нужно что-то более инфраструктурное.
Способ 3. Blackbox Exporter + Prometheus + Alertmanager
Для чего: добавить мониторинг сертификатов в уже существующий Prometheus.
Взрослый вариант для тех, у кого есть Prometheus. Blackbox Exporter умеет ходить на сайты, делать полный TLS-handshake и отдавать метрику probe_ssl_earliest_cert_expiry, unix-таймстамп истечения сертификата.
Для мониторинга в prometheus.yml добавьте job с характерной перепривязкой меток, чтобы метрики подписывались адресом цели, а не адресом экспортера:
Для мониторинга в prometheus.yml добавьте job с характерной перепривязкой меток, чтобы метрики подписывались адресом цели, а не адресом экспортера. Стандартный модуль Blackbox Exporter называется http_2xx, причем он работает и с HTTPS-адресами. Если Blackbox Exporter у вас уже настроен и модуль http_2xx есть в blackbox.yml, этот файл трогать не нужно:
modules: http_2xx: prober: http timeout: 10s http: method: GET follow_redirects: true preferred_ip_protocol: ip4
Blackbox Exporter при успешном TLS-соединении отдает probe_ssl_earliest_cert_expiry с Unix timestamp окончания сертификата и probe_success со статусом всей проверки. Теперь prometheus.yml:
global: scrape_interval: 30s evaluation_interval: 30s rule_files: - /etc/prometheus/ssl-alerts.yml alerting: alertmanagers: - static_configs: - targets: - 127.0.0.1:9093 scrape_configs: - job_name: blackbox-https metrics_path: /probe scrape_timeout: 15s params: module: - http_2xx static_configs: - targets: - https://site1.ru - https://site2.ru relabel_configs: - source_labels: - address target_label: __param_target - source_labels: - __param_target target_label: instance - target_label: address replacement: 127.0.0.1:9115
К слову, blackbox:9115 — пример адреса Blackbox Exporter. Если Prometheus и exporter запущены через Docker Compose, это может быть имя сервиса. Если он запущен на другой машине, соответственно, укажите ее hostname или IP.
Дальше правила. Лучше делать их три — спокойное предупреждение за месяц, тревога за три дня и отдельное на случившееся фиаско. Создаем /etc/prometheus/ssl-alerts.yml:
groups: - name: ssl-expiry rules: - alert: SSLExpiresIn30Days expr: | ( probe_ssl_earliest_cert_expiry{job="blackbox-https"} - time() ) < (30 24 3600) and ( probe_ssl_earliest_cert_expiry{job="blackbox-https"} - time() ) >= (3 24 3600) for: 1h labels: severity: warning annotations: summary: "У {{ $labels.instance }} сертификат протухнет через {{ $value | humanizeDuration }}" - alert: SSLExpiresIn3Days expr: | ( probe_ssl_earliest_cert_expiry{job="blackbox-https"} - time() ) < (3 24 3600) and ( probe_ssl_earliest_cert_expiry{job="blackbox-https"} - time() ) > 0 for: 5m labels: severity: critical annotations: summary: "СРОЧНО: у {{ $labels.instance }} сертификат протухнет через {{ $value | humanizeDuration }}" - alert: BlackboxProbeFailed expr: probe_success{job="blackbox-https"} == 0 for: 5m labels: severity: critical annotations: summary: "Сайт {{ $labels.instance }} не отвечает или TLS рукопожатие сломано"
Обратите внимание на третье правило. При неудачной TLS-проверке probe_success равен нулю. Сама метрика probe_ssl_earliest_cert_expiry появляется при получении TLS-информации, поэтому полагаться только на нее нельзя. Осталась доставка, для этого в Alertmanager заводим маршрут в TG:
route: receiver: telegram group_wait: 30s repeat_interval: 24h receivers: - name: telegram telegram_configs: - bot_token: "123456:ABC_токен_бота" chat_id: 123456789 parse_mode: '' message: | {{ range .Alerts }}? {{ .Annotations.summary }} Статус: {{ .Status }} {{ end }}
После правок конфиги лучше проверить до перезапуска через promtool check config /etc/prometheus/prometheus.yml и правила через promtool check rules /etc/prometheus/ssl-alerts.yml. А затем перечитать конфигурацию Prometheus. Если сервис работает через systemd:
sudo systemctl reload prometheus
Если reload для конкретной установки не настроен:
sudo systemctl restart prometheus
После изменения конфигурации Alertmanager ее можно перечитать через SIGHUP или /-/reload. Если в вашей установке отдельный reload не настроен, проще перезапустить сервис:
sudo systemctl restart alertmanager
Минусы — ради трех доменов поднимать Prometheus, Blackbox Exporter и Alertmanager странно. Этот вариант хорош именно тогда, когда стек уже есть.
Способ 4. Zabbix
Для чего: мониторить сертификаты там же, где живут серверы, диски и базы.
Если инфраструктура исторически сидит на Zabbix, то проще остаться в нем. В Zabbix Agent 2 есть web.certificate.get. Он получает данные сертификата сайта, включая срок действия, после чего через шаблон можно задать порог предупреждения.
Для этого используется макрос {$CERT.EXPIRY.WARN} — то есть сертификат становится еще одной метрикой узла. Тут же видно CPU, место на диске, доступность сервиса и сколько дней осталось до очередной маленькой катастрофы.
Минусы — поднимать целый Zabbix ради сертификатов никто в здравом уме не станет. Но если он уже есть, решение практически бесплатное.
Способ 5. Icinga Certificate Monitoring
Для чего: искать сертификаты по сети, включая те, о которых уже успели забыть.
Тут сценарий немного интереснее — Icinga Certificate Monitoring умеет сканировать указанные диапазоны адресов и портов, находить TLS-сервисы, собирать их сертификаты и показывать всё это через веб-интерфейс.
Для проверки можно задавать warning и critical как в процентах, так и обычным количеством дней. Например, можно прогнать им внутреннюю сеть и найти сертификат на старой админке, про которую никто не вспоминал.
Минусы — это уже отдельная система с базой, Icinga Web и своей настройкой.
Способ 6. Netdata
Для чего: добавить сертификат к остальным метрикам сервера.
У Netdata есть collector x509check, который показывает оставшееся до окончания сертификата время через x509check.time_until_expiration, а также умеет отдельно проверять статус отзыва, если включить check_revocation_status. Удобно, если Netdata Agent уже установлен, и это, кстати, хороший вариант для первого VDS.
Минусы — ставить Netdata только ради SSL такое себе решение. Агент все-таки занимается куда большим количеством метрик.
Способ 7. x509-certificate-exporter для Kubernetes
Для чего: искать истекающие сертификаты внутри Kubernetes.
Утилита x509-certificate-exporter собирает метрики X.509 из Kubernetes и может работать отдельным бинарником. Проект живой и обновлялся в 2026 году, но так как сам не пользовался, много говорить не буду.
Минусы — для обычного nginx на VDS этот инструмент просто не нужен.
Мониторинг это не продление
Мониторинг сообщает о том, какие сертификаты тухнут, но сами утилиты их не перевыпустят. Если сертификаты у вас бесплатные Let's Encrypt, настройте certbot или acme.sh с автопродлением и проверьте, что хук перезагружает nginx.
Если же сертификат покупной, то автоматика заменяется связкой «Мониторинг + быстрый выпуск». Тут сделаю маленькое отступление — в RUVDS сертификаты теперь можно оформить в личном кабинете, без сторонних регистраторов и танцев с письмами-подтверждениями. На выбор три варианта:
Single-domain с проверкой через HTML-файл, если удобнее положить файлик.
Single-domain с проверкой через DNS-запись, если править файлы сайта не хочется или некому.
Wildcard с проверкой через DNS закрывает основной домен и все поддомены первого уровня.
Оба Single-domain по 1100 руб. по акции вместо 1300 руб., а Wildcard — 1200 руб. вместо 2400 руб. — для проекта с кучей поддоменов он удобнее пяти отдельных сертификатов. Сертификат в течение оплаченного периода будет автоматически перевыпускаться с учетом ограничений CA/B Forum.
Что выбрать
Если у вас один сайт и вы любите скрипты — bash вам в помощь. Хочется красивую панель и уведомления за пять минут — выбирайте Uptime Kuma. Уже есть Prometheus — добавляйте Blackbox Exporter. Живете на Zabbix, Netdata или Icinga — используйте их штатные возможности. Для Kubernetes следите за сертификатами внутри секретов. Комбинировать способы тоже никто не запрещает, но настройте мониторинг, пока сертификаты свежие.
А вы как следите за сертификатами? Если пропустил хороший инструмент, кидайте в комментарии — добавлю в следующую подборку.
© 2026 ООО «МТ ФИНАНС»