SiteGuard4 ноября 202617 мин чтения

Бесплатный SSL-сертификат: как получить и подключить Let’s Encrypt

Бесплатный SSL-сертификат для сайта можно получить через Let’s Encrypt: включить выпуск в панели поддерживающего хостинга или установить ACME-клиент на свой сервер. Затем сертификат нужно подключить к точке, которая принимает HTTPS-соединения, и проверить результат снаружи. Для обычного сайта достаточно подтвердить управление нужными именами домена; покупать сертификат только ради включения HTTPS необязательно.

Разберём подготовку DNS, первый выпуск, установку и проверку HTTPS на хостинге и VPS с Nginx. Домены example.com и www.example.com в командах — учебные: замените их своими именами. Перенос адресов, редиректы всего сайта и дальнейшее обслуживание требуют отдельной настройки.

Что вы получаете бесплатно вместе с Let’s Encrypt

Let’s Encrypt — центр сертификации, который бесплатно выпускает сертификаты через протокол ACME. Запрос отправляет программа: встроенная интеграция хостинга либо ACME-клиент администратора. На самом сайте Let’s Encrypt нет формы, куда достаточно вписать домен и скачать готовый комплект. В официальном руководстве по началу работы предлагается сначала выяснить, возьмёт ли управление сертификатом на себя провайдер.

Бесплатен выпуск сертификата. Домен, сервер и работа администратора оплачиваются по своим условиям. Если провайдер берёт плату за «подключение SSL», уточните состав услуги: счёт может относиться к настройке и сопровождению.

Привычное название «SSL-сертификат» сохраняется, хотя современные HTTPS-соединения используют TLS. Сертификат помогает проверить сервер, с которым устанавливается защищённое соединение. Исправление уязвимостей CMS и резервное копирование остаются самостоятельными задачами.

Ситуация	Подходящий маршрут	Что выяснить заранее
Сайт на обычном хостинге с интеграцией Let’s Encrypt	Панель провайдера	Поддерживаемые имена, способ проверки домена, автоматическое продление
Собственный VPS с Nginx и доступом администратора	Certbot и плагин Nginx	DNS, доступность HTTP, корректность конфигурации и резервная копия
Нужен сертификат для группы поддоменов вида *.example.com	DNS-01 с подходящим клиентом	Возможность автоматически менять TXT-записи через API DNS-провайдера
HTTPS принимает CDN или балансировщик	Управление на соответствующей точке TLS	Кто выпускает сертификат для посетителя и как защищено соединение с сервером

Выберите одного ответственного за сертификаты. Если ими управляет хостинг, отдельная установка Certbot обычно не нужна.

Что подготовить перед выпуском бесплатного SSL-сертификата

Составьте точный список доменных имён

example.com и www.example.com — разные имена. Если посетители используют оба, запрашивайте сертификат для обоих и обеспечьте проверку каждого. Добавляйте shop.example.com или api.example.com только тогда, когда они действительно нужны в этом сертификате и вы управляете их настройками. Длинный список «на всякий случай» увеличивает число зависимостей при выпуске.

Для перенаправления с https://www.example.com на домен без www тоже нужен подходящий сертификат: TLS-соединение устанавливается до получения HTTP-редиректа. Включите в проверку адреса из рекламы и писем, даже если они не являются основными.

Проверьте публичный DNS, включая IPv6

В сценарии HTTP-01 запрос по домену должен попадать на нужный Nginx. Проверьте A и AAAA каждого имени, а при CNAME — конечную цель. Локальный файл hosts не меняет публичный DNS для Let’s Encrypt.

dig +short A example.com
dig +short AAAA example.com
dig +short A www.example.com
dig +short AAAA www.example.com

Сопоставьте ответы dig с адресами хостинга. Каждый опубликованный маршрут должен обслуживать проверку. При наличии AAAA проверьте IPv6: Let’s Encrypt предпочитает его для первой попытки, а переход на IPv4 предусмотрен не для любых ошибок. Подробнее — в документации по IPv6.

