Автоматическое продление SSL-сертификата через Certbot и systemd

Сертификат Let’s Encrypt выпускается на ограниченный срок, поэтому его недостаточно один раз установить на сервер. Администратору нужно убедиться, что Certbot регулярно запускается, успешно проходит проверку домена, получает новый сертификат и заставляет веб-сервер перечитать обновленные файлы.

Наличие установленного Certbot еще не подтверждает, что автоматическое продление работает. Таймер может быть отключен, DNS — указывать на другой сервер, порт 80 — оказаться закрытым, а конфигурация Nginx или Apache — ссылаться на другой каталог сертификатов.

Иногда Certbot успешно продлевает сертификат, но посетители продолжают видеть прежний. Такая ситуация возникает, если HTTPS завершается на CDN, балансировщике или reverse proxy либо веб-сервер не перечитал конфигурацию после обновления файлов.

В этой инструкции разберем, как проверить весь процесс: от состояния сертификата и задания systemd до тестового продления, журналов, deploy-hook и внешней проверки сайта. Команды приведены для Linux-сервера с systemd. Способ установки Certbot и имена служебных единиц могут отличаться в зависимости от дистрибутива и источника пакета.

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

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

                 systemd timer
                       │
                       ▼
                 certbot renew
                       │
                       ▼
          Чтение параметров сертификата
                       │
              ┌────────┴────────┐
              ▼                 ▼
      Продление еще рано   Требуется продление
                                │
                                ▼
                     Проверка владения доменом
                                │
                   ┌────────────┴────────────┐
                   ▼                         ▼
             Проверка успешна          Проверка не пройдена
                   │                         │
                   ▼                         ▼
        Получение нового сертификата    Запись ошибки в журнал
                   │
                   ▼
              Deploy-hook
                   │
                   ▼
       Проверка и reload веб-сервера
                   │
                   ▼
        Внешняя проверка сертификата

Что делает команда certbot renew

Команда:

sudo certbot renew

проверяет конфигурации продления и пытается обновить сертификаты, для которых наступил соответствующий период. Она не должна каждый раз принудительно перевыпускать все найденные сертификаты.

Это важно по двум причинам:

• не создаются лишние запросы к центру сертификации;
• не расходуются ограничения на выпуск повторяющихся сертификатов;
• не выполняется ненужный reload веб-сервера;
• одна команда может обслуживать несколько доменов;
• задание можно безопасно запускать регулярно.

Что хранит Certbot

При стандартной установке рабочие данные Certbot обычно находятся в каталоге:

/etc/letsencrypt/

В нем могут находиться:

• актуальные ссылки на сертификаты;
• предыдущие версии файлов;
• конфигурации продления;
• учетные данные ACME;
• служебные параметры Certbot.

Для каждого сертификата важны файлы:

/etc/letsencrypt/live/example.ru/fullchain.pem
/etc/letsencrypt/live/example.ru/privkey.pem

В конфигурации веб-сервера обычно указываются пути из каталога live. Они являются ссылками на актуальную версию сертификата и закрытого ключа.

Какие способы проверки домена используются

Для wildcard-сертификатов применяется проверка через DNS. Обычная HTTP-проверка не позволяет получить сертификат на имя вида *.example.ru.

Как проверить установленные сертификаты

До проверки таймера нужно понять, какие сертификаты обслуживает Certbot, когда они заканчиваются и каким способом должны продлеваться.

Просмотр сертификатов Certbot

sudo certbot certificates

Для каждого найденного сертификата команда обычно показывает:

• имя сертификата в Certbot;
• домены;
• дату окончания;
• состояние;
• путь к сертификату;
• путь к закрытому ключу.

Нужно проверить, что в списке присутствует рабочий домен и все варианты имени, которые должны открываться по HTTPS.

Например, если используются оба адреса:

example.ru
www.example.ru

они должны быть включены в сертификат либо обслуживаться отдельными корректно настроенными сертификатами.

Просмотр срока действия файла

Проверить локальный файл можно через OpenSSL:

sudo openssl x509 \
    -in /etc/letsencrypt/live/example.ru/fullchain.pem \
    -noout \
    -subject \
    -issuer \
    -dates

