Как обновить и настроить автопродление сертификата через Certbot

Введение

Сертификаты Let's Encrypt живут 90 дней. Это компромисс: короткий срок снижает риски компрометации ключей, но требует надёжного автоматического продления. Certbot — самый распространённый клиент для получения и обновления таких сертификатов. Если автопродление настроено неправильно, сайт однажды встретит посетителей ошибкой NET::ERR_CERT_DATE_INVALID, а почта и API-интеграции начнут падать.

В этом гайде разберём, как вручную обновить сертификат, как убедиться, что автопродление действительно работает, как проверить таймеры systemd и задачи cron, как настроить хуки для перезагрузки веб-сервера и что делать, если certbot renew завершается ошибкой. Материал рассчитан на администраторов Linux-серверов с базовым опытом работы в терминале.

Требования и исходные условия

Перед началом убедитесь, что у вас есть:

• Linux-сервер (Ubuntu/Debian, CentOS/RHEL/AlmaLinux, Fedora) с root-доступом или sudo.

• Установленный Certbot (пакет certbot или python3-certbot-nginx / python3-certbot-apache).

• Действующий сертификат, выданный ранее (например, через certbot --nginx или certbot certonly).

• Открытые порты 80 и/или 443 для прохождения ACME-проверки (либо настроенный DNS-плагин).

• Работающий веб-сервер (Nginx, Apache) или другой сервис, использующий сертификат.

Проверить версию Certbot и наличие сертификатов можно так:

certbot --version
sudo certbot certificates

Команда certbot certificates покажет список сертификатов, домены, путь к файлам и дату истечения. Это отправная точка для любой диагностики.

Шаг 1. Проверьте текущий срок действия сертификата

Прежде чем что-то обновлять, посмотрите, сколько осталось дней. Это поможет понять, работает ли автопродление вообще.

sudo certbot certificates

В выводе обратите внимание на строки Expiry Date и Certificate Path. Если до истечения меньше 30 дней, а сертификат не обновился автоматически, значит, автопродление сломано. Дополнительно можно проверить сертификат «снаружи»:

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

Так вы увидите реальные даты notBefore и notAfter, которые отдаёт сервер, а не только файлы на диске.

Шаг 2. Обновите сертификат вручную

Certbot обновляет сертификаты командой renew. Она проходит по всем сертификатам, срок которых подходит к концу (по умолчанию — менее 30 дней), и пытается их продлить.

sudo certbot renew

Если нужно обновить конкретный сертификат принудительно, независимо от срока:

sudo certbot renew --cert-name example.com --force-renewal

Флаг --force-renewal использует новый приватный ключ и создаёт новую линию сертификата. Не применяйте его без необходимости: у Let's Encrypt есть лимиты на выдачу (duplicate certificate limit). Для обычного обновления достаточно certbot renew.

Если сертификат получен через плагин Nginx или Apache, Certbot сам перезагрузит сервис после успешного продления. Если используется certonly (webroot, standalone, DNS), перезагрузку нужно делать вручную или через хук — об этом ниже.

Шаг 3. Проверьте, что автопродление включено

Современные пакеты Certbot устанавливают таймер systemd certbot.timer, который запускает certbot renew дважды в день со случайной задержкой. Проверить его состояние:

systemctl status certbot.timer
systemctl list-timers | grep certbot

Если таймер активен (active (waiting)), автопродление уже работает. Посмотреть расписание следующего запуска можно в выводе systemctl list-timers. Если таймера нет (например, в контейнере или на старом дистрибутиве), проверьте cron:

ls -l /etc/cron.d/certbot
cat /etc/cron.d/certbot

Типичная строка в cron выглядит как запуск certbot renew с рандомизированной задержкой. Если ни таймера, ни cron-задачи нет — автопродление нужно настроить вручную (см. шаг 5).

Шаг 4. Сделайте тестовый прогон (dry-run)

Самая полезная команда для диагностики — --dry-run. Она имитирует продление, обращается к staging-серверу Let's Encrypt и не расходует лимиты на реальную выдачу.

sudo certbot renew --dry-run

Успешный вывод заканчивается сообщением Congratulations, all simulated renewals succeeded. Если появляются ошибки, читайте их внимательно: чаще всего проблема в ACME-проверке (порт 80 закрыт, неверный webroot, DNS не указывает на сервер) или в правах доступа к файлам.