После изменения DNS учитывайте кеширование и TTL: разные резолверы могут возвращать старые ответы. Проверьте записи из внешней сети, при расхождении — авторитетные DNS-серверы. Исправляйте неработающий IPv6 или устаревшую запись после уточнения её назначения.

Убедитесь, что проверка домена попадёт на правильный сервер

HTTP-01 подтверждает управление доменом запросом к адресу вида http://example.com/.well-known/acme-challenge/ТОКЕН. Проверка начинается через публичный TCP-порт 80; перенести её на произвольный внешний порт нельзя. Нужный ответ создаёт ACME-клиент. При нескольких веб-серверах он должен быть доступен на всех возможных маршрутах. Эти условия приведены в описании методов проверки Let’s Encrypt.

Открывающаяся главная страница ещё не подтверждает доступность challenge-пути. Его могут отдельно блокировать авторизация, CMS, кеш, WAF или прокси. Во время проверки клиент должен отдать именно выданное ему содержимое.

Для HTTPS понадобится и TCP-порт 443. Проверяйте правила как на VPS, так и в сетевом экране облачного провайдера. Если порт 80 нельзя открыть по условиям инфраструктуры, заранее выбирайте другой поддерживаемый способ подтверждения, например DNS-01. Let’s Encrypt отдельно объясняет роль порта 80; отключение сетевой защиты целиком для выпуска не требуется.

Способ 1. Получить SSL бесплатно через панель хостинга

В панели поддерживающего хостинга техническую работу выполняет интеграция. Названия разделов и порядок действий различаются: используйте инструкцию своего провайдера. Наличие панели само по себе не гарантирует поддержку бесплатного SSL.

Выберите нужный сайт. Сверьте домен, аккаунт и окружение, чтобы не подключить сертификат только к тестовой копии.
Уточните поддержку Let’s Encrypt. Проверьте условия тарифа и допустимые имена. Если интеграции нет, узнайте способ подключения собственного сертификата.
Укажите нужные имена. Добавьте основной домен и www, если он используется. Проверьте автоматически включённые почтовые и технические поддомены: они могут иметь другой DNS.
Подготовьте проверку и запустите выпуск. Следуйте требованиям провайдера к DNS или TXT. Не меняйте DNS-серверы по чужому примеру без учёта почты и других сервисов домена.
Проверьте назначение сертификата. Если установка отделена от выпуска, выберите полученный сертификат для нужного сайта по инструкции панели.
Проверьте HTTPS снаружи. Откройте каждое имя и посмотрите предъявленный сертификат. Выясните, выполняет ли хостинг продление автоматически и где отображаются ошибки.

При обращении в поддержку укажите домен, время попытки, текст ошибки и ответы DNS. Это помогает отличить неполадку интеграции от неверного адреса одного из поддоменов.

При ручной загрузке файлов выясните, кто будет обновлять их после следующего выпуска. Бесплатный SSL-сертификат для домена полезнее подключать с понятным процессом сопровождения и назначенным ответственным.

Способ 2. Установить Let’s Encrypt на VPS с Nginx и Certbot

Условия, для которых подходит этот пример

Ниже используется Ubuntu 24.04 LTS, Nginx и Certbot из snap. Ubuntu 24.04 находится в периоде стандартной поддержки, что можно проверить в таблице жизненного цикла Ubuntu. Это пример первичной установки на сервере без другой действующей установки Certbot. Он не предназначен для контейнерного Nginx, Kubernetes, нескольких балансировщиков или сервера, конфигурацию которого автоматически перезаписывает панель.

Есть SSH-доступ и права sudo, Nginx уже обслуживает нужный сайт по HTTP.
На сервере установлен и работает snapd, а использование snap разрешено вашей политикой администрирования.
Имена домена ведут непосредственно на этот VPS, HTTP доступен извне по порту 80, HTTPS разрешён по порту 443.
Сохранена резервная копия конфигурации Nginx, понятен порядок её восстановления.
Во время изменений другой администратор или система развёртывания не перезаписывает те же конфигурационные файлы.

