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

Для сайта на Ubuntu 22.04 или 24.04 с Nginx сертификат Let's Encrypt можно получить и подключить примерно за 10–20 минут. Чаще всего новички упираются не в сам Certbot, а в DNS, закрытый порт 80, лишнюю AAAA-запись или виртуальный хост, который не знает нужное доменное имя. Ниже — рабочая последовательность для Certbot 2.x и Nginx, а затем разбор ошибок, из-за которых выпуск сертификата останавливается.

Что подготовить до начала

Инструкция рассчитана на сервер с Ubuntu 22.04 или 24.04, установленным Nginx и доступом по SSH с правами sudo. Домен в примерах замените на свой, например example.com.

• Доменная запись A указывает на публичный IPv4-адрес сервера.
• Если у домена есть запись AAAA, она указывает на рабочий IPv6-адрес этого же сервера. Если IPv6 не настроен, запись лучше временно удалить.
• Порты 80 и 443 разрешены в облачном firewall, группе безопасности и локальном firewall сервера.
• Nginx уже установлен и обслуживает сайт по HTTP.
• В конфигурации Nginx есть виртуальный хост с правильным server_name.

Проверьте базовую конфигурацию до установки Certbot:

sudo nginx -t
curl -I http://example.com
getent ahosts example.com

Проверка пройдена, если Nginx сообщает syntax is ok и test is successful, HTTP-запрос получает ответ от вашего сервера, а getent показывает ожидаемый адрес.

Пошаговое подключение через Certbot

1. Обновите сведения о пакетах и установите Certbot через Snap. Для Ubuntu это рекомендуемый способ получить актуальную версию клиента. Если Certbot уже установлен из APT, сначала проверьте его версию: смешивать две установки без необходимости не стоит.

   sudo apt update
   sudo snap install core
   sudo snap refresh core
   sudo snap install --classic certbot
   sudo ln -s /snap/bin/certbot /usr/local/bin/certbot
   certbot --version

   Проверка: команда выводит версию Certbot 2.x или более новую доступную версию, а не сообщение command not found. Если ссылка уже существует, последняя команда может сообщить, что файл есть: это не означает, что установка сломалась.

2. Убедитесь, что Nginx отвечает именно на нужный домен. Откройте конфигурацию виртуального хоста и проверьте строку server_name. В ней должны быть все имена, для которых нужен сертификат, например example.com www.example.com.

   sudo nginx -t
   curl -I http://example.com
   curl -I http://www.example.com

   Проверка: оба домена возвращают ответ от вашего Nginx. Код 404 сам по себе не мешает выпуску сертификата, если запрос действительно пришёл на этот сервер; ошибка связи и чужая страница — мешают.

3. Запустите мастер Certbot для Nginx.

   sudo certbot --nginx

   Certbot попросит адрес электронной почты, согласие с условиями и имена доменов. На вопрос о перенаправлении выберите вариант с автоматическим переходом с HTTP на HTTPS, если сайт уже корректно работает по HTTPS и внутри приложения нет жёстко заданных HTTP-ссылок.

   Проверка: в конце появится сообщение о том, что сертификат сохранён, а Nginx перезагружен. Откройте https://example.com в браузере и убедитесь, что адресная строка не показывает ошибку сертификата.

4. Проверьте, какие сертификаты установлены.

   sudo certbot certificates

   Проверка: в списке есть нужные домены и путь к сертификату. Обычно Certbot хранит данные в каталоге /etc/letsencrypt; вручную редактировать файлы внутри него не нужно.

5. Проверьте автоматическое продление. Сертификаты Let's Encrypt выдаются на ограниченный срок, поэтому важен не только первый выпуск.

   sudo certbot renew --dry-run

   Проверка: тестовое продление завершается без ошибки. Команда ничего не продлевает по-настоящему, а проверяет сценарий обновления и доступ к серверу.

Если Certbot пишет, что не может подтвердить домен, не начинайте с повторной установки Nginx. Сначала проверьте, куда указывает DNS и может ли внешний сервер открыть порт 80.

ACME-челлендж — проверка, с помощью которой Let's Encrypt убеждается, что вы управляете доменом. При варианте HTTP-01 центр сертификации обращается к специальному адресу на вашем сайте через порт 80.

Частые ошибки новичков

1. DNS указывает не на этот сервер

Сообщение может выглядеть как Timeout during connect, connection refused или unauthorized. Причина не всегда в Certbot: домен мог ещё не обновиться у DNS-провайдеров, либо запись A ведёт на старый IP.

