BASH
#certbot#letsencrypt#openssl#acme#ssl#troubleshooting

Certbot: проверка ACME challenge и срока действия сертификата

Проверка доступности .well-known/acme-challenge и проверка дат сертификата через openssl s_client. Для диагностики ошибок выпуска и продления.

Как использовать

  1. Проверка challenge: создай файл в .well-known/acme-challenge/ и запроси его через curl по HTTP.
  2. Проверка срока: openssl s_client + openssl x509 -noout -dates; подставь свой домен и порт 443.

При выпуске или продлении сертификата Let’s Encrypt по методу HTTP-01 проверка домена идёт по URL http://домен/.well-known/acme-challenge/TOKEN. Если этот путь не отдаётся веб-сервером, certbot выдаёт ошибку и сертификат не выдаётся. Отдельно после продления нужно убедиться, что nginx отдаёт уже новый сертификат, а не старый — иначе даты в браузере не обновятся. Проблема: непонятно, почему выпуск падает или продление «вроде прошло», но срок не изменился. Ниже — две диагностические проверки: доступность каталога для ACME challenge (curl к тестовому файлу) и проверка срока действия сертификата по HTTPS через openssl. По результатам можно исправить путь webroot или перезагрузить nginx.

Решение

Две типовые проверки: доступен ли каталог для HTTP-01 challenge (иначе certbot не сможет подтвердить домен) и какие даты у сертификата, который реально отдаёт сервер по HTTPS.

1. Доступность каталога для ACME challenge

Let’s Encrypt обращается по адресу http://домен/.well-known/acme-challenge/TOKEN. Файл должен отдаваться по HTTP без редиректа на HTTPS до выпуска сертификата.

Пример для домена example.com и webroot BitrixVM:

mkdir -p /home/bitrix/ext_www/example.com/public_html/.well-known/acme-challenge
echo test > /home/bitrix/ext_www/example.com/public_html/.well-known/acme-challenge/test.txt
chown -R bitrix:bitrix /home/bitrix/ext_www/example.com/public_html/.well-known

curl -s http://example.com/.well-known/acme-challenge/test.txt

Ожидаемый ответ: строка test. Если пусто, 404 или редирект — nginx не отдаёт этот путь или путь в certbot -w указан неверно.

2. Срок действия сертификата по HTTPS

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

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

Вывод: notBefore и notAfter — период действия. Если после продления даты не обновились, выполните systemctl reload nginx, чтобы nginx подхватил новые файлы из /etc/letsencrypt/live/.

Проверка

  1. Диагностика challenge — подставьте свой домен и путь к document root. Если curl возвращает пусто или 404:
# Проверить, что файл есть на диске
ls -la /home/bitrix/ext_www/example.com/public_html/.well-known/acme-challenge/
# Проверить HTTP-код ответа
curl -s -o /dev/null -w "%{http_code}" http://example.com/.well-known/acme-challenge/test.txt

Ожидаем 200. Если 301/302 — возможен редирект на HTTPS; до выпуска сертификата challenge должен отдаваться по HTTP.

  1. Полная информация по сертификату (субъект, издатель, даты):
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Убедитесь, что issuer — Let’s Encrypt и notAfter в будущем.

  1. После изменений в nginx — всегда перезагружайте конфиг: sudo nginx -t && sudo systemctl reload nginx, затем снова проверьте даты через openssl.

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

  • curl к challenge возвращает 404 — путь в -w у certbot не совпадает с document root в nginx для этого домена. Проверьте root в конфиге виртуального хоста и создайте .well-known/acme-challenge именно в этой папке. Права: владелец должен быть пользователь, от которого работает nginx (например bitrix:bitrix в BitrixVM).
  • Редирект с HTTP на HTTPS при запросе к .well-known — до первого успешного выпуска редиректить HTTP на HTTPS нельзя для пути /.well-known/acme-challenge/. Временно отключите редирект для этого location или выпустите сертификат, затем включите редирект.
  • notAfter не обновился после certbot renew — nginx не перезагружали. Настройте cron с deploy-hook или вручную выполните systemctl reload nginx после продления.

Где применять

  • Prod / dev: любой сервер с certbot и nginx (BitrixVM, VPS). Проверка challenge — перед первым выпуском и при ошибках продления; проверка дат — после ручного или автоматического renew.
  • BitrixVM: путь к document root — /home/bitrix/ext_www/ДОМЕН/public_html, см. Выпуск сертификата webroot.

Связанные сниппеты: Выпуск сертификата webroot в BitrixVM, Продление и cron с deploy-hook, Nginx и SSL Let’s Encrypt для BitrixVM.

Источники: Let’s Encrypt — HTTP-01 challenge, OpenSSL s_client, x509.

Похожие сниппеты