Официальная инструкция Certbot для Nginx и snap рекомендует этот способ установки большинству пользователей. Если snapd отсутствует, сначала установите его по инструкции для своей ОС, указанной на этой странице. Не соединяйте в одну последовательность команды установки Certbot через snap, системный пакетный менеджер и Python: здесь выбран один способ.

Шаг 1. Проверьте конфигурацию до изменений

У виртуального сервера Nginx должны быть правильные имена в server_name. Для двух адресов фрагмент существующего блока выглядит так:

server_name example.com www.example.com;

Это директива внутри существующего блока server. Сохраните настройки приложения и проксирования. Если открывается другой сайт или стартовая страница Nginx, сначала исправьте выбор виртуального сервера.

sudo nginx -t
snap version

nginx -t проверяет синтаксис и возможность открыть указанные файлы — см. параметры Nginx. Исправьте обнаруженные ошибки до запуска Certbot.

Шаг 2. Установите Certbot из snap

sudo snap install --classic certbot
sudo /snap/bin/certbot --version

В командах далее используется полный путь /snap/bin/certbot, чтобы явно запускать выбранную установку. Создавать дополнительную символическую ссылку для этого примера не требуется. Способ через snap также показан в руководстве Ubuntu по получению TLS-сертификатов.

Если Certbot уже обслуживает другие домены, сначала определите порядок перехода по официальной инструкции: удаление существующих пакетов без проверки может нарушить их обслуживание.

Шаг 3. Запросите сертификат и подключите его к Nginx

Для сайта с основным доменом и www выполните команду после замены обоих учебных имён:

sudo /snap/bin/certbot --nginx --no-redirect -d example.com -d www.example.com

Плагин проверит домены и установит сертификат в Nginx. Параметры -d задают имена; несуществующий и ненужный www не включайте. Пройдите интерактивные шаги, включая принятие условий, и сохраните сведения о результате.

С --no-redirect Certbot не добавляет автоматическое перенаправление HTTP на HTTPS, а защищённая версия включается — см. справочник Certbot. После проверки отдельно настройте основной HTTPS-адрес, ссылки и редиректы.

Дождитесь сообщения об успешной установке. При неудаче исправьте причину ошибки конкретного имени перед повтором: на операции выпуска действуют ограничения частоты.

Шаг 4. Проверьте конфигурацию и установленный сертификат

sudo nginx -t
sudo /snap/bin/certbot certificates

В выводе Certbot сверьте имена, срок действия, название сертификата и пути к файлам. Имя каталога может отличаться от домена, например иметь дополнительный суффикс: используйте фактические пути из результата. Успешный вывод этой команды подтверждает наличие сертификата в управлении Certbot, но ещё не доказывает, что нужный экземпляр отдаётся посетителю.

Плагин при успешной установке применяет изменения Nginx. Если после этого вы вручную меняли настройки и nginx -t прошёл, примените их штатной перезагрузкой конфигурации:

sudo nginx -s reload

Reload выполняйте только после успешного теста. Для установки выберите подходящее время: плагин меняет действующую конфигурацию веб-сервера. Затем переходите к внешней проверке.

Как связаны сертификат, закрытый ключ и цепочка доверия

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

Файл Certbot	Содержимое	Практическое назначение
`cert.pem`	Сертификат самого сайта	Публичные данные о сертификате без полного набора промежуточных сертификатов
`chain.pem`	Промежуточная цепочка	Дополняет сертификат сервера при построении доверия
`fullchain.pem`	Сертификат сайта, затем промежуточные сертификаты	Обычно указывается в директиве `ssl_certificate` Nginx
`privkey.pem`	Закрытый ключ	Указывается в `ssl_certificate_key`; не публикуется и не передаётся посторонним

Назначение файлов и их расположение описаны в руководстве Certbot. Для полученного сертификата конфигурация может содержать следующие строки; это пример с условным именем каталога:

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

После автоматической установки не добавляйте строки вторично. Сверьте фактические пути: дальнейшее обновление должно попадать именно в используемый сервером комплект.