Проверьте записи у регистратора и сравните их с публичным адресом сервера. Если используется CDN или прокси, запрос Let's Encrypt может попадать не на Nginx, а на промежуточный сервис. На время диагностики оставьте маршрут до сервера прозрачным или используйте документацию своего CDN.

2. AAAA-запись отправляет запросы в нерабочий IPv6

Это одна из самых неприятных ошибок: по IPv4 сайт открывается, а центр сертификации выбирает IPv6 и получает тайм-аут. Браузер конкретного пользователя может при этом успешно переключиться на IPv4, поэтому проблема долго остаётся незаметной.

Если IPv6 на сервере не настроен, удалите AAAA-запись или настройте IPv6 до конца: маршрут, firewall, прослушивание Nginx и разрешение порта 80. Нельзя оставлять запись только потому, что она появилась в панели хостинга автоматически.

3. Порт 80 закрыт или занят не тем сервисом

Для HTTP-01 порт 80 должен быть доступен из интернета. Веб-сайт может открываться по HTTPS, но этого недостаточно для первого выпуска, если проверка использует HTTP.

sudo ss -ltnp | grep -E ':(80|443)\b'
sudo ufw status

Если на порту 80 нет Nginx, проверьте конфигурацию и firewall. Если порт занят Apache, Caddy или контейнером, нужно либо настроить проверку через уже работающий веб-сервер, либо остановить конфликтующий сервис на время — но только если сайт после этого не станет недоступен.

4. В Nginx указан другой домен

Certbot может не найти подходящий виртуальный хост, если в нём написано только имя сервера, а вы запрашиваете сертификат для другого имени. Например, конфигурация обслуживает www.example.com, а команда запущена для example.com.

Добавьте оба имени в server_name, проверьте конфигурацию командой sudo nginx -t и перезагрузите Nginx. Не заменяйте перезагрузку полным перезапуском без причины: при ошибке конфигурации сервис может не подняться.

5. Файлы сайта закрыты правилами Nginx

Ошибка unauthorized появляется, если сервер отдаёт неправильный ответ для пути проверки, например перенаправляет его в приложение, возвращает 403 или всегда отвечает страницей ошибки. Это часто происходит из-за глобального правила rewrite, basic auth или запрета доступа к скрытым каталогам.

Временно уберите правило, которое перехватывает все HTTP-запросы, или настройте исключение для пути проверки. После выпуска сертификата повторно включите защиту и отдельно проверьте, что автоматическое продление проходит командой sudo certbot renew --dry-run.

6. Смешаны Certbot из APT и Snap

Команда certbot может запускать одну версию, а автоматическое обновление будет настроено для другой. В результате первый сертификат выпускается, но через несколько недель продление не срабатывает.

Проверьте путь к исполняемому файлу и список установленных пакетов. Выберите один способ установки, удалите лишнюю версию только после проверки зависимостей и снова выполните тестовое продление. Не удаляйте каталог /etc/letsencrypt: там находятся сертификаты и настройки Certbot.

Когда автоматическое изменение Nginx — плохая идея

Режим --nginx удобен для обычного сайта, но осторожность нужна на сервере с несколькими приложениями, нестандартными шаблонами конфигурации и управлением через Docker или Ansible. Certbot может добавить директивы в другой виртуальный хост или изменить редирект, который использует приложение.

Перед запуском сохраните конфигурацию в системе контроля версий или сделайте резервную копию. После запуска сравните изменения, проверьте sudo nginx -t, откройте главную страницу и выполните тест продления. Если конфигурация управляется кодом инфраструктуры, лучше описать TLS там, а не оставлять ручное изменение, которое следующий деплой перезапишет.

Что проверить после выпуска

• HTTPS открывается для каждого имени, включённого в сертификат.
• HTTP перенаправляется на HTTPS только один раз, без циклического редиректа.
• Приложение видит исходную схему HTTPS, если за Nginx работает прокси или CMS.
• Статические файлы, формы и внешние API не загружаются по HTTP, если браузер блокирует mixed content.
• sudo certbot renew --dry-run завершается успешно после изменений firewall или DNS.

Что делать дальше

Сначала сохраните конфигурацию Nginx и зафиксируйте результат команды sudo certbot certificates. Затем добавьте проверку HTTPS и тестового продления в мониторинг: важны срок действия сертификата, доступность портов 80 и 443 и успешный ответ приложения после перезагрузки Nginx. Инвалидация старых сертификатов и настройка DNS-01 для закрытых сервисов — отдельные задачи; для обычного публичного сайта достаточно довести до рабочего состояния HTTP-01 и регулярно проверять продление.