Команда показывает данные файла на сервере, но не гарантирует, что именно этот сертификат получают посетители.

Проверка сертификата, который отдается извне

echo |
openssl s_client \
    -connect example.ru:443 \
    -servername example.ru \
    2>/dev/null |
openssl x509 \
    -noout \
    -subject \
    -issuer \
    -dates \
    -serial

Параметр -servername передает имя домена через SNI. Без него сервер с несколькими HTTPS-сайтами может вернуть сертификат другого виртуального хоста.

Сравните:

• дату окончания локального файла;
• серийный номер локального сертификата;
• дату и номер внешнего сертификата;
• имя издателя;
• фактический IP домена.

Серийный номер локального файла:

sudo openssl x509 \
    -in /etc/letsencrypt/live/example.ru/fullchain.pem \
    -noout \
    -serial

Проверка DNS

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

dig +short A example.ru
dig +short AAAA example.ru

При наличии AAAA-записи центр сертификации может обратиться к серверу по IPv6. Если IPv6 опубликован, но сайт по нему не обслуживается, проверка домена может завершиться ошибкой.

Дополнительно следует проверить:

• вариант с www;
• все имена из сертификата;
• отсутствие старого IP;
• настройки CDN;
• балансировщик;
• несколько A- или AAAA-записей.

Как проверить systemd timer

При пакетной установке Certbot автоматический запуск часто создается заранее. Не нужно сразу добавлять еще одно задание в cron: сначала следует проверить существующий механизм.

Найти таймер Certbot

systemctl list-timers --all |
    grep -i certbot

В зависимости от дистрибутива и способа установки таймер может называться:

certbot.timer
snap.certbot.renew.timer

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

systemctl list-unit-files |
    grep -i certbot

И задания cron:

sudo grep -R "certbot renew" \
    /etc/cron.d \
    /etc/crontab \
    /var/spool/cron 2>/dev/null

Одновременное отсутствие systemd timer и cron означает, что автоматический запуск, вероятнее всего, не настроен.

Проверить состояние таймера

Для стандартного имени:

systemctl status certbot.timer

Показать расписание:

systemctl list-timers certbot.timer

Просмотреть содержимое служебной единицы:

systemctl cat certbot.timer
systemctl cat certbot.service

Нужно обратить внимание на:

• состояние active;
• время следующего запуска;
• время последнего запуска;
• команду, выполняемую службой;
• случайную задержку запуска;
• наличие ошибок.

Включить существующий таймер

Если таймер установлен, но отключен:

sudo systemctl enable --now certbot.timer

После этого:

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

Для Certbot, установленного через Snap, следует использовать фактическое имя таймера, найденное через systemctl list-timers, а не создавать дубликат с другим именем.

Почему таймер запускается чаще, чем продлевается сертификат

Нормально, если systemd запускает проверку ежедневно или несколько раз в сутки, а сертификат не перевыпускается при каждом запуске. Команда certbot renew самостоятельно определяет, какие сертификаты уже нужно обновлять.

Не создавать второй механизм без необходимости

Дублирование systemd timer и cron может привести к параллельным запускам, путанице в журналах и сложной диагностике.

Перед добавлением собственного задания проверьте:

• способ установки Certbot;
• существующий systemd timer;
• системный cron;
• задания пользователя root;
• механизм панели управления;
• внешнюю автоматизацию провайдера.

Как выполнить безопасный тест продления

Главная проверка автоматизации — тестовый запуск, который проходит процесс продления с использованием тестовой инфраструктуры центра сертификации.

Запуск dry-run

sudo certbot renew --dry-run

Команда проверяет конфигурации продления без замены рабочего сертификата на тестовый.

Успешный результат означает, что на момент проверки:

• Certbot прочитал конфигурации;
• домен прошел проверку;
• используемый плагин сработал;
• Certbot смог выполнить тестовый выпуск;
• заданные хуки завершились без ошибки.

Однако dry-run не заменяет внешний мониторинг. До реального продления могут измениться DNS, firewall, токен DNS API, структура сайта или конфигурация веб-сервера.

Перед запуском проверить веб-сервер

Для Nginx:

sudo nginx -t