Dry-run стоит запускать после любого изменения конфигурации: смены веб-сервера, переезда, изменения DNS, обновления пакетов. Это дешёвый способ поймать проблему до того, как сертификат реально истечёт.

Шаг 5. Настройте автопродление через systemd или cron

Если таймера нет, создайте его. Для systemd создайте unit-файлы:

# /etc/systemd/system/certbot-renew.service
[Unit]
Description=Certbot renewal

[Service]
Type=oneshot
ExecStart=/usr/bin/certbot renew --quiet

# /etc/systemd/system/certbot-renew.timer
[Unit]
Description=Run certbot renewal twice daily

[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=3600
Persistent=true

[Install]
WantedBy=timers.target

Затем включите таймер:

sudo systemctl daemon-reload
sudo systemctl enable --now certbot-renew.timer
systemctl list-timers | grep certbot

Альтернатива — cron. Добавьте задачу от root:

0 3,15 * * * /usr/bin/certbot renew --quiet --deploy-hook "systemctl reload nginx"

Запуск дважды в день с запасом в 30 дней гарантирует, что даже при временных сбоях (недоступность Let's Encrypt, проблемы с DNS) будет несколько попыток до истечения сертификата.

Шаг 6. Настройте хуки для перезагрузки сервисов

Если сертификат используется сервисом, который не перезагружается автоматически (Nginx при certonly, Postfix, Dovecot, HAProxy, собственное приложение), нужен deploy-хук. Certbot поддерживает два типа хуков:

• --pre-hook — выполняется перед попыткой продления (например, остановить standalone-сервер, освободить порт 80).

• --deploy-hook — выполняется только после успешного продления.

Пример для Nginx:

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

Чтобы хук применялся при каждом автозапуске, пропишите его в конфигурации обновления /etc/letsencrypt/renewal/example.com.conf в секции [renewalparams]:

renew_hook = systemctl reload nginx

Или создайте исполняемый скрипт в /etc/letsencrypt/renewal-hooks/deploy/, например reload-nginx.sh с содержимым #!/bin/sh\nsystemctl reload nginx. Certbot выполнит все скрипты из этой папки после успешного обновления. Это удобнее, чем дублировать хуки в каждой конфигурации.

Шаг 7. Проверьте конфигурацию renewal-файлов

Для каждого сертификата Certbot хранит файл /etc/letsencrypt/renewal/<name>.conf. В нём указаны домены, метод аутентификации (authenticator), webroot и параметры плагина. Если вы меняли способ проверки (например, перешли с standalone на webroot), старый конфиг может ломать продление.

Посмотрите файл:

sudo cat /etc/letsencrypt/renewal/example.com.conf

Убедитесь, что:

• authenticator соответствует реально используемому плагину.

• webroot_path указывает на существующую директорию, доступную веб-серверу.

• Список domains актуален (нет удалённых поддоменов).

Если домен больше не существует, его нужно убрать из сертификата командой certbot renew --cert-name example.com после правки конфигурации или перевыпустить сертификат с новым списком доменов.

Шаг 8. Разберите типичные ошибки

Ошибка ACME-проверки (challenge failed). Сервер Let's Encrypt не смог достучаться до http://example.com/.well-known/acme-challenge/.... Причины: закрыт порт 80, DNS указывает на другой IP, редирект с HTTP на HTTPS настроен до проверки, файрвол или CDN блокирует запросы. Проверьте доступность извне и временно отключите жёсткий редирект для пути /.well-known/acme-challenge/.

`Problem binding to port 80`. Порт занят веб-сервером, а выбран плагин standalone. Либо остановите сервис на время проверки через --pre-hook, либо перейдите на webroot или плагин Nginx/Apache.

`Too many failed authorizations`. Временная блокировка после серии неудачных попыток. Подождите указанное в сообщении время (обычно час) и устраните причину, прежде чем повторять.

`Rate limit exceeded`. Превышен лимит Let's Encrypt на дубликаты или неудачные проверки. Не запускайте --force-renewal многократно. Для тестов используйте --dry-run или staging-сервер (--staging).

Сертификат обновился, но браузер показывает старый. Сервис не перезагрузился. Проверьте deploy-хук и вручную перезагрузите Nginx/Apache. Убедитесь, что в конфигурации веб-сервера указан правильный путь к fullchain.pem.

`certbot.timer` не срабатывает. Проверьте systemctl status certbot.timer и журнал journalctl -u certbot.timer -u certbot.service. Часто причина — отключённый таймер после обновления пакета или ошибка в unit-файле.

Шаг 9. Настройте уведомления о сбоях

Даже работающее автопродление стоит контролировать. Простой способ — мониторинг срока действия сертификата извне (Zabbix, Prometheus blackbox exporter, Uptime Kuma, внешние сервисы проверки SSL). Настройте алерт, если до истечения осталось меньше 14 дней.

Второй уровень — уведомления от самого Certbot. В новых версиях можно указать email при регистрации (--email), и Let's Encrypt пришлёт письмо, если сертификат близок к истечению. Дополнительно настройте отправку вывода certbot renew в лог и алерт на ненулевой код возврата:

/usr/bin/certbot renew --quiet || echo "certbot renew failed" | mail -s "Certbot error" admin@example.com

Шаг 10. Обновите Certbot и проверьте зависимости

Устаревший Certbot — частая причина проблем с новыми ACME-требованиями. Обновляйте пакет штатным менеджером:

sudo apt update && sudo apt install --only-upgrade certbot
# или
sudo dnf upgrade certbot

После обновления перезапустите таймер и снова выполните certbot renew --dry-run. Если вы ставили Certbot через snap, обновление идёт командой sudo snap refresh certbot.

Типичные ошибки

• Использование `--force-renewal` для «проверки». Это расходует лимиты Let's Encrypt. Для проверки есть --dry-run.

• Отсутствие deploy-хука. Сертификат на диске новый, а сервис отдаёт старый — классическая ситуация при certonly.

• Редирект HTTP→HTTPS на весь сайт. ACME-проверка по HTTP ломается. Исключите путь /.well-known/acme-challenge/ из редиректа.

• Закрытый порт 80 «для безопасности». HTTP-01 challenge требует доступности порта 80. Если это неприемлемо, используйте DNS-01 challenge.

• Ручной запуск `certbot renew` без расписания. Один раз обновить недостаточно — нужен таймер или cron.

• Игнорирование dry-run после изменений. Переезд или смена DNS незаметно ломают продление.

• Отсутствие мониторинга. Без алерта о сбое вы узнаете об истечении сертификата от пользователей.

FAQ

Как часто Certbot пытается продлить сертификат? По умолчанию таймер запускает certbot renew дважды в день. Реальное продление происходит, когда до истечения остаётся менее 30 дней. Certbot сам решает, нужно ли обновлять конкретный сертификат.

Можно ли обновить сертификат раньше 30 дней? Да, с флагом --force-renewal или --renew-by-default, но это расходует лимиты. Обычно в этом нет необходимости.

Что делать, если `certbot renew` пишет «No renewals were attempted»? Значит, ни один сертификат не подошёл к порогу продления. Это нормально. Проверить список и даты можно командой certbot certificates.

Нужно ли останавливать Nginx для продления? Нет, если используется плагин Nginx, webroot или DNS. Остановка нужна только для плагина standalone, и то её можно автоматизировать через --pre-hook и --post-hook.

Где хранятся сертификаты и ключи? В /etc/letsencrypt/live/<name>/: fullchain.pem (сертификат + цепочка), privkey.pem (приватный ключ), cert.pem, chain.pem. В конфигурации веб-сервера используйте fullchain.pem и privkey.pem.

Как перевыпустить сертификат с новыми доменами? Используйте certbot certonly --cert-name example.com -d example.com -d new.example.com с тем же методом аутентификации. Certbot обновит существующий сертификат, сохранив имя.

Безопасно ли удалять старые файлы в `/etc/letsencrypt/archive/`? Не рекомендуется вручную чистить архив: Certbot управляет символическими ссылками в live/. Удаление может сломать продление и работу веб-сервера.

Итог

Автопродление сертификатов через Certbot — это не одна команда, а связка из нескольких элементов: работающего таймера или cron-задачи, корректного метода ACME-проверки, deploy-хука для перезагрузки сервисов и внешнего мониторинга срока действия. Ручное обновление (certbot renew) полезно для разовых ситуаций, но ставку стоит делать на автоматику с двойным ежедневным запуском и запасом в 30 дней.

Минимальный чек-лист: certbot certificates показывает здоровый срок, certbot renew --dry-run завершается успешно, systemctl list-timers содержит активный certbot.timer, deploy-хук перезагружает веб-сервер, а мониторинг пришлёт алерт за две недели до истечения. Если все пять пунктов выполнены, сертификат не станет неожиданностью ни для вас, ни для пользователей.