"У нас Let's Encrypt с auto-renewal, сертификаты не могут истечь". Эту фразу я слышал десятки раз — обычно от команд, у которых сертификат только что истёк. Auto-renewal — отличная технология. Но она ломается. DNS-провайдер поменялся, файервол обновился, certbot устарел, cron job случайно удалили. И когда auto-renewal тихо перестаёт работать, вы узнаёте об этом в 3 часа ночи, когда весь трафик падает.
SSL-мониторинг — это страховка от этого сценария. Занимает 2 минуты на настройку, работает годами без внимания и спасает от одного из самых обидных типов downtime — потому что это downtime, который на 100% предотвратим.
Почему SSL-сертификаты истекают несмотря на автоматику
Let's Encrypt выдаёт сертификаты на 90 дней и рекомендует обновлять каждые 60. Автоматические инструменты (certbot, acme.sh, Caddy) обычно справляются. Но есть десяток причин, по которым автоматика молча ломается:
DNS-верификация перестала работать. Вы перенесли DNS на Cloudflare, а certbot настроен на верификацию через старый DNS-провайдер. Challenge не проходит, сертификат не обновляется. Ошибка в логах certbot — но кто читает логи certbot каждый день?
HTTP challenge заблокирован. Firewall, WAF или CDN блокирует запросы к /.well-known/acme-challenge/. Или nginx-конфиг переписали и забыли добавить location для ACME. Сертификат не обновляется.
Certbot устарел. После обновления ОС certbot может сломаться: несовместимость Python-версий, устаревшие зависимости, изменённый API Let's Encrypt. Ubuntu 22 → 24 upgrade — классический момент, когда certbot тихо перестаёт работать.
Cron/systemd timer удалён. Certbot работает по расписанию. Если кто-то почистил crontab или переустановил систему без восстановления таймеров — обновления просто не запускаются.
Wildcard-сертификат с DNS-01. Wildcard-сертификаты требуют DNS-01 challenge. Для этого certbot должен уметь создавать TXT-записи через API DNS-провайдера. Ротация API-ключей, смена тарифа, отзыв permissions — и обновление ломается.
Общий паттерн: auto-renewal ломается тихо. Нет push-уведомлений. Ошибка записывается в лог-файл, который никто не смотрит. А через 30-60 дней сертификат истекает и всё ломается. SSL-мониторинг разрывает этот цикл — вы получаете алерт за 30 дней до проблемы.
Что проверяет SSL-мониторинг
Хороший SSL-мониторинг — это не просто "сертификат истекает через N дней". Он проверяет всю цепочку доверия и конфигурацию TLS:
Срок действия сертификата
Основная проверка. Мониторинг записывает дату истечения и отправляет алерт, когда осталось меньше заданного порога. Рекомендуемые пороги: 30 дней (early warning), 14 дней (нужно действовать), 7 дней (авральная ситуация). В AtomPing порог настраивается в политике алертов — от 1 до 90 дней.
Цепочка сертификатов (certificate chain)
Сертификат вашего домена подписан intermediate CA, который подписан root CA. Если intermediate-сертификат отсутствует в ответе сервера — некоторые клиенты (особенно мобильные приложения и старые браузеры) не смогут проверить доверие и откажут в подключении. Причём Chrome на десктопе может работать (он умеет "дотягивать" chain), а Safari на iOS — нет.
SSL Checker от AtomPing проверяет полноту chain бесплатно — можно использовать для разовых проверок, а TLS-мониторинг делает это автоматически при каждой проверке.
Hostname match
Сертификат должен покрывать именно тот домен, на котором он установлен. Сертификат для example.com не покрывает api.example.com, если нет SAN (Subject Alternative Name) или wildcard *.example.com. При переезде на поддомен это часто упускают.
Версия TLS-протокола
TLS 1.0 и 1.1 — deprecated. Все современные браузеры требуют TLS 1.2+. Если ваш сервер ещё поддерживает TLS 1.0 — это и security risk, и потенциальная проблема совместимости. PCI DSS compliance требует минимум TLS 1.2 с 2018 года.
Как настроить SSL-мониторинг за 5 минут
Настройка SSL-мониторинга — одна из самых быстрых и полезных задач в инфраструктурной безопасности. Вот пошаговый процесс:
Шаг 1. Составьте список доменов. Все домены, на которых работают ваши сервисы: основной сайт, API, CDN, status page, admin panel. Не забудьте поддомены — у каждого может быть отдельный сертификат.
Шаг 2. Добавьте TLS-проверки. В AtomPing создайте TLS-мониторинг для каждого домена. Он проверяет валидность сертификата, полноту chain и дни до истечения при каждом цикле проверки.
Шаг 3. Настройте порог оповещения. Установите 30 дней как стандартный порог. Для wildcard-сертификатов или тех, которые обновляются вручную — 45 дней, чтобы было больше запаса.
Шаг 4. Подключите каналы оповещений. SSL-алерты должны приходить в тот же канал, что и uptime-алерты: Slack, Telegram, email. Убедитесь, что алерт дойдёт до человека, который может обновить сертификат.
Шаг 5. Проверьте разово. Запустите SSL Checker для каждого домена прямо сейчас. Убедитесь, что chain полный, hostname совпадает, протокол — TLS 1.2+. Если есть проблемы — исправьте до того, как мониторинг начнёт алертить.
SSL-мониторинг для API и микросервисов
Если у вас microservice architecture, SSL-сертификатов может быть десятки: каждый сервис с собственным доменом или поддоменом. Internal services на *.internal.company.com, API-gateway на api.company.com, webhook receiver на hooks.company.com.
Особый риск — internal certificates. Для внутренних сервисов часто используют self-signed сертификаты или internal CA. Их нельзя мониторить обычным внешним SSL-чекером. Два подхода:
Вариант 1: Единый wildcard. Используйте один wildcard-сертификат (*.company.com) для всех публичных сервисов. Один сертификат = один point of monitoring. Обновляется один раз, покрывает все поддомены. Минус — если скомпрометирован, затронуты все сервисы.
Вариант 2: Per-service certificates с централизованным мониторингом. Каждый сервис получает свой сертификат (через cert-manager в Kubernetes, например). Мониторинг для каждого — через AtomPing TLS-проверки. Больше сертификатов = больше точек мониторинга, но и лучшая изоляция.
Реальные кейсы: когда SSL-мониторинг спас ситуацию
Кейс 1: Cloudflare → DNS migration. Компания перенесла DNS с GoDaddy на Cloudflare. Certbot был настроен на DNS-01 challenge через GoDaddy API. Через 60 дней сертификат не обновился. SSL-мониторинг отправил алерт за 30 дней до истечения — команда успела перенастроить certbot на Cloudflare API.
Кейс 2: Intermediate certificate removal. CDN-провайдер обновил свой intermediate certificate и забыл добавить его в bundle. Десктопные браузеры работали (они кэшируют intermediate сертификаты), а мобильные клиенты начали падать с SSL errors. TLS-мониторинг AtomPing заметил неполную chain через 5 минут после изменения.
Кейс 3: Kubernetes cert-manager quota. cert-manager в Kubernetes достиг rate limit Let's Encrypt (50 сертификатов на registered domain в неделю). Новые сервисы не могли получить сертификаты, а существующие начали истекать. SSL-мониторинг показал, что 5 сертификатов одновременно приближаются к expiry — что навело на проблему с cert-manager.
Чек-лист по SSL-безопасности
Пройдитесь по этому списку для каждого продакшн-домена:
1. Сертификат валиден и не истекает в ближайшие 30 дней.
2. Certificate chain полный — включает все intermediate сертификаты.
3. Hostname в сертификате совпадает с доменом (включая www и поддомены).
4. Минимальная версия протокола — TLS 1.2. TLS 1.0 и 1.1 отключены.
5. Auto-renewal настроен и работает (проверьте лог последнего обновления).
6. SSL-мониторинг активен с алертом за 30 дней до expiry.
7. HSTS включён (Strict-Transport-Security header).
8. HTTP → HTTPS редирект настроен для всех доменов.
SSL-мониторинг — это тот случай, когда 2 минуты настройки сейчас экономят часы аварийной работы потом. Настройте TLS-проверки для всех своих доменов сегодня — и вычеркните "expired certificate" из списка возможных причин downtime навсегда.
FAQ
What is SSL certificate monitoring?
SSL certificate monitoring is the automated process of tracking your SSL/TLS certificates for expiration dates, configuration issues, and chain validity. It alerts you days or weeks before a certificate expires, so you can renew it before your site becomes inaccessible or shows security warnings to visitors.
How often should I check my SSL certificates?
Check certificate expiration daily. Most monitoring tools, including AtomPing, run SSL checks alongside your regular uptime monitors — so every time your site is checked (every 1-5 minutes), the certificate validity is also verified. Expiry alerts are typically sent once when the certificate enters the warning window (e.g., 30 days before expiry).
Can Let's Encrypt certificates expire if I have auto-renewal?
Yes, absolutely. Auto-renewal fails more often than you'd expect. Common causes: DNS verification issues (changed DNS provider), firewall blocking the ACME challenge, certbot version incompatibility after OS update, expired API credentials for DNS-based validation. This is exactly why monitoring is essential even with auto-renewal.
What happens when an SSL certificate expires?
Browsers show a full-page security warning that most users won't click through. API clients and mobile apps refuse to connect entirely — they don't show a 'proceed anyway' option. Webhooks from services like Stripe stop delivering. Search engines may demote your site. In short: an expired certificate is effectively a full outage for most of your traffic.
How many days before expiry should I get alerted?
Set up three alert thresholds: 30 days (first warning — time to investigate if auto-renewal is working), 14 days (urgent — renew manually if auto-renewal hasn't kicked in), and 7 days (critical — drop everything and fix this). AtomPing lets you configure the expiry threshold in your alert policy settings.
Does SSL monitoring check more than just expiration?
Good SSL monitoring checks several things: certificate expiration date, chain completeness (all intermediate certificates present), hostname match (certificate covers your domain), protocol version (TLS 1.2+ required), and cipher strength. AtomPing's TLS monitoring verifies the full chain and reports days until expiry.