Для Apache в Debian и Ubuntu:

sudo apache2ctl configtest

Для Apache в других дистрибутивах команда может называться:

sudo httpd -t

Если конфигурация уже содержит ошибку, deploy-hook не сможет безопасно перезагрузить веб-сервер после продления.

Проверить доступность HTTP

Для проверки HTTP-01 порт 80 должен быть доступен извне:

sudo ss -lntp |
    grep -E ':(80|443)\s'

Проверка с другого компьютера:

curl -I http://example.ru/

Редирект с HTTP на HTTPS обычно допустим, если маршрут ACME challenge обрабатывается корректно. Но сложные редиректы, прокси и правила безопасности могут блокировать служебный запрос.

Не использовать force-renewal для обычной проверки

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

sudo certbot renew --force-renewal

Ее не следует применять как регулярный тест. Для проверки используется --dry-run, а принудительное рабочее продление выполняется только при понятной необходимости и с учетом ограничений центра сертификации.

Проверить отдельный сертификат

На сервере с несколькими сертификатами полезно сначала посмотреть их имена:

sudo certbot certificates

Затем можно ограничить тест выбранным именем сертификата:

sudo certbot renew \
    --cert-name example.ru \
    --dry-run

Значение после --cert-name должно совпадать с именем сертификата, которое показывает Certbot. Оно не всегда полностью совпадает с доменным именем.

Как настроить reload через deploy-hook

Certbot обновляет сертификат только тогда, когда это необходимо. Поэтому reload веб-сервера следует выполнять после успешного продления, а не после каждого запуска таймера.

Типы хуков Certbot

Для обычной конфигурации Nginx или Apache чаще всего требуется deploy-hook.

Каталоги хуков

Certbot может выполнять исполняемые файлы из каталогов:

/etc/letsencrypt/renewal-hooks/pre/
/etc/letsencrypt/renewal-hooks/deploy/
/etc/letsencrypt/renewal-hooks/post/

Создадим deploy-hook для Nginx:

sudo nano \
    /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Содержимое:

#!/bin/sh
set -eu

/usr/sbin/nginx -t
/bin/systemctl reload nginx

Сделать файл исполняемым:

sudo chmod 750 \
    /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Перед использованием проверьте фактические пути:

command -v nginx
command -v systemctl

Для Apache на Debian или Ubuntu:

#!/bin/sh
set -eu

/usr/sbin/apache2ctl configtest
/bin/systemctl reload apache2

На других дистрибутивах служба может называться httpd.

Почему сначала выполняется проверка конфигурации

Команды:

nginx -t
apache2ctl configtest

помогают не выполнять reload при синтаксической ошибке. Сам сертификат останется продленным, но веб-сервер не должен перечитывать заведомо некорректную конфигурацию.

Проверка deploy-hook

После создания хука снова выполните:

sudo certbot renew --dry-run

Затем проверьте:

• завершился ли dry-run без ошибки;
• выполнился ли хук;
• остался ли веб-сервер активен;
• нет ли новых ошибок в журнале;
• не выполняется ли лишний restart вместо reload.

Состояние Nginx:

systemctl status nginx --no-pager

Состояние Apache:

systemctl status apache2 --no-pager

Когда свой deploy-hook не нужен

Плагины Certbot для Nginx и Apache могут сами управлять конфигурацией и перечитыванием веб-сервера. Панели управления также используют собственный механизм.

До добавления хука проверьте:

• каким плагином выпущен сертификат;
• содержимое конфигурации продления;
• выполняется ли reload при dry-run;
• нет ли уже deploy-hook;
• не управляет ли сертификатом ispmanager или другая панель;
• не завершается ли TLS на отдельном прокси.

Повторный reload обычно не критичен, но дублирование автоматизации усложняет сопровождение.

Где смотреть журналы и как диагностировать ошибки

Если dry-run или реальное продление завершилось ошибкой, нужно сохранить полный текст сообщения и определить этап сбоя.

Журнал Certbot

Основной журнал обычно находится по адресу:

/var/log/letsencrypt/letsencrypt.log

Последние записи:

sudo tail -n 200 \
    /var/log/letsencrypt/letsencrypt.log