Порядок сертификатов в цепочке и соответствие ключа сертификату имеют значение; документация Nginx по HTTPS разбирает такие ошибки. Закрытый ключ нельзя загружать в сторонний «проверяльщик SSL» или отправлять в обычной переписке. Для первичной диагностики поддержки достаточно домена, текста ошибки и публичных сведений о сертификате.

Когда вместо HTTP-01 нужен DNS-01

DNS-01 подтверждает управление именем через специальную TXT-запись, например под _acme-challenge.example.com. Этот путь подходит, когда проверка по HTTP неудобна, а также нужен для wildcard-сертификатов Let’s Encrypt вида *.example.com. HTTP-01 wildcard не выпускает. Выбор и различия методов описаны в официальной документации.

Для автоматизации нужны DNS API и подходящий плагин. Он создаёт актуальное TXT-значение и дожидается публикации; одна запись не заменяет последующие проверки. Ограничьте права API-токена необходимой зоной и операциями, если провайдер это поддерживает.

Ручное добавление TXT само по себе не даёт автоматического продления: Certbot требует для этого автоматизирующие hooks. Для рабочего сайта выберите поддерживаемую интеграцию и следуйте инструкции для своего DNS-провайдера. Универсальной команды для всех провайдеров нет.

Wildcard тоже имеет границы: *.example.com подходит для имени shop.example.com, но не заменяет отдельное имя example.com и не покрывает произвольную глубину поддоменов. Если нужны корневой домен и wildcard, их указывают в запросе отдельно. Для небольшого сайта с двумя известными именами обычный сертификат часто проще в эксплуатации, потому что не требует отдельного доступа к DNS API.

CDN и reverse proxy: где на самом деле устанавливать сертификат

Если перед сервером стоит CDN или обратный прокси с завершением TLS, возникают два самостоятельных соединения: посетитель — внешняя точка и внешняя точка — исходный сервер, который называют origin. Браузер видит сертификат первой точки. Установка Let’s Encrypt только на VPS не заменит сертификат CDN, а рабочий сертификат CDN не подтверждает состояние origin.

Выясните, кто принимает HTTPS: CDN, балансировщик или конечный сервер. При передаче TLS без завершения сертификат остаётся на конечном сервере. Если узлов несколько, предусмотрите установку и проверку на каждом.

Полезный пример разделения — режим Full (strict) в Cloudflare: для соединения с origin требуется действующий сертификат с подходящим именем и поддержкой HTTPS на сервере. Это отдельная проверка от соединения браузера с CDN. У другого поставщика названия режимов и требования могут отличаться, поэтому выбирайте настройки по его документации.

Проксирование также влияет на HTTP-01: запрос к challenge-пути должен попасть туда, где клиент подготовил ответ. Постоянный challenge в браузере, перенаправление в личный кабинет или закешированная ошибка мешают выпуску. Настройте маршрут для ACME в предусмотренных провайдером границах либо используйте DNS-01. Не отключайте CDN и защитные правила целиком как обязательный шаг универсальной инструкции.

Как проверить, что бесплатный SSL действительно работает

Посмотрите сайт глазами внешнего посетителя

Откройте https://example.com/ и https://www.example.com/ с компьютера или телефона во внешней сети. Убедитесь, что отображается нужный сайт. В сведениях о соединении откройте сертификат и проверьте имя, срок действия и отсутствие ошибки доверия. Ориентируйтесь на информацию браузера, поскольку вид значка около адреса меняется между версиями и браузерами.

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

Проверьте соединение командой curl

В Windows PowerShell 5.1 во всех командах этого раздела вызывайте curl.exe вместо curl: иначе может запускаться псевдоним Invoke-WebRequest с другим набором параметров. Это различие описано в справке Microsoft.

curl -I https://example.com/
curl -I https://www.example.com/

curl по умолчанию проверяет сертификат и соответствие имени сервера; это описано в руководстве curl по TLS-проверке. В результате не должно быть сообщения об ошибке проверки сертификата. При этом HTTP-статус оценивают отдельно: например, ответ 403 может означать ограничение доступа, а не неудачное TLS-соединение. Если приложение не поддерживает HEAD-запросы, проверьте обычную загрузку в браузере.

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

