Чем опасен Let’s Encrypt с точки зрения эксплуатации инфраструктуры?

Let's Encrypt — это прекрасный инструмент, но его использование в продакшене сопряжено с операционными рисками, которые необходимо учитывать в DevOps-практиках:

1. Риск протухания сертификата из-за сбоя автоматизации: Короткий срок жизни сертификата (90 дней) требует безупречной работы автоматического обновления. Сбой в cron, в скрипте обновления или в вызове webhook для перезагрузки сервиса (nginx, Apache) приведет к отказу сервиса.

   # Ненадежный cron-задание (нет обработки ошибок и алертинга)
   0 3 1 * * /usr/bin/certbot renew

2. Ограничения скорости (Rate Limits): Let's Encrypt имеет строгие лимиты (например, 50 сертификатов на домен в неделю). При частых пересборках окружений или ошибках в скриптах можно быстро исчерпать лимит, что заблокирует выпуск новых сертификатов.

3. Зависимость от внешнего CA и его доступности: Проблемы с API Let's Encrypt или с вашим интернет-соединением в момент обновления могут сорвать процесс.

4. Сложность управления для большого числа доменов и wildcard-сертификатов: Для инфраструктуры с сотнями доменов процесс обновления нужно тщательно проектировать, возможно, с использованием DNS-провайдера API для прохождения challenge.

Меры противодействия:

• Мониторинг срока действия сертификатов: Интеграция проверки в Prometheus/Grafana с алертами за 30, 15 и 7 дней до окончания срока.
• Идемпотентные и отказоустойчивые пайплайны обновления: Использование инструментов вроде cert-manager в Kubernetes, который управляет всем жизненным циклом.
• Резервный план: Наличие скрипта для быстрого переключения на резервный, долгоживущий сертификат от другого CA в случае критического сбоя.