Как подключить SSL Let's Encrypt на Nginx: живой пример
Разбираем подключение HTTPS для сайта на Ubuntu 22.04/24.04 и Nginx: проверяем DNS, выпускаем сертификат через Certbot, включаем перенаправление и тестируем автоматическое продление.
Сайт на Nginx можно перевести на HTTPS примерно за 15–30 минут, если домен уже указывает на сервер, а порты 80 и 443 доступны из интернета. Ниже — рабочий сценарий для Ubuntu 22.04/24.04, Nginx 1.18 или новее и Certbot из Snap: на выходе сайт будет открываться по HTTPS, HTTP-запросы уйдут на защищённый адрес, а сертификат будет продлеваться автоматически.
Что проверяем до установки
Пример будет использовать домен example.com. Замените его на свой домен во всех командах и настройках. Нужен сервер с Ubuntu 22.04 или 24.04, установленный Nginx и учётная запись с правами sudo.
- DNS-запись
Aдомена указывает на публичный IPv4-адрес сервера. - Если у домена есть запись
AAAA, сервер действительно доступен по этому IPv6-адресу. Иначе проверка Let's Encrypt может уйти не туда. - Порты 80 и 443 разрешены в облачном firewall и локальном firewall сервера.
- Nginx уже обслуживает домен и отвечает на обычный HTTP-запрос.
- В конфигурации Nginx в директиве
server_nameуказаны нужные домены, напримерexample.com www.example.com.
Быстрая проверка с вашего компьютера: откройте http://example.com в браузере. Должна загрузиться именно ваш сайт, а не страница другого виртуального хоста. Если DNS только что менялся, дождитесь обновления записей: срок зависит от TTL и кешей провайдеров.
Сертификат не исправляет DNS и не открывает закрытый порт. Он только подтверждает домен и шифрует соединение, которое уже должно доходить до вашего Nginx.
Сноска. HTTP-01 challenge — проверка владения доменом через специальный файл, который Let's Encrypt запрашивает по обычному HTTP на порту 80. Поэтому для первого выпуска сертификата одного открытого порта 443 недостаточно.
Три способа выпустить сертификат
Для одного сайта на Nginx проще всего использовать плагин Certbot. Он сам добавит HTTPS-блок и может настроить перенаправление с HTTP. Если автоматическое изменение конфигурации нежелательно, сертификат выпускают отдельно через webroot. DNS-проверка нужна, когда сайт не должен быть доступен по HTTP или требуется wildcard-сертификат вроде *.example.com.
| Способ | Когда выбирать | Цена решения |
|---|---|---|
certbot --nginx | Обычный сайт или reverse proxy на Nginx | Минимум ручной работы, но Certbot меняет конфигурацию Nginx |
certbot certonly --webroot | Конфигурацию Nginx нужно контролировать вручную | После выпуска сертификата пути к файлам и HTTPS-блок настраиваются самостоятельно |
| DNS-проверка | Wildcard-сертификат или закрытый HTTP-порт | Нужно управлять DNS и автоматизировать обновление TXT-записей |
В живом примере используем первый вариант. Он подходит, если Nginx принимает запросы непосредственно на сервере и конфигурация сайта не собрана из нестандартных шаблонов.
Подключаем HTTPS через Certbot
1. Устанавливаем Certbot
Команды ниже рассчитаны на Ubuntu 22.04/24.04 с установленным Snap. Если команды snap на сервере нет, сначала установите пакет snapd из официальных репозиториев Ubuntu и повторите шаг.
sudo snap install certbot --classic
sudo ln -s /snap/bin/certbot /usr/bin/certbot
certbot --versionВ актуальной ветке Snap Certbot может иметь версию 2.x или 3.x в зависимости от даты установки. Важен сам результат последней команды: она должна вывести установленную версию, а не сообщение command not found. Команды ниже не зависят от конкретного минорного релиза.
2. Выпускаем сертификат и меняем конфигурацию Nginx
Укажите все имена, которые должны открываться по HTTPS. Certbot запросит адрес электронной почты для уведомлений, согласие с условиями и выбор перенаправления HTTP на HTTPS.
sudo certbot --nginx -d example.com -d www.example.comВыберите перенаправление HTTP на HTTPS, если сайт не должен работать в двух схемах одновременно. После успешного завершения Certbot сохранит сертификаты в каталоге /etc/letsencrypt/live/example.com/ и добавит SSL-настройки в конфигурацию Nginx.
Проверка результата:
sudo nginx -t
sudo systemctl reload nginx
curl -I http://example.com
curl -I https://example.comКоманда nginx -t должна сообщить, что синтаксис конфигурации корректен. HTTP-запрос обычно возвращает редирект с кодом 301 или 308, а HTTPS-запрос — ответ вашего приложения, например 200, 301 или 302. Код зависит от самого сайта, поэтому проверяйте не только статус, но и заголовок Location.
3. Проверяем, что сертификат выдан для нужных имён
sudo certbot certificatesВ выводе должны быть перечислены домены example.com и www.example.com, а также дата окончания действия сертификата. В браузере проверьте оба адреса: предупреждение о сертификате на одном имени часто означает, что это имя забыли добавить в команду -d.
Что делать, если очевидный сценарий не сработал
Ошибка проверки домена
Сообщение вроде Timeout during connect обычно означает, что Let's Encrypt не достучался до порта 80. Проверьте security group у облачного провайдера, правила ufw, внешний firewall и то, что Nginx слушает публичный адрес.
Домен ведёт не на тот сервер
Ошибки Invalid response и unauthorized возникают, когда DNS указывает на другой хост или запрос попадает в неправильный виртуальный сервер. Сверьте записи A и AAAA, затем проверьте ответ с нескольких сетей. Если IPv6 настроен частично, временно исправьте IPv6-маршрутизацию или удалите ошибочную запись AAAA.
Nginx не проходит проверку конфигурации
Если после запуска Certbot появляется nginx: [emerg] duplicate listen options или другая ошибка синтаксиса, не перезапускайте сервис вслепую. Выполните sudo nginx -t, найдите изменённый серверный блок в /etc/nginx/sites-enabled/ и сравните его с резервной копией. Certbot меняет конфигурацию, но не знает о нестандартной логике ваших шаблонов и include-файлов.
Сайт открывается, но браузер показывает смешанное содержимое
Предупреждение о mixed content означает, что HTML по HTTPS загружает изображения, стили или скрипты по HTTP. Сертификат здесь работает правильно: исправлять нужно абсолютные ссылки в приложении, шаблоне или настройках CMS. Начните с консоли браузера и списка заблокированных ресурсов.
Автоматическое продление и подводные камни
Let's Encrypt выдаёт сертификаты с ограниченным сроком действия, поэтому ручное продление каждые несколько недель — ненадёжный процесс. Установленный через Snap Certbot обычно получает обновления и запускает проверку продления через системный таймер. Наличие таймера не означает, что обновление действительно сработает для вашего домена.
sudo certbot renew --dry-run
systemctl list-timers | grep certbotПервая команда проводит тестовый сценарий продления без замены действующего сертификата. Она должна завершиться сообщением об успешной симуляции. Если тест не проходит, смотрите причину: закрытый порт 80, неправильный DNS, удалённый webroot или ошибки в конфигурации Nginx.
Не копируйте сертификаты из /etc/letsencrypt/live/ в приложение вручную. Эти файлы являются символическими ссылками на актуальные версии, а сервису после обновления может потребоваться reload. Для нестандартной схемы — например, когда TLS завершается в отдельном прокси — настройте deploy-hook по документации Certbot и отдельно протестируйте перезагрузку прокси.
Когда выбирать другой подход
certbot --nginx удобен для одного или нескольких обычных виртуальных хостов. Webroot лучше использовать в инфраструктуре, где конфигурация генерируется Ansible, Terraform или шаблонизатором: Certbot тогда только кладёт файл проверки и выпускает сертификат, не редактируя Nginx. DNS-проверка нужна для wildcard и для сервисов, которые принципиально не выставляют порт 80 в интернет.
Не смешивайте несколько клиентов ACME для одного домена без причины. Два независимых таймера могут одновременно запрашивать продление, упираться в ограничения центра сертификации и оставлять непонятные логи. Выберите один способ, запишите владельца конфигурации и проверьте его в тестовом окружении.
Что делать дальше
После выпуска сертификата проверьте HTTPS с внешней сети, редирект с HTTP, оба доменных имени и автоматическое продление через certbot renew --dry-run. Затем добавьте мониторинг срока действия сертификата и алерт заранее, а не в день отказа. Если сайт работает за CDN или балансировщиком, отдельно проверьте TLS на каждом участке цепочки: сертификат на Nginx не гарантирует корректную настройку внешнего прокси.
Источники: Certbot User Guide, Let's Encrypt: Challenge Types
Частые вопросы
Можно ли подключить Let's Encrypt, если сайт пока работает только по IP-адресу?
Что делать, если у меня другая версия Ubuntu или Nginx?
Почему сертификат выпустился для example.com, но не для www.example.com?
Что будет, если автоматическое продление не сработает?
Нужно ли открывать порт 80 после выпуска сертификата?
Можно ли использовать этот способ для wildcard-сертификата?
Материал носит информационный характер и подготовлен редакцией «Агентуры». Он не является офертой, рекламой или индивидуальной консультацией. Упомянутые продукты, компании и торговые знаки принадлежат их правообладателям. Перед принятием решений, влекущих юридические или финансовые последствия, обратитесь к профильному специалисту.