Certbot ставит себе systemd-таймер или cron-задачу автоматически при установке и дважды в сутки проверяет, не пора ли продлевать SSL-сертификат для сайта. Продление запускается по умолчанию за 30 дней до истечения – запас времени выглядит большим. На практике эта тихая надёжность и подводит: certbot renewничего не делает вне окна продления и так же молча падает при ошибке, потому что встроенного алертинга у него нет. Администратор узнаёт о проблеме одновременно с посетителями сайта – по красному замку в браузере.
Как продление ломается на практике
Один личный сервер два года подряд продлевал сертификаты без единого сбоя, пока на него не добавили новый сервис под health-check, занявший порт 80. HTTP-01-проверка Let's Encrypt перестала проходить, три цикла продления подряд провалились молча, а об истёкшем сертификате администратор узнал из письма пользователя сайта.
Это один из шести задокументированных сценариев тихого отказа. Systemd-таймер может отключиться при обновлении пакета. Новый location-блок в конфиге nginx способен перехватить /.well-known/acme-challenge/ раньше самого ACME-челленджа. DNS-01-хук иногда завершается кодом 0, хотя запись в DNS реально не распространилась. После апгрейда дистрибутива путь к бинарнику certbot нередко «уезжает» между snap и apt. Диск может переполниться так, что лог в /var/log/letsencrypt перестаёт писаться, и продление прерывается. А слишком частые --dry-run прогоны сами способны упереться в лимит запросов.
Ещё коварнее ловушка с отсутствием --deploy-hook для перезагрузки веб-сервера. Сертификат на диске обновляется успешно, certbot репортит success, а nginx или apache продолжают отдавать старый истёкший сертификат прямо из памяти процесса, пока их явно не перезапустить. Формально продление отработало, а сайт всё равно падает с ошибкой сертификата.
Масштаб проблемы, если автоматизации много
12 марта 2026 сбой продления на масштабе Kubernetes-кластера обошёлся одной компании в 127 минут простоя TLS-терминации сразу для 14 000+ продакшн-сервисов в трёх регионах AWS. Cron-задача cert-manager сменила окно продления на 2 часа вместо 30 дней, а пакетное продление 12 раз подряд упёрлось в лимит на дублирующиеся сертификаты – 5 одинаковых наборов доменов за 7 дней. Постмортем компании оценил ущерб в $42 000 SLA-штрафов. Кейс относится к Kubernetes и cert-manager, поэтому цифру ущерба не стоит переносить на одиночный certbot на VPS как типовую. Сам механизм сбоя – узкое окно продления в связке с лимитом запросов – при этом одинаково актуален для любого масштаба.
Продления через новый механизм ACME Renewal Info полностью освобождены от лимита на дублирующиеся сертификаты, поэтому стоит сначала проверить, использует ли установленный certbot этот механизм – лимиты на практике не такие неизменные, как кажутся на первый взгляд.
Как проверить, что автопродление реально работает
Ручной запуск certbot renew --dry-run имитирует полный цикл продления без реального выпуска сертификата и покажет ошибку заранее, если что-то из перечисленного выше сломано. Стоит сверять дважды: сразу после первичной настройки и через несколько месяцев, когда в конфиге сервера что-то уже успело измениться.
Дату истечения на живом сайте можно проверить напрямую, не полагаясь на память о том, что «настроил и работает»:
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
Если notAfter в выводе ближе, чем 30 дней от текущей даты, а certbot renew --dry-run при этом отработал без ошибок, дело почти наверняка в --deploy-hook: сертификат обновился на диске, но веб-сервер об этом не узнал.
Что изменится в ближайшие два года
Let's Encrypt объявил переход на более короткие сертификаты. С мая 2026 доступен ранний профиль на 45 дней. С февраля 2027 стандартный профиль сократится до 64 дней. С февраля 2028 он перейдёт на 45 дней с окном на подтверждение авторизации всего 7 часов вместо нынешних 30 дней запаса. Продление придётся выполнять вдвое чаще, а времени на то, чтобы заметить и исправить сбой до истечения, будет заметно меньше. Проверенная сейчас связка --deploy-hook и регулярный --dry-run окупится ещё сильнее, когда привычный запас сократится втрое.
Частые вопросы
Как понять, что certbot не смог продлить сертификат?
Команда certbot certificates показывает точную дату истечения каждого установленного сертификата. Если дата ближе, чем ожидалось, продление где-то сломалось молча, и стоит прогнать --dry-run для диагностики конкретной причины.
Нужен ли alert на почту при сбое продления?
Для продакшн-сайта да, потому что сам certbot алертинга не даёт. Уведомление собирается отдельно – например, cron-джобой, которая сверяет notAfter сертификата с текущей датой и шлёт письмо, если срок подошёл вплотную.
Что делать, если certbot не находит nginx после обновления сервера?
Проверить путь к бинарнику certbot между snap- и apt-версией – при обновлении дистрибутива это чаще всего рвёт cron-задачу без явной ошибки в логах systemd.
Заключение
Автопродление Let's Encrypt редко ломается сразу. Обычно оно исправно работает месяцами, а иногда и годами, и в этом сама ловушка: то, что стабильно работало, никто не проверяет. Регулярный --dry-runявный --deploy-hook для перезагрузки веб-сервера и отдельный алерт на дату истечения закрывают почти все сценарии из этого разбора – настроить их один раз дешевле, чем объяснять клиентам предупреждение о небезопасном соединении на сайте.
Комментарии