Let’s Encrypt с 4 июня 2025 года перестаёт слать письма об истечении SSL/TLS-сертификатов. Официальная позиция: автоматизация уже норма, хранить миллионы email ради напоминаний накладно и лишний privacy-риск, инфраструктуру уведомлений хотят упростить.
Для DevOps это не «конец света», а сигнал: если продление и мониторинг держатся на письме от CA, процесс хрупкий. Ниже – зачем LE это делает и что настроить у себя.
Почему отключают expiration emails
1. Автопродление стало стандартом
Certbot, acme.sh, lego, встроенные ACME-клиенты у reverse-proxy и панели хостинга уже сами обновляют сертификаты. Письмо «сертификат скоро истечёт» для нормально настроенного контура почти всегда шум.
2. Конфиденциальность
Чтобы слать напоминания, нужно годами хранить адреса и привязку к доменам. LE давно позиционирует себя как минималистичный CA: меньше персональных данных – меньше поверхность атаки и compliance-головной боли.
3. Ресурсы и простота
Массовая почтовая рассылка – отдельный сервис, очереди, bounces, abuse. Отказ от него освобождает мощность и убирает ещё одну точку отказа в стеке LE.
Что сделать в своей инфраструктуре
1. Автоматическое продление
Базовый вариант с Certbot: тихий renew по cron или systemd timer.
certbot renew --quiet
Пример cron (каждый день в 03:00):
0 3 * * * certbot renew --quiet
После успешного renew обычно нужен reload/restart web-сервера (deploy-hook у certbot удобнее ручного restart «на всякий случай»).
2. Свой мониторинг сроков
Не ждите письма от CA. Проверяйте сертификат сами:
- Zabbix / Nagios / Icinga – item или check «дней до notAfter»
- Prometheus + blackbox/ssl exporter – метрики и алерты в Alertmanager
- Простая проверка с хоста – openssl + cron + Telegram/email
Быстрый ручной контроль:
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \ | openssl x509 -noout -dates
3. Внешние мониторы (если удобно)
Можно переложить «напомнить за N дней» на SaaS: UptimeRobot, Better Stack, специализированные SSL-мониторы, Red Sift Certificates и аналоги. Смысл тот же: алерт в ваш канал, а не зависимость от почты LE.
4. Документация и runbook
Уберите из внутренних wiki фразы вроде «придёт письмо от Let’s Encrypt». Добавьте: где крутится ACME-клиент, какой timer/cron, куда падают логи renew, как выглядит аварийный сценарий.
5. Аварийное продление
На случай сбоя авто-renew (rate limit, DNS, firewall, упавший challenge):
certbot renew --force-renewal systemctl reload nginx
--force-renewal используйте осознанно: LE rate limits никто не отменял. Лучше починить причину failed renew, а force оставить для инцидента.
Итог
LE убирает костыль «мы вам напомним». Нормальный контур уже выглядит так: ACME-клиент + timer, проверка notAfter в мониторинге, алерт в on-call, runbook на force renew. Если так и было – почти ничего не меняется. Если продление держалось на почте – самое время это починить до июня 2025.
- Автопродление, а не ручной клик раз в 60-90 дней
- Мониторинг срока действия в своей системе
- Внешние алерты по желанию
- Актуальный runbook для команды