curl -4 -I https://example.com/
curl -6 -I https://example.com/

Повторите тест для www. Проверяющий компьютер должен иметь нужный IPv4- или IPv6-маршрут; иначе ошибка подключения сама по себе не доказывает проблему сайта.

При необходимости проверьте origin отдельно от CDN

Если по архитектуре разрешено прямое обращение к origin, параметр --resolve позволяет подключиться к заданному адресу, сохранив доменное имя для HTTPS-проверки. В примере 192.0.2.10 — документационный адрес: замените его фактическим адресом своего origin.

Выполняйте эту проверку из разрешённой сети при прямом подключении без настроенного HTTP(S)-прокси: прокси может изменить маршрут запроса.

curl --resolve example.com:443:192.0.2.10 -I https://example.com/

Назначение параметра приведено в справочнике curl. Команда проверяет конкретный узел, а обычный запрос к домену — публичный маршрут. Если origin закрыт для внешних подключений, проверяйте его из разрешённой административной сети. Если он использует внутренний или предназначенный только для CDN центр сертификации, обычное хранилище доверия браузера может не подходить: способ проверки выбирают по архитектуре, сохраняя проверку доверия.

Почему Let’s Encrypt не выпускает сертификат или HTTPS выдаёт ошибку

Ошибка подтверждения домена требует проверки DNS и challenge-маршрута. Если сертификат выпущен, но браузер его не видит, проверяйте установку и точку завершения TLS.

Признак	Вероятное направление проверки	Что сделать
Имя не разрешается или возвращается NXDOMAIN	Публичный DNS и делегирование	Проверить существование имени, записи зоны и авторитетные DNS-серверы
Тайм-аут HTTP-01	Адрес, порт 80, firewall, IPv6	Проверить внешний доступ к каждому опубликованному маршруту и сетевые правила провайдера
Проверка получает 404, 403 или страницу приложения	Challenge-путь обслуживает неверный обработчик	Проверить виртуальный сервер, авторизацию, WAF, кеш и проксирование именно этого пути
Основной домен проходит, www не проходит	У имён разные DNS или конфигурации	Сравнить записи и обслуживание каждого имени из запроса
Ошибка CAA или SERVFAIL	Политика выдачи либо неисправность DNS	Проверить CAA, DNSSEC и ответы авторитетных серверов
Браузер получает сертификат другого сайта	Выбран другой виртуальный сервер или узел	Сверить имя, DNS, настройки HTTPS, CDN и результат применения конфигурации
Ошибка доверия при правильном имени	Неполная цепочка, тестовый сертификат или локальное доверие	Проверить используемый fullchain, источник выпуска и результат из другого актуального клиента

CAA и DNSSEC решают разные задачи

Записи CAA задают, каким центрам разрешено выпускать сертификаты для домена. Если у домена уже есть ограничения, проверьте разрешение для letsencrypt.org, включая применимые настройки родительских имён и wildcard. Добавлять CAA обязательно для любого первого выпуска не требуется. Разрешение нужного центра нужно согласовать с существующей политикой, а не удалять все записи ради успешной попытки.

Ошибка SERVFAIL при запросе CAA может быть вызвана DNSSEC или недоступностью авторитетного DNS, а не отсутствием разрешения в записи. Проверяйте подписи и делегирование совместно с DNS-провайдером. Let’s Encrypt разбирает эти случаи в руководстве по CAA. Отключать DNSSEC как стандартный способ устранения ошибки не нужно.

Лимиты выпуска: сначала исправление, затем повтор

Let’s Encrypt ограничивает частоту запросов и отдельных операций. При ошибке лимита ориентируйтесь на её тип и указанное время следующей попытки; актуальные условия опубликованы в документации Rate Limits. Простое удаление локальных файлов или повторное создание аккаунта не является корректным способом устранения причины.

Для отладки сложной первой настройки предусмотрена тестовая среда staging. Она выдаёт тестовые сертификаты, которые не подходят для обычных посетителей. Используйте её по официальной инструкции, а после проверки выполните рабочий выпуск. Не назначайте тестовый сертификат публичному сайту в качестве готового результата.

