Почему истекают SSL-сертификаты, даже с автопродлением

Сертификат истёк в выходные. Браузер показывает «Ваше подключение не защищено», API-клиенты отказываются соединяться, мобильное приложение разом теряет связь с бэкендом. Всё это происходит без предупреждения — ведь команда была уверена: «у нас же Let’s Encrypt, он продлевается сам».

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

Сроки действия сокращаются

Ещё недавно сертификат покупали на год и надолго о нём забывали. Теперь так не получится. По решению CA/Browser Forum — организации, которая задаёт правила для удостоверяющих центров и браузеров, — максимальный срок действия публичных сертификатов сокращается поэтапно:

Let’s Encrypt идёт быстрее: сейчас его сертификаты действуют 90 дней, с февраля 2027 года — 64 дня, а с февраля 2028-го — 45 дней. А с июня 2025 года Let’s Encrypt больше не присылает письма о скором истечении сертификатов — следить за сроками теперь нужно самим.

Вывод простой: ручное продление уходит в прошлое, а автопродление должно работать безотказно — и кто-то должен это проверять.

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

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

Закрыт порт 80 или проверку перехватывает CDN

Самый распространённый способ подтвердить домен в Let’s Encrypt — проверка HTTP-01: удостоверяющий центр запрашивает файл по адресу http://ваш-домен/.well-known/acme-challenge/…. Если новое правило файрвола закрыло порт 80, перед сервером появился CDN или WAF, который не пропускает такие запросы, или редирект ведёт не туда, — проверка не проходит.

DNS-записи изменились после переезда

Домен переехал на новый сервер или к новому провайдеру, а продление по-прежнему настроено на старой машине. Проверка HTTP-01 уходит на новый адрес, где нет нужного файла. А при проверке DNS-01 сломаться могут API-токен DNS-провайдера или его плагин.

CAA-запись не разрешает ваш удостоверяющий центр

CAA-записи указывают, каким удостоверяющим центрам разрешено выпускать сертификаты для домена. Если кто-то добавил CAA-запись только для коммерческого центра, Let’s Encrypt откажет в продлении.

Не работает таймер или cron-задача продления

certbot продлевает сертификаты по расписанию — через systemd-таймер или cron-задачу. Таймер могли отключить, при переносе сервера cron-задачу не перенесли, а сам certbot перестал запускаться после обновления системы. Снаружи это никак не заметно, пока сертификат не истечёт.

В Kubernetes продлением обычно занимается cert-manager (как его настроить), и сбои у него те же: проверка не проходит, а сертификат продолжает стареть. Состояние видно в ресурсе Certificate:

kubectl get certificate -A
kubectl describe certificate <имя> -n <namespace>

Сертификат продлён, но сервер отдаёт старый

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

certbot renew --deploy-hook "systemctl reload nginx"

Сертификат продлён не везде

TLS часто терминируется не на том сервере, где работает certbot: на балансировщике, в CDN, на втором сервере за балансировщиком. Сертификат продлили на одной машине, а на остальных он доживает срок.

После перевыпуска сломалась цепочка

Сертификат действителен, но сервер не отдаёт промежуточный. Десктопные браузеры часто «достраивают» цепочку сами, а часть мобильных клиентов, curl и HTTP-библиотеки в коде выдают ошибку. Для nginx это обычно означает, что в ssl_certificate указан cert.pem вместо fullchain.pem. Проверить, сколько сертификатов отдаёт сервер, можно так — их должно быть больше одного:

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null \
  | grep -c "BEGIN CERTIFICATE"

Как убедиться, что автопродление работает

1. Прогоните продление вхолостую: certbot renew --dry-run проверит весь процесс на тестовом сервере Let’s Encrypt и покажет ошибку, если что-то не так.
2. Убедитесь, что расписание продления существует: systemctl list-timers | grep -i certbot или запись в crontab.
3. Проверьте сертификат, который сервер реально отдаёт клиентам, а не файл на диске:

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

certbot продлевает 90-дневный сертификат за 30 дней до истечения, поэтому дата notBefore не должна быть старше 60 дней. Если она старше, продление сломалось — даже если до notAfter ещё далеко. Другие способы посмотреть срок действия — в браузере и через онлайн-сервисы — разобраны в статье «Как проверить срок действия SSL».

Чек-лист: что сделать прямо сейчас

1. Инвентаризация доменов и поддоменов: основной сайт, api, staging, админка, почта, внутренние сервисы. Просроченные сертификаты живут именно на забытых поддоменах, о которых вспоминают, только когда кто-то присылает скриншот с предупреждением браузера.
2. Для каждого домена — удостоверяющий центр, способ продления (certbot, cert-manager, вручную), дата notAfter и ответственный.
3. certbot renew --dry-run на каждом сервере, где выпускаются сертификаты.
4. Deploy-hook с перезагрузкой веб-сервера и доставкой сертификата на все узлы, где терминируется TLS.
5. Полная цепочка сертификатов на каждом домене.
6. Внешний мониторинг с порогом ниже точки автопродления.
7. Аварийная процедура: кто и как экстренно перевыпускает сертификат, если он истёк в выходные.

Автоматический мониторинг срока действия

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

• проверяет сертификат снаружи — так же, как это делает реальный клиент, — для всех доменов из списка, включая поддомены;
• предупреждает заранее. Для Let’s Encrypt порог разумно ставить ниже точки автопродления — например, 20 дней: алерт сработает, только если продление не случилось. Для коммерческих сертификатов — от 30 дней;
• следит не только за датой: цепочка и доверие, соответствие имени домена, протоколы и шифры, известные уязвимости TLS;
• доставляет алерты туда, где команда их увидит, — в мессенджер, а не в почтовый ящик, который открывают раз в месяц.

Такой мониторинг проверяет не само автопродление, а его результат. Поэтому он ловит сбой на любом шаге: закрытый порт, мёртвый таймер, забытый reload или узел, до которого не доехал новый сертификат.

Как настроить мониторинг SSL в Pingera

Проверка SSL-сертификата в Pingera смотрит на сертификат снаружи, как реальный клиент: срок действия, цепочку и доверие, соответствие имени домена, поддерживаемые протоколы и шифры, известные уязвимости вроде Heartbleed и ROBOT. По итогам проверка выставляет оценку безопасности с рекомендациями по улучшению — о том, как довести её до максимума, мы писали в статье «Как получить A+ по безопасности SSL/TLS с Nginx Ingress». Поддерживаются и сертификаты Минцифры.

В настройках проверки задаётся порог в днях: как только до истечения сертификата останется меньше, проверка станет проваленной и придёт алерт. Отдельно можно задать минимальную оценку безопасности — тогда вы узнаете и о том, что конфигурация TLS стала хуже. Уведомления приходят в Telegram, MAX, на почту, по SMS или в вебхук.

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

Начать можно на бесплатном тарифе — для пет-проектов и домашних серверов этого достаточно. Для продакшн-доменов подойдут тарифы Про — от 1800 ₽/мес; при оплате за год два месяца бесплатно, а для юрлиц доступна оплата по счёту и документооборот через ЭДО.

Часто задаваемые вопросы

Итог

Автопродление не гарантирует, что сертификат не истечёт: проверка домена, расписание, перезагрузка сервера и доставка сертификата на все узлы ломаются молча. А с сокращением сроков до 47 дней продлений станет в разы больше. Проверьте продление вхолостую, настройте deploy-hook и поставьте внешний мониторинг: Pingera предупредит заранее — за столько дней, сколько вы зададите, а не в момент, когда пользователи уже видят предупреждение браузера.