Автопродление сертификатов Certbot и безопасная перезагрузка

Certbot обновил сертификат, но Nginx продолжает работать со старым состоянием — сайт может внезапно потерять HTTPS, хотя продление формально прошло успешно. В Certbot 2.x эту цепочку собирают из автоматического запуска renew и deploy-хука: он проверяет конфигурацию Nginx и отправляет ему команду мягкой перезагрузки только после успешного обновления сертификата.

Что должно происходить при продлении

Автоматизация состоит из двух независимых частей. Планировщик запускает certbot renew, а Certbot проверяет, пора ли продлевать сертификат. Если сертификат успешно обновлён, deploy-хук сообщает веб-серверу, что пора перечитать файлы. Если сертификат ещё не истекает, обновления нет — и deploy-хук не нужен.

В статье речь о Certbot 2.x и Nginx на Linux. Команды предполагают, что Certbot запускается с правами, достаточными для доступа к сертификатам и управления службой. Проверьте установленную версию командой certbot --version. Сам способ запуска Certbot зависит от установки: пакетный менеджер, snap и контейнер могут использовать разные таймеры и окружение.

• Убедитесь, что Nginx настроен на актуальные пути Certbot, обычно это файлы fullchain.pem и privkey.pem в каталоге сертификата.
• Проверьте, что командой systemctl reload nginx можно перезагрузить Nginx в вашей системе.
• Уточните, как именно у вас запускается Certbot: это может быть systemd-таймер или другой планировщик, установленный вместе с пакетом.

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

Три типа хуков — три разных момента

Certbot различает pre-, post- и deploy-хуки. Ошибка выбора обычно не ломает продление, но может приводить к лишним перезагрузкам или к ситуации, когда сертификат обновился, а сервер его не перечитал.

Для обычной перезагрузки Nginx выбирайте deploy-хук. Pre- и post-хуки способны срабатывать при очередном запуске renew, даже если Certbot не выпустил новый сертификат. Перезагружать сервер при каждой такой проверке — лишняя работа и дополнительный риск.

Продление и применение сертификата — разные события. Мониторьте оба: срок действия файлов и успешную перезагрузку сервиса.

Настройте deploy-хук для Nginx

Certbot умеет запускать исполняемые скрипты из каталога deploy-хуков. Для типичной Linux-установки создайте файл /etc/letsencrypt/renewal-hooks/deploy/10-reload-nginx со следующим содержимым:

#!/bin/sh
set -eu

# Не отправляем Nginx перезагрузку, если конфигурация не проходит проверку.
/usr/sbin/nginx -t
/usr/bin/systemctl reload nginx

Пути к nginx и systemctl различаются между системами. Проверьте их командами command -v nginx и command -v systemctl, затем при необходимости замените пути в скрипте. Если Nginx установлен в нестандартном месте или управляется не systemd, укажите подходящие для вашей установки команды.

1. Создайте каталог, если его ещё нет. Выполните sudo install -d -m 0755 /etc/letsencrypt/renewal-hooks/deploy. Проверка: каталог существует, и Certbot сможет прочитать его при запуске.
2. Сохраните скрипт. Создайте файл по указанному пути с содержимым выше. Проверка: команда sudo cat /etc/letsencrypt/renewal-hooks/deploy/10-reload-nginx показывает обе команды в правильном порядке.
3. Сделайте файл исполняемым. Выполните sudo chmod 0755 /etc/letsencrypt/renewal-hooks/deploy/10-reload-nginx. Проверка: файл имеет право на исполнение; посмотреть права можно через ls -l.
4. Проверьте скрипт отдельно от Certbot. Запустите его вручную от имени администратора. Проверка: nginx -t сообщает, что синтаксис корректен, а команда reload завершается без ошибки.
5. Проверьте сценарий продления. Запустите sudo certbot renew --dry-run. Проверка: тестовое продление завершается успешно. Не считайте этот запуск автоматической проверкой deploy-хука: поведение тестовых хуков зависит от версии и параметров Certbot. Сам скрипт уже проверен предыдущим шагом.

Команда в примере перезагружает Nginx после каждого успешного продления сертификата, обработанного этим экземпляром Certbot. Если на сервере есть сертификаты, которые Nginx не использует, общий хук всё равно может привести к перезагрузке. Тогда продумайте разделение Certbot по сервисам или отдельную проверку того, какие сертификаты обслуживает Nginx; не добавляйте в скрипт непроверенные переменные Certbot.

Когда достаточно общего хука, а когда нужен отдельный

Общий скрипт в каталоге deploy-хуков удобен на сервере, где все обновлённые сертификаты обслуживает один Nginx. Он прост в поддержке, но действует широко. Если один экземпляр Certbot обслуживает несколько приложений или служб, перезагрузка Nginx после обновления любого сертификата может оказаться ненужной.

Параметр командной строки --deploy-hook позволяет указать действие при запуске Certbot. Это полезно для разового ручного вызова, но не заменяет настройку автоматического запуска: если планировщик вызывает Certbot без этого параметра, действие из ручной команды не станет частью его расписания. Для постоянной настройки используйте поддерживаемый вашей установкой каталог хуков либо документированный способ конфигурации именно вашей версии.

Как выбрать

• Один веб-сервер и один общий сценарий перезагрузки — deploy-скрипт в каталоге хуков.
• Несколько служб с разными сертификатами — отдельные сценарии или явное разделение задач, чтобы обновление одного сертификата не перезапускало всё подряд.
• Нужно остановить службу перед проверкой домена — изучите pre-hook, но только если выбранный метод проверки этого требует.

Что ломается и как это заметить

Успешный certbot renew ещё не доказывает, что клиент сайта получает новый сертификат. Хук может не запуститься из-за прав, неправильного пути или отсутствия флага исполнения; Nginx может отвергнуть конфигурацию; планировщик может вообще не запускать Certbot. Проверяйте цепочку целиком.

• В журнале есть ошибка «Permission denied». Проверьте права на скрипт и каталоги. Убедитесь, что Certbot запускается с правами, нужными для исполнения хука.
• Появляется «nginx: command not found». В скрипте указан неверный путь к Nginx. Найдите его через command -v nginx и обновите путь.
• Проверка Nginx завершилась ошибкой. Не убирайте проверку ради перезагрузки. Сначала исправьте конфигурацию: reload не должен применять заведомо некорректные настройки.
• Сертификат обновился, но клиент видит старый. Убедитесь, что Nginx использует именно обновляемые файлы Certbot, а запрос не обслуживает другой узел, прокси или балансировщик.

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

Что делать дальше

После ручной проверки хука найдите таймер или задачу, которая запускает Certbot, и убедитесь, что она включена и не завершается ошибкой. Установки из разных источников используют разные механизмы — не создавайте второй планировщик, пока не выяснили, что уже настроено. Затем добавьте внешний мониторинг срока сертификата и проверку ответа сайта. Следующий полезный показатель — не просто «renew завершился успешно», а дата истечения сертификата, который реально получает клиент.

Смежная тема — настройка challenge-проверки домена и обновление сертификата на нескольких узлах; здесь рассматриваем только запуск действий после успешного обновления.