Поиск ошибок:

sudo grep -iE \
    "error|failed|unauthorized|timeout" \
    /var/log/letsencrypt/letsencrypt.log |
    tail -n 100

Перед передачей журнала проверьте наличие доменных данных, адресов и другой служебной информации.

Журнал systemd

Для стандартной службы:

sudo journalctl \
    -u certbot.service \
    --since "7 days ago" \
    --no-pager

Для установки через Snap имя определяется через:

systemctl list-units |
    grep -i certbot

Также можно посмотреть последнее выполнение таймера:

systemctl list-timers --all |
    grep -i certbot

Типичные ошибки продления

Ошибка HTTP-01

Сначала проверьте, куда указывает домен:

dig +short A example.ru
dig +short AAAA example.ru

Затем состояние веб-сервера:

sudo systemctl status nginx --no-pager

И доступность порта:

sudo ss -lntp |
    grep ':80 '

Проверьте firewall. Например, при использовании UFW:

sudo ufw status verbose

Кроме локального firewall могут действовать:

• сетевые правила провайдера;
• облачный firewall;
• NAT;
• CDN;
• защита от DDoS;
• внешний reverse proxy.

Неправильный webroot

При использовании плагина webroot Certbot должен записывать challenge в каталог, который фактически обслуживает домен.

Проверьте конфигурацию продления:

sudo sed -n '1,200p' \
    /etc/letsencrypt/renewal/example.ru.conf

Не изменяйте файл без резервной копии. Сначала сопоставьте указанный webroot с конфигурацией виртуального хоста.

Тестовый файл можно создать вручную:

sudo mkdir -p \
    /var/www/example.ru/.well-known/acme-challenge

echo "acme-test" |
sudo tee \
    /var/www/example.ru/.well-known/acme-challenge/test-file

Проверить извне:

curl \
    http://example.ru/.well-known/acme-challenge/test-file

После проверки файл нужно удалить:

sudo rm \
    /var/www/example.ru/.well-known/acme-challenge/test-file

Продление прошло, но сервер отдает старый сертификат

Проверьте последовательно:

1. Срок и серийный номер локального файла.
2. Пути в конфигурации веб-сервера.
3. Результат проверки конфигурации.
4. Выполнение reload.
5. Сертификат на внешнем адресе.
6. CDN и reverse proxy.
7. Другие серверы за балансировщиком.
8. Кэш промежуточных узлов.

Найти пути в конфигурации Nginx:

sudo nginx -T 2>/dev/null |
    grep -E \
    "ssl_certificate|ssl_certificate_key"

Для Apache:

sudo grep -R \
    "SSLCertificateFile\|SSLCertificateKeyFile" \
    /etc/apache2 \
    /etc/httpd 2>/dev/null

DNS-01 перестал работать

Для автоматического DNS-подтверждения проверьте:

• срок действия API-токена;
• разрешение на изменение нужной зоны;
• путь к файлу учетных данных;
• права на этот файл;
• название установленного DNS-плагина;
• соответствие версии плагина и Certbot;
• время распространения TXT-записи;
• отсутствие ручной конфигурации без автоматизации.

Файл с API-данными должен быть доступен только администратору:

sudo chmod 600 \
    /root/.secrets/certbot/dns.ini

Не размещайте токен DNS в публичном репозитории или в каталоге сайта.

Как организовать контроль срока действия

Даже успешно настроенное автоматическое продление может перестать работать после изменения инфраструктуры. Поэтому необходим независимый контроль сертификата снаружи.

Что контролировать

• дату окончания внешнего сертификата;
• доступность HTTPS;
• совпадение доменного имени;
• корректность цепочки;
• серийный номер после продления;
• возраст последнего успешного запуска Certbot;
• ошибки systemd service;
• состояние Nginx или Apache;
• все узлы балансировщика;
• отдельный сертификат на CDN.

Локальная проверка срока

Проверить, закончится ли локальный сертификат раньше заданного периода:

sudo openssl x509 \
    -checkend 2592000 \
    -noout \
    -in /etc/letsencrypt/live/example.ru/fullchain.pem