Первая установка завершена: проверьте, что предусмотрено продление

Для управляемого хостинга достаточно выяснить, кто выполняет продление и где видны ошибки. На VPS с выбранной установкой Certbot проверьте наличие штатного задания и выполните тест продления:

systemctl list-timers --all
sudo /snap/bin/certbot renew --dry-run

Найдите задание Certbot среди таймеров; сам факт запуска команды просмотра не подтверждает его наличие и работоспособность. В стандартной конфигурации --dry-run использует staging и не сохраняет тестовый сертификат как рабочий. Однако проверка может временно менять конфигурацию, выполнять предусмотренные hooks и перезагружать веб-сервер. Запускайте её в подходящее время и прочитайте итоговый результат. Это проверка возможности продления, а не полноценный регламент обслуживания.

Не стройте процесс вокруг универсального срока «90 дней». По состоянию на 31 октября 2026 года Let’s Encrypt уже объявил переход стандартного срока на 64 дня с 10 февраля 2027 года; существуют и более короткие профили. Для установленного сертификата проверяйте фактическую дату окончания. Письма о скором истечении от Let’s Encrypt также не являются страховкой: этот сервис прекратился 4 июня 2025 года.

После подключения полезно включить внешний контроль доступности и сертификата, определить получателя уведомлений и сохранить краткую запись о настройке. Если вы выбираете подход к регулярной проверке сайта, познакомьтесь с SiteGuard и сопоставьте его возможности со своими задачами. Успешная установка сегодня должна оставаться проверяемым результатом после изменений DNS, сервера и инфраструктуры.

Частые вопросы о бесплатном SSL-сертификате

Можно ли получить SSL бесплатно без доступа по SSH?

Да, если выпуск и подключение поддерживает ваш хостинг или платформа. Используйте их панель и инструкцию. Если такой возможности нет, а вам разрешена только загрузка файлов сайта, сначала уточните у провайдера способ установки сертификата: наличие файлов само по себе не даёт доступа к HTTPS-конфигурации сервера.

Можно ли установить сертификат до переноса сайта на новый VPS?

Да, но способ подтверждения должен соответствовать текущему DNS и маршрутизации. Команда HTTP-01 из примера ожидает, что проверка придёт на этот VPS. Если публичный домен пока ведёт на старую площадку, заранее организуйте поддерживаемый маршрут проверки или выберите DNS-01 с доступом к зоне. Локальная подмена адреса на компьютере администратора этого не заменяет.

Подойдёт ли сертификат для IP-адреса вместо домена?

Let’s Encrypt поддерживает сертификаты для IPv4 и IPv6: их общедоступный выпуск объявлен в январе 2026 года. Для них используется короткий срок — 160 часов. Это отдельный сценарий с поддерживающим клиентом и надёжной автоматизацией; приведённые команды предназначены для доменных имён. Сертификат домена не становится сертификатом IP только потому, что домен на этот адрес указывает.

Чек-лист: сертификат получен и подключён правильно

В сертификате есть все нужные имена, включая www, если оно используется.
Публичные записи A и AAAA ведут к предусмотренной инфраструктуре.
Сертификат подключён именно к точке завершения TLS: Nginx, балансировщику или CDN.
Веб-сервер использует соответствующий закрытый ключ и полную промежуточную цепочку.
Конфигурация прошла проверку и успешно применена.
Внешний клиент открывает каждый нужный HTTPS-адрес без ошибки сертификата.
Основные пользовательские действия работают на защищённой версии сайта.
Понятно, кто выполняет последующее продление и как будет обнаружена ошибка.

Сохраните имена, способ проверки, место установки и ответственного в документации проекта. Эта запись поможет при смене хостинга или администратора.

Основные официальные материалы

Let’s Encrypt: начало работы — выбор между хостингом и собственным ACME-клиентом.
Certbot: Nginx и snap — актуальные шаги установки.
Let’s Encrypt: методы подтверждения — HTTP-01 и DNS-01.
Nginx: настройка HTTPS — сертификат, ключ и цепочка.