Certbot: как проверить сертификат и не пропустить сбой.

Certbot решает выпуск, но не весь HTTPS

Certbot помогает выпустить и продлить сертификат, но он не гарантирует, что сайт отдаёт свежий файл пользователю. Сертификат может успешно обновиться в каталоге, а веб-сервер продолжит держать старый файл в памяти. Может пройти dry-run, но боевой выпуск упасть из-за CAA, DNS, rate limit, закрытого порта или изменённого vhost. Поэтому Certbot нужно проверять как часть эксплуатации, а не как кнопку «сделать HTTPS».

Первый уровень — понять, каким способом выпускался сертификат: webroot, standalone, nginx plugin, apache plugin или DNS challenge. От этого зависит, что может сломаться. Webroot требует доступности `.well-known`, standalone требует свободного порта, DNS challenge требует правильной зоны и API-доступа, nginx plugin зависит от конфигурации веб-сервера.

Если нужен общий порядок автоматического продления, рядом подходит материал автопродление и проверка SSL-сертификатов. Здесь акцент на том, как не пропустить сбой уже после настройки.

Проверка timer, dry-run и логов

На большинстве современных серверов Certbot продлевается через systemd timer. Нужно проверить, что timer включён, когда он запускался и какой статус у последней попытки. Затем выполнить `certbot renew --dry-run`. Dry-run не гарантирует успешный боевой выпуск во всех будущих условиях, но показывает, что базовый путь валидации сейчас рабочий.

Логи Certbot важнее, чем сообщение в панели. В них видно, какой домен проверялся, какой challenge использовался, где возникла ошибка, был ли вызван deploy hook. Если выпуск падает, не нужно сразу удалять сертификат и создавать новый. Сначала читают лог, затем проверяют DNS, CAA, порт 80/443, webroot и права на файлы.

CAA может заблокировать выпуск неожиданно, особенно после переноса зоны или усиления политики домена. Если Certbot внезапно перестал выпускать сертификат, стоит сверить CAA-записи и выпуск SSL-сертификатов до того, как менять веб-сервер.

Обновился файл — перезагрузился ли веб-сервер

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

Проверка должна идти снаружи. Посмотреть дату файла на сервере полезно, но важнее увидеть, что отдаёт домен через HTTPS. Для этого используют браузер, `openssl s_client -servername` и `curl -v`. Материал как проверить SSL-сертификат сайта без лишних сервисов закрывает эту часть без привязки к онлайн-сканерам.

Deploy hook лучше держать простым и явным. Например, после успешного продления выполнить `systemctl reload nginx`. Но hook должен быть проверен: команда существует, у Certbot хватает прав, reload не падает из-за ошибки в другой части конфигурации. Если `nginx -t` не проходит, новый сертификат может быть готов, но применить его не получится.

Что смотреть до даты истечения сертификата

Мониторинг должен смотреть не только файлы на сервере, а публичный сертификат на домене. Важно видеть срок, имя, цепочку и фактический endpoint. Если сайт за CDN, мониторинг edge-сертификата и origin-сертификата могут быть разными задачами. Если несколько поддоменов используют разные сертификаты, проверяют каждый критичный адрес.

Хороший практический блок: раз в настройке проверить `certbot certificates`, timer, dry-run, логи, deploy hook, `nginx -t`, reload и внешний сертификат. Затем поставить напоминание или мониторинг за 30, 14 и 7 дней до истечения. Если сертификат важен для панели, API или оплаты, проверка должна быть строже, чем для тестовой страницы.

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

Кейс: сертификат продлился, сайт всё равно истёк

На сервере Certbot успешно продлил сертификат за две недели до истечения. Владелец видел новые файлы в `/etc/letsencrypt/live/`, поэтому считал задачу закрытой. В день истечения браузеры начали показывать ошибку. Проверка показала, что Nginx всё это время отдавал старый сертификат, потому что deploy hook не выполнял reload после renew.

Причина была простой: команда reload была написана в старом скрипте, но после миграции на systemd путь изменился, и hook молча не применял новую конфигурацию. После исправления hook, проверки `nginx -t` и внешнего `openssl` сайт начал отдавать свежий сертификат. Вывод: успешный renew — это половина проверки. Вторая половина — убедиться, что новый сертификат реально видит пользователь.

Как убедиться, что Certbot обновил именно нужный узел

Файл и процесс

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

DNS и выпуск

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

Клиенты

VPN для Android, VPN для iPhone и VPN для Windows могут по-разному принимать цепочку. Профиль VPN сохраняют до правки. VPN не подключается после обновления — фиксируют точным сообщением. Не отключайте проверку доверия ради исчезновения предупреждения.

Контроль

VPN соединение проверяют новой сессией. Проверить VPN соединение нужно через штатный клиент, а не только просмотром файла. DNS через VPN относится к отдельной проверке. Надежный VPN имеет журнал продления и возможность отката к прежнему сертификату.

В этой схеме серверная часть — профиль vpn; рядом разобраны vpn подписка и клиентские шаги для vpn для macos и vpn для видео.

FAQ по Certbot

Как проверить, что Certbot продлит сертификат?

Проверьте `certbot certificates`, systemd timer или cron, затем выполните `certbot renew --dry-run`. Один факт текущего сертификата не доказывает будущий renew.

Что делает `certbot renew --dry-run`?

Он имитирует процесс продления на тестовой инфраструктуре CA и показывает, пройдёт ли validation. Это не заменяет проверку reload веб-сервера.

Почему сертификат продлён, а сайт отдаёт старый?

Certbot мог обновить файл, но nginx или apache не перечитал конфигурацию. Нужен deploy hook, reload и проверка внешнего TLS-ответа.

Где искать логи Certbot?

Обычно в `/var/log/letsencrypt/`. Там видно validation, ошибки challenge, проблемы с webroot, DNS и результат попытки renew.

Продлит ли Certbot сертификат для VPN сам по себе?

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

Certbot обновил файл, но сертификат VPN остался старым — почему?

Нужный процесс мог продолжить использовать прежний сертификат либо читать другой путь. Сначала проверьте сертификат VPN в реальном соединении, затем настройки загрузки. Уточните сертификат для VPN по имени и правилам выпуска. Автопродление файла и применение его конкретной службой — два разных шага.