Значение 2592000 соответствует 30 дням в секундах. Команда возвращает код завершения, который можно использовать в системе мониторинга.

Пример проверки:

if sudo openssl x509 \
    -checkend 2592000 \
    -noout \
    -in /etc/letsencrypt/live/example.ru/fullchain.pem
then
    echo "Сертификат действует больше 30 дней"
else
    echo "Сертификат скоро закончится"
fi

Такая проверка контролирует файл на сервере. Для сайта за CDN или балансировщиком дополнительно нужен внешний мониторинг.

Почему уведомление должно приходить заранее

Ошибка может потребовать времени на:

• исправление DNS;
• восстановление доступа к DNS API;
• изменение firewall;
• проверку нескольких серверов;
• замену устаревшего Certbot;
• согласование изменений с владельцем инфраструктуры;
• перевыпуск сертификата другим способом.

Уведомление в последний день не оставляет безопасного времени на диагностику.

Чек-лист после настройки

• Certbot показывает нужный сертификат.
• Все используемые домены включены в сертификат.
• DNS указывает на правильную инфраструктуру.
• Найден и включен systemd timer либо другой штатный механизм.
• Не создано дублирующее задание cron.
• certbot renew --dry-run выполняется успешно.
• Deploy-hook проверяет конфигурацию и выполняет reload.
• Веб-сервер использует файлы из актуального каталога.
• Внешний сертификат совпадает с локальным.
• Настроено предупреждение об окончании срока.
• Проверены CDN, прокси и все узлы балансировщика.
• Ответственный знает, где смотреть журналы.

Заключение

Автоматическое продление SSL через Certbot нельзя считать настроенным только потому, что на сервере существует команда certbot. Необходимо проверить сертификаты, конфигурации продления, systemd timer, тестовый запуск и перечитывание файлов веб-сервером.

Основной проверкой служит команда certbot renew --dry-run. Она помогает обнаружить ошибки DNS, HTTP-подтверждения, webroot, плагина и deploy-hook без ненужного перевыпускания рабочего сертификата.

После успешного обновления веб-сервер должен перечитать новый сертификат. Для этого можно использовать deploy-hook с предварительной проверкой конфигурации Nginx или Apache.

Финальная проверка всегда выполняется снаружи. Локальный файл может быть актуальным, но пользователи продолжат получать старый сертификат от CDN, reverse proxy, другого виртуального хоста или одного из узлов балансировщика.

Что почитать дальше

Для выпуска сертификата и диагностики HTTPS будут полезны следующие материалы:

• Бесплатный SSL-сертификат для сайта — как подготовить домен, выпустить сертификат и проверить сайт после перехода на HTTPS.
• Ошибки SSL-сертификата — как диагностировать неверный домен, неполную цепочку, старый сертификат и mixed content.
• Зачем нужен SSL-сертификат — какие задачи решает HTTPS и от каких угроз он не защищает.

Когда стоит обратиться к специалистам

Стандартный сертификат для одного сайта можно проверить самостоятельно, если Certbot установлен штатным способом, домен указывает прямо на сервер, а HTTPS обслуживает один Nginx или Apache. При сложной инфраструктуре нужно учитывать дополнительные точки завершения TLS.

Специалисты IPWAY помогут проверить Certbot, systemd timer, DNS, конфигурацию Nginx или Apache и автоматическую установку обновленного сертификата. Для рабочих проектов также доступны SSL-сертификаты с помощью при выпуске, продлении и установке.

Если сайт размещается на собственном сервере, можно использовать Linux VPS от IPWAY с полным доступом к настройкам веб-сервера, сертификатов и автоматизации.

Кратко

• Наличие Certbot не подтверждает работу автоматического продления.
• Сначала нужно проверить список сертификатов, домены, сроки и пути к файлам.
• Штатное задание может работать через systemd timer, cron или механизм панели.
• Не следует создавать второй таймер, пока не проверена существующая автоматизация.
• Для безопасного теста используется certbot renew --dry-run.
• Deploy-hook выполняется после успешного обновления сертификата.
• Перед reload необходимо проверить конфигурацию веб-сервера.
• Финальный результат подтверждается внешней проверкой HTTPS и мониторингом срока действия.