IIAdmin
← На главнуюTLS и сертификаты
Практическое руководство

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

2026-10-09Источников: 2Тема: tls-04

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

Задача и общий подход

Материал посвящён теме «Автоматическое продление сертификатов Certbot» с акцентом на журналам, автоматизации и контролю изменений.

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

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

Что должно получиться

После выполнения руководства по теме «Автоматическое продление сертификатов Certbot» результат должен быть измеримым:

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

Когда применять этот порядок

Этот сценарий подходит для следующих ситуаций:

  • плановое внедрение или перенос компонента категории «TLS и сертификаты» на новый VPS
  • изменение портов, домена, сертификата, маршрута или способа публикации сервиса
  • разбор инцидента, когда локальная и внешняя проверки дают разные результаты
  • подготовка к обновлению пакета или восстановлению после неудачного изменения

Как устроена схема

Клиент устанавливает TCP-соединение, передаёт SNI и согласует TLS до обычного HTTP-запроса. HTTP-01 требует доступного порта 80, DNS-01 подтверждает управление DNS-зоной и подходит для wildcard.

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

Резервная точка

Сохраните именно те файлы и параметры, которые собираетесь менять.

Универсальная фиксация состояния

TS=$(date +%F-%H%M%S)
mkdir -p /root/iiadmin-change-$TS
cp -a /path/to/config /root/iiadmin-change-$TS/
systemctl status SERVICE --no-pager > /root/iiadmin-change-$TS/status-before.txt
ss -lntup > /root/iiadmin-change-$TS/listeners-before.txt

Замените путь и SERVICE. Для активных баз данных используйте штатный экспорт, а не обычный cp.

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

Подготовка перед изменениями

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

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

Пошаговая настройка

Выполняйте блоки последовательно и после каждого шага проверяйте код возврата команды.

Таймер

systemctl list-timers --all | grep -i certbot
journalctl -u certbot.timer -n 50 --no-pager

Имя юнита зависит от способа установки.

DNS и порты

dig +short A example.org
ss -lntp | grep -E ':(80|443)\b'
curl -I http://example.org/

Домен должен указывать на нужный сервер, а challenge быть доступен.

Локальный сертификат

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

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

Сертификат на порту

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

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

Тест продления

sudo certbot renew --dry-run

Выявляет большинство проблем до истечения срока.

Имена доменов, адреса, порты и пути в примерах условные. Перед выполнением замените их фактическими значениями.

Проверка результата

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

  • DNS актуален
  • сертификат содержит имя
  • цепочка полная
  • системное время корректно
  • dry-run успешен

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

systemctl is-active SERVICE
systemctl status SERVICE --no-pager
journalctl -u SERVICE -n 80 --no-pager
ss -lntup

Замените SERVICE и сохраните вывод рядом с резервной копией.

Диагностика, если не заработало

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

  1. Подтвердите симптом точной командой и запишите время.
  2. Проверьте конфигурацию штатным тестом.
  3. Проверьте процесс и последние записи журнала.
  4. Убедитесь, что нужный адрес и порт слушаются.
  5. Сравните локальный запрос с запросом извне.
  6. Только затем проверяйте firewall, DNS и маршрут.
  7. Меняйте одну переменную и повторяйте тот же тест.

Для темы «Автоматическое продление сертификатов Certbot» важно не путать открытый firewall с запущенным сервисом: правило доступа не создаёт listener, а активный процесс не гарантирует доступность извне.

Безопасность

После получения рабочего результата уменьшите количество исключений и временных разрешений.

  • выдавайте файлам конфигурации минимальные права
  • ограничивайте административный доступ доверенными IP или VPN
  • закрывайте временные порты после завершения теста
  • не храните секреты в публикуемых конфигурациях и журналах
  • просматривайте журналы аутентификации и ошибки запуска

Дальнейшее сопровождение

Рабочая конфигурация со временем устаревает и требует контроля.

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

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

Чаще всего восстановление усложняют следующие действия:

  • использование устаревшей команды без проверки версии пакета
  • открытие административного порта для всего интернета
  • удаление рабочей конфигурации до успешного запуска новой
  • перезапуск службы до проверки синтаксиса
  • проверка только локального подключения без внешнего теста
  • игнорирование различий правил IPv4 и IPv6

Откат изменений

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

  1. вернуть прежние пути сертификата
  2. проверить права ключа
  3. выполнить nginx -t
  4. перезагрузить и повторить openssl-проверку

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

Контрольный список

Перед тем как считать тему «Автоматическое продление сертификатов Certbot» закрытой, пройдите список:

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

Что дополнительно сверить в документации

При подготовке материала были сопоставлены разделы русскоязычной документации. Для углублённой проверки полезно изучить:

  • Настройка HTTPS-серверов
  • Как развернуть свой веб-сайт в облаке с помощью Next.js, Django, SSL, DNS
  • План действий
  • Необходимые требования
  • VDS и VPS
  • Настройка сервера
  • Установка нужного комплекта программ
  • Настройка безопасности

Финальная проверка с точки зрения реального клиента

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

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

Тест продления

sudo certbot renew --dry-run

Выявляет большинство проблем до истечения срока.

Поэтапное применение обновления

Обновляйте один компонент за раз, выполняя штатный тест и клиентскую проверку после каждого этапа. Для кластера или нескольких узлов используйте тестовый экземпляр.

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

Ошибки, блокировки и журнал запуска

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

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

Права на закрытый ключ и применение сертификата

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

После изменения путей выполните штатный тест конфигурации и reload. Затем повторно снимите сертификат с публичного порта: наличие нового файла на диске ещё не означает, что сервис использует его.

Проверить файлы и путь

sudo namei -l /etc/letsencrypt/live/example.org/privkey.pem
sudo openssl x509 -in /etc/letsencrypt/live/example.org/fullchain.pem -noout -dates
sudo nginx -t

Не выводите содержимое закрытого ключа в терминал или журнал.

Источники и документация

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