SystemdDoctor
служба не работает certbot сертификаты частое

certbot: проверка владения доменом не проходит

Проверка владения доменом по способу http-01 требует, чтобы запрос к пути с проверкой доходил до certbot. Сбой почти всегда означает одно из трёх: порт занят, каталог проверки не тот, или веб-сервер перехватывает запрос редиректом на HTTPS.

Что это значит

Самая коварная причина — редирект. Если блок на 80-м порту целиком уводит запросы на HTTPS, проверка тоже уходит туда и не доходит до файла. Поэтому путь проверки объявляют выше редиректа.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Запрос проверки перехватывается редиректом на HTTPS

    Правило «весь http на https» действует и на путь проверки. Certbot кладёт файл, а запрос до него не доходит.

  2. Порт 80 занят или закрыт

    Способ проверки standalone поднимает свой сервер на 80-м порту и не может этого сделать при работающем веб-сервере. Плюс порт может быть закрыт брандмауэром.

  3. Указан не тот каталог проверки

    Способ webroot кладёт файл в указанный каталог, а веб-сервер отдаёт его из другого. Пути должны совпадать.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Полный прогон обновления без расхода лимитов выдачи.

sudo certbot renew --dry-run

Доходит ли запрос проверки: ответ 404 нормален, 301 — проблема.

curl -sI http://ваш-домен/.well-known/acme-challenge/test

Сроки действия сертификатов: главный показатель.

sudo certbot certificates

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Запрос проверки перехватывается редиректом на HTTPS
Почему происходит
Правило «весь http на https» действует и на путь проверки. Certbot кладёт файл, а запрос до него не доходит.
Как проверить
Проверьте, что путь отдаётся по обычному http. 
curl -sI http://ваш-домен/.well-known/acme-challenge/test | head -3
Как исправить
Объявите путь проверки выше редиректа в конфигурации веб-сервера. 
# в блоке на 80 порту, выше редиректа:
# location ^~ /.well-known/acme-challenge/ { root /var/www/acme; }
2. Порт 80 занят или закрыт
Почему происходит
Способ проверки standalone поднимает свой сервер на 80-м порту и не может этого сделать при работающем веб-сервере. Плюс порт может быть закрыт брандмауэром.
Как проверить
Посмотрите владельца порта и доступность извне. 
sudo ss -tlnp | grep ":80\s"
curl -sI --max-time 5 http://ваш-домен/ | head -2
Как исправить
Используйте способ через каталог в корне сайта (webroot) вместо standalone: он работает при включённом веб-сервере. 
sudo certbot certonly --webroot -w /var/www/acme -d ваш-домен --dry-run
3. Указан не тот каталог проверки
Почему происходит
Способ webroot кладёт файл в указанный каталог, а веб-сервер отдаёт его из другого. Пути должны совпадать.
Как проверить
Сравните каталог certbot и корень, из которого отдаётся путь проверки. 
sudo grep -r "webroot" /etc/letsencrypt/renewal/ 2>/dev/null | head
sudo nginx -T 2>/dev/null | grep -A2 "acme-challenge"
Как исправить
Приведите пути к одному значению в настройках обновления и в конфигурации веб-сервера.

Пример вывода

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

certbot[4500]: Challenge failed for domain example.org
certbot[4500]: http-01 challenge for example.org
certbot[4500]: Detail: <адрес>: Invalid response from http://example.org/.well-known/acme-challenge/xVbC...: 301

Связанные ошибки

Где встречается чаще всего

Источники

  • Документация certbot: способы проверки документация программы
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено редиректом всего http на https без исключения для пути проверки.     собственная проверка, systemd 255
    сверено 15 сентября 2026