HTTPS без домена: сертификат Let’s Encrypt для IP-адреса VPS

MAATRIX · 17 октября 2026 · 8 мин чтения

Раньше просьба «сделайте нормальный HTTPS прямо на IP» часто заканчивалась покупкой домена или объяснением самоподписанного сертификата. В 2026 году у неё появился ещё один практический ответ. Let’s Encrypt выдаёт публично доверенные сертификаты для IP-адресов, и браузеру больше не обязательно показывать предупреждение только потому, что в строке адреса нет имени сайта.

Есть важное условие: такие сертификаты короткоживущие. Их срок — 160 часов, чуть больше шести суток. Поэтому настройка не заканчивается получением файлов. Нужно сразу проверить продление и загрузку нового сертификата веб-сервером. Иначе красивый зелёный старт продлится меньше отпуска администратора.

Где это удобно, а где домен всё же лучше

Сертификат на IP пригодится для временного стенда, технического интерфейса или сервиса, который действительно должен быть доступен по числовому адресу. Он подтверждает контролируемый адрес и позволяет установить защищённое TLS-соединение.

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

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

Общая доступность возможности объявлена 15 января 2026 года. Поддерживаются IPv4 и IPv6. Речь идёт о публичных адресах, контроль над которыми можно проверить, а не о частном адресе домашней сети вроде 192.168.1.10.

Что понадобится для практической настройки

Разберём один понятный вариант: отдельный VPS с Nginx и Certbot, проверка HTTP-01 через webroot. Сервер уже должен иметь публичный адрес, а входящий TCP-порт 80 — быть доступным для проверки. Для самого HTTPS потребуется порт 443.

Понадобится Certbot не ниже 5.4 для описанного сочетания IP и webroot. Версию проверяют командой certbot --version, а устанавливают поддерживаемым способом из инструкции проекта. Старый пакет дистрибутива может не знать нужные параметры, даже если команда называется точно так же.

Механизм описан в официальном руководстве Let’s Encrypt для Certbot. В этой статье используется получение через certonly и явная настройка Nginx. Возможности автоматических установщиков меняются; не рассчитывайте, что плагин сам настроит весь сайт без проверки.

Для небольшого стенда подходит, например, MAATRIX Ba Lite с 1 vCPU и 2 GB памяти. Ресурсы рабочего приложения рассчитываются отдельно. Ubuntu или Debian должны поддерживать выбранный способ установки актуального Certbot. Смена размера VPS сама по себе не решает проблему недоступного порта.

Сначала докажите доступность проверочного каталога

Создайте отдельный каталог webroot и настройте HTTP-сервер так, чтобы файлы из .well-known/acme-challenge отдавались напрямую. Ниже фрагмент для нового учебного виртуального хоста. Адрес 203.0.113.10 зарезервирован для примеров: в рабочей настройке вместо него нужен ваш публичный IP.

server {
    listen 80;
    server_name 203.0.113.10;
    root /var/www/ip-site;

    location ^~ /.well-known/acme-challenge/ {
        try_files $uri =404;
    }

    location / {
        return 200 "IP HTTPS test\n";
    }
}

Не добавляйте этот блок вслепую в занятую конфигурацию. Если Nginx уже обслуживает сайты, определите, какой server block принимает запросы к IP, и устраните конфликт. Создайте каталог с правами, позволяющими веб-серверу читать проверочные файлы, затем проверьте конфигурацию через nginx -t и примените её штатным reload.

Положите в проверочный каталог безобидный файл probe и откройте http://ВАШ_IP/.well-known/acme-challenge/probe из внешней сети. Ответ должен содержать именно его текст, без страницы входа, редиректа на недоступный домен или ошибки приложения. После проверки файл удалите.

HTTP-01 требует доступности порта 80 со стороны центра сертификации. Изменение локального порта Certbot не меняет этот внешний адрес проверки. Особенности способов подтверждения перечислены в описании challenge types. Для IP не нужно пытаться создать TXT-запись в обратной DNS-зоне вместо выбранного HTTP-пути.

Выпуск сначала проверяется без доверенного сертификата

Выполните пробную выдачу. Замените адрес примера и путь, если выбрали другой каталог. --dry-run обращается к тестовой среде и не сохраняет тестовый сертификат как рабочий:

