Let's Encrypt SSL на сервере: частые ошибки и решения

MAATRIX

Let's Encrypt почти всегда «просто работает», но когда не работает — сообщения об ошибках пугают: проверка домена не прошла, превышен лимит запросов, сертификат внезапно истёк. Ниже — частые ошибки Let's Encrypt SSL на VPS и как их чинить: по каждой — причина и конкретные команды. Полезно держать в голове общую картину, тогда почти любая ошибка становится понятной. Let's Encrypt не верит на слово: прежде чем выдать сертификат, центр сертификации должен убедиться, что домен действительно под вашим контролем. Он делает это проверкой — либо запрашивает специальный файл по HTTP на порту 80 вашего сервера (способ HTTP-01), либо ищет заданную TXT-запись в DNS домена (способ DNS-01). Отсюда растут почти все проблемы выпуска: если домен указывает не на тот сервер, порт 80 закрыт, мешает прокси или DNS не успел распространиться — проверка не проходит. А проблемы продления — это те же проверки, только через 60–90 дней, когда условия успели измениться: кто-то закрыл порт, переписал конфиг веб-сервера или сменил DNS. Держа эту логику в уме, вы почти всегда сразу понимаете, в какую сторону копать.

Проверка домена не проходит (challenge failed)

Самая частая ошибка при выпуске: certbot пишет что-то вроде Challenge failed for domain или Invalid response from .... Let's Encrypt не смог подтвердить, что домен ваш. Проверьте три вещи по порядку.

Домен указывает на этот сервер:

dig +short ваш-домен.ru

IP в ответе должен совпадать с IP VPS. Частый случай — за DNS стоит Cloudflare в режиме «проксирования» (оранжевое облако), и проверка бьётся о прокси. На время выпуска включите «DNS only» (серое облако) или используйте DNS-01.

Порт 80 открыт и доступен снаружи:

ufw allow 80/tcp
ufw reload
curl -I http://ваш-домен.ru/.well-known/acme-challenge/test

Проверка HTTP-01 идёт именно по порту 80 — если он закрыт фаерволом или облачной security group, выпуск не пройдёт, даже когда сайт работает по другому порту.

Rate limit: превышен лимит запросов

После нескольких неудачных попыток certbot начинает отвечать too many failed authorizations или too many certificates already issued. У Let's Encrypt есть лимиты: около 5 повторных выпусков одного набора доменов в неделю и лимит неудачных проверок в час.

Не долбите выпуск вслепую. Пока отлаживаете конфигурацию, используйте тестовую среду staging — там лимиты огромные, а сертификаты невалидные (только для проверки, что процесс проходит):

certbot --nginx -d ваш-домен.ru --dry-run

--dry-run бьёт по staging и не тратит недельный лимит. Когда --dry-run проходит чисто — запускайте боевой выпуск. Если лимит уже упёрт, остаётся ждать окончания недельного окна: сбросить его нельзя.

Сертификат не продлился и истёк

Сайт вдруг выдаёт «Ваше подключение не защищено». Значит автопродление не сработало. Сначала посмотрите, жив ли таймер:

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

Затем прогоните продление руками и смотрите на ошибку:

certbot renew --dry-run

Три частые причины провала автопродления: за время жизни сертификата закрыли порт 80 (продление по HTTP-01 не прошло); удалили или переименовали server-блок, на который ссылался certbot; сменили веб-сервер, а плагин остался старый. Починив причину, продлите принудительно:

certbot renew --force-renewal
systemctl reload nginx

Чтобы не ловить это впредь — держите порт 80 всегда открытым и раз в квартал заглядывайте в certbot renew --dry-run.

Ошибка «mixed content» после включения HTTPS

Сертификат валиден, замок горит, но в консоли браузера — предупреждения, а часть картинок и скриптов не грузится. Это mixed content: страница отдаётся по HTTPS, а внутри ссылки на ресурсы по http://. Браузер блокирует небезопасные вставки.

Лечится на стороне сайта — заменой абсолютных http://-ссылок на https:// или на относительные. Быстрый способ подстраховаться на уровне Nginx — заголовок, который просит браузер сам подтягивать ресурсы по HTTPS:

add_header Content-Security-Policy "upgrade-insecure-requests" always;

Но правильнее всё же поправить сами ссылки в шаблонах и базе (для CMS есть плагины поиска-замены URL). Заголовок — временный костыль, а не решение.

Порт 80 закрыт, но нужен HTTPS: DNS-01

Иногда порт 80 занять нельзя — например, за сервером стоит балансировщик, отдающий только 443. Тогда HTTP-01 не подходит, используйте проверку DNS-01: она подтверждает владение через TXT-запись, порт не нужен вовсе:

certbot certonly --manual --preferred-challenges dns -d ваш-домен.ru

Certbot выдаст значение TXT-записи, которое надо добавить в зону домена; после распространения — нажать Enter. Минус ручного DNS-01 — продлевать придётся тоже руками, если не подключить плагин вашего DNS-провайдера с API. Тот же способ обязателен для wildcard-сертификатов.

«certbot command not found» и конфликт клиентов

После установки система пишет certbot: command not found или ставит слишком старую версию из репозитория дистрибутива. Проверьте, что установлен именно пакет certbot и плагин:

apt install certbot python3-certbot-nginx
which certbot

Второй источник хаоса — несколько ACME-клиентов на одном сервере (certbot и, скажем, acme.sh) наперегонки продлевают один домен и мешают друг другу. Оставьте один клиент. Посмотреть, какие сертификаты и чем управляются:

certbot certificates

Команда покажет все сертификаты под управлением certbot, их домены и срок действия — удобно для ревизии.

Слабый рейтинг SSL и старые протоколы

Сертификат валиден, но тест защищённости ставит низкую оценку. Обычно виноваты устаревшие протоколы и шифры. Ограничьте Nginx современными версиями TLS:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

Проверьте и перезагрузите:

nginx -t && systemctl reload nginx

После этого стоит включить HSTS — но только осознанно, потому что откатить его тяжело. И помните: сертификат шифрует канал, а безопасность сервера в целом держится на фаерволе, входе по SSH-ключу и своевременных обновлениях.

Отдельно стоит сказать про самопроверку перед тем, как звать на помощь. Прежде чем гадать, полезно посмотреть на подробный лог самого certbot — он пишет причину отказа человеческим языком, а не только код ошибки. Загляните в журнал последнего запуска и найдите строку с объяснением, почему проверка не удалась: там прямо будет сказано, вернул ли сервер не тот ответ, был ли недоступен порт или сработал лимит. Это экономит часы: вместо перебора гипотез вы читаете конкретную причину и чините именно её. И помните разницу между тестовой средой staging и боевой: если отлаживаете процесс, всегда добавляйте флаг пробного прогона — так вы не сожжёте недельный лимит на настоящих сертификатах, пока ищете причину.

Разобравшись с проверкой домена, портом 80 и автопродлением, вы получаете HTTPS, о котором можно забыть на годы. Для этого нужен сервер с белым IP и контролем над DNS и фаерволом — VPS в MAATRIX оплачивается картой РФ, по СБП или криптой, без иностранной карты.

Частые вопросы