sudo certbot certonly --dry-run \
  --preferred-profile shortlived \
  --webroot --webroot-path /var/www/ip-site \
  --cert-name vps-ip \
  --ip-address 203.0.113.10

При первой настройке следуйте запросам регистрации и условиям сервиса. Ошибку нужно устранить до повторного запроса в производственную среду. Многократные попытки наугад только усложняют диагностику и способны упереться в ограничения выдачи.

Если проверка прошла, повторите команду без --dry-run. Сохраните показанные пути, а затем просмотрите certbot certificates. В нашем примере имя линии сертификата задано явно: vps-ip. Поэтому конфигурация не зависит от того, как файловая система представляет двоеточия в IPv6-адресе.

Проверьте, что выпущенный сертификат содержит нужный IP в Subject Alternative Name и ожидаемые даты действия. Сертификат для домена не начинает подходить IP только потому, что домен указывает на ту же машину. Клиент проверяет идентификатор, к которому он обратился.

Подключаем сертификат к Nginx

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

server {
    listen 443 ssl;
    server_name 203.0.113.10;

    ssl_certificate /etc/letsencrypt/live/vps-ip/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/vps-ip/privkey.pem;

    location / {
        return 200 "IP HTTPS test\n";
    }
}

Это минимальный стенд, к которому затем подключается приложение. Для рабочей конфигурации учитывайте рекомендации по TLS и параметры вашего сервиса. Назначение файлов и директив описано в документации HTTPS Nginx.

Выполните проверку конфигурации и reload, откройте https://ВАШ_IP с другого устройства. Предупреждения о доверии или несовпадении адреса нельзя обходить кнопкой браузера и считать настройку завершённой. Найдите причину: тестовый сертификат, другой виртуальный хост, неполная цепочка или неверный адрес.

Для IPv6 в адресной строке используются квадратные скобки. Также нужен соответствующий listener и доступность сети IPv6. Если сертификат выпущен только для IPv4, это не покрывает IPv6-адрес той же машины автоматически.

Продление и перечитывание — две разные операции

Certbot может успешно обновить файлы, пока Nginx продолжает отдавать прежний сертификат из памяти. Поэтому предусмотрите deploy hook, который после успешного выпуска проверяет конфигурацию и выполняет reload.

На обычном сервере с Nginx под systemd можно сохранить такой исполняемый скрипт в каталоге deploy hooks Certbot:

#!/bin/sh
set -eu
/usr/sbin/nginx -t
/bin/systemctl reload nginx

Для стандартного каталога Certbot файл можно разместить как /etc/letsencrypt/renewal-hooks/deploy/reload-nginx. После сохранения назначьте ему право исполнения для администратора и проверьте владельца. Каталог hooks не должен быть доступен для записи посторонним пользователям.

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

Проверьте автоматический запуск renew: таймер, расписание и журнал последнего выполнения. Не создавайте второй конкурирующий планировщик, если установка уже настроила первый. Для проверки выполните certbot renew --cert-name vps-ip --dry-run; отдельно испытайте hook в согласованное время. Подробности --run-deploy-hooks и поведения пробного запуска есть в руководстве Certbot.

Шестидневному сертификату не подходит ручное напоминание раз в месяц. Клиент должен регулярно проверять необходимость обновления, а мониторинг — следить за фактически выдаваемым сертификатом снаружи. Успешный код завершения команды не всегда означает, что сертификат сегодня менялся.

Три неисправности, которые выглядят одинаково в браузере

Первая ситуация: сертификат есть, но выдаётся другой. На одном IP несколько HTTPS-блоков, а клиент при обращении к числовому адресу не обязан отправлять доменное SNI. Поэтому для описанного отдельного стенда блок с IP-сертификатом должен обслуживать соединение по умолчанию на нужном адресе и порту. На занятом сервере определите этот выбор явно, например через подходящий default_server, предварительно устранив конфликт с существующим значением. Одного server_name с IP недостаточно для всех вариантов TLS-подключения.

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

Третья ситуация: первая выдача прошла, а продление перестало работать. Сравните маршрут HTTP-проверки с первоначальным: не появился ли общий редирект, пароль на весь сайт или новое правило firewall. Проверьте именно внешний запрос, поскольку локальное обращение обходит часть сетевых ограничений.

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

Когда настройку можно считать законченной

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

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

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

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