С 15 января 2026 года Let’s Encrypt выдаёт общедоступные TLS-сертификаты непосредственно на IP-адреса. Доменное имя больше не обязательно, поэтому адрес вида https://публичный_IP может открываться без предупреждения о недоверенном сертификате. Поддерживаются как IPv4, так и IPv6.
IP записывается в расширение Subject Alternative Name сертификата как iPAddress. Такой формат предусмотрен требованиями CA/Browser Forum. Браузер сравнивает адрес, к которому подключился пользователь, с IP в SAN. Записывать IP как обычное доменное имя в dNSName не нужно.
У сертификатов Let’s Encrypt на IP есть существенное отличие от обычных сертификатов на домены. Для них требуется профиль shortlived, а срок действия составляет 160 часов, то есть 6 дней 16 часов. Поэтому ставить такой сертификат вручную и вспоминать о продлении раз в несколько месяцев не получится. Автоматическое продление нужно настроить сразу.
Сертификат Let’s Encrypt можно получить только на публичный IP. Адреса10.0.0.0/8,172.16.0.0/12,192.168.0.0/16и другие зарезервированные диапазоны не подходят для публично доверенного сертификата. Правила CA/Browser Forum прямо запрещают центрам сертификации выдавать такие сертификаты. Для внутренней сети нужен собственный центр сертификации либо самоподписанный сертификат.
Как получить сертификат Let’s Encrypt на IPv4 или IPv6 через Certbot
Для IP-сертификатов нужен современный Certbot. Ключ --ip-address появился в Certbot 5.3, а поддержка IP в режиме webroot появилась в версии 5.4. Поэтому для инструкции ниже используйте Certbot 5.4 или новее. Текущая документация разрешает указывать несколько --ip-address, чтобы включить несколько IPv4 или IPv6 в один сертификат.
Сначала проверьте версию:
certbot --version
Для проверки через HTTP-01 сервер должен быть доступен из интернета по тому самому IP, который попадёт в сертификат, а TCP-порт 80 должен принимать входящие подключения. Let’s Encrypt обращается к http://IP/.well-known/acme-challenge/... и проверяет временный файл. DNS для такой проверки не нужен. HTTP-01 работает и с IP-адресами, тогда как DNS-01 для проверки IP не применяется. Альтернативой служит TLS-ALPN-01 на порту 443, но поддержка такого способа зависит от клиента ACME.
Если Nginx, Apache или другой веб-сервер уже работает, удобнее использовать webroot. Последовательность выглядит так: публичный IP закреплён за сервером → порт 80 открыт → каталог сайта доступен по HTTP → Certbot создаёт проверочный файл → Let’s Encrypt проверяет IP → Certbot сохраняет сертификат.
Сначала запустите запрос через тестовую среду Let’s Encrypt, подставив реальный IP и каталог сайта:
sudo certbot certonly --staging --preferred-profile shortlived --webroot --webroot-path /var/www/html --ip-address <PUBLIC_IPV4> --cert-name ip-cert
Тестовый сертификат не считается публично доверенным. Если проверка прошла, повторите команду без --staging:
sudo certbot certonly --preferred-profile shortlived --webroot --webroot-path /var/www/html --ip-address <PUBLIC_IPV4> --cert-name ip-cert
Для IPv6 команда выглядит так же. В --ip-address передаётся сам адрес без квадратных скобок:
sudo certbot certonly --preferred-profile shortlived --webroot --webroot-path /var/www/html --ip-address <PUBLIC_IPV6> --cert-name ip-certЕсли сервер одновременно доступен по IPv4 и IPv6, оба адреса можно записать в один сертификат:
sudo certbot certonly --preferred-profile shortlived --webroot --webroot-path /var/www/html --ip-address <PUBLIC_IPV4> --ip-address <PUBLIC_IPV6> --cert-name ip-certLet’s Encrypt должен успешно проверить каждый указанный адрес. Если IPv4 работает, а IPv6 ведёт на другой сервер или закрыт межсетевым экраном, выпуск сертификата с обоими адресами завершится ошибкой.
Когда веб-сервер ещё не запущен, можно использовать --standalone. Certbot сам временно откроет HTTP-сервер для проверки. Порт 80 при этом должен быть свободен и доступен из интернета:
sudo certbot certonly --preferred-profile shortlived --standalone --ip-address <PUBLIC_IP> --cert-name ip-certКак подключить IP-сертификат в Nginx или Apache и настроить продление
Получить сертификат и автоматически установить его в веб-сервер пока не одно и то же. Certbot пока умеет получать IP-сертификаты, но не устанавливать их в Nginx или Apache. Плагины nginx и apache не поддерживают IP-адреса. Поэтому сертификат получают через webroot, standalone или manual, а пути к файлам прописывают в конфигурации веб-сервера вручную.
При использовании --cert-name ip-cert Certbot хранит актуальные файлы по стабильным путям /etc/letsencrypt/live/ip-cert/fullchain.pem и /etc/letsencrypt/live/ip-cert/privkey.pem. Для Nginx достаточно указать их в нужном серверном блоке:
server { listen 443 ssl; listen [::]:443 ssl; ssl_certificate /etc/letsencrypt/live/ip-cert/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/ip-cert/privkey.pem; location / { root /var/www/html; } }После правки проверьте конфигурацию и перечитайте её:
sudo nginx -t sudo systemctl reload nginxДля Apache используются те же файлы:
<VirtualHost *:443> SSLEngine on SSLCertificateFile /etc/letsencrypt/live/ip-cert/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/ip-cert/privkey.pem </VirtualHost>
После продления веб-сервер должен перечитать новый сертификат. Поскольку веб-серверные плагины Certbot пока не поддерживают IP-сертификаты, для этого нужно настроить --deploy-hook. Хук запускается после успешного продления и сообщает Nginx или Apache, что нужно загрузить актуальные файлы с диска. Для Nginx можно использовать:
sudo certbot reconfigure --cert-name ip-cert --deploy-hook "systemctl reload nginx"
Для Apache вместо команды перезагрузки Nginx укажите systemctl reload apache2 или соответствующую команду вашего дистрибутива. Let’s Encrypt рекомендует использовать --deploy-hook именно потому, что автоматические установщики веб-серверов пока не работают с IP-сертификатами.
Проверьте, установлен ли системный таймер Certbot:
systemctl list-timers | grep certbotЗатем протестируйте продление:
sudo certbot renew --dry-run
Из-за срока в 160 часов задача certbot renew должна запускаться регулярно, а не раз в неделю. Стандартные установки Certbot обычно создают системный таймер или cron-задачу автоматически. После успешного продления --deploy-hook заставит сервер перечитать сертификат, иначе на диске появятся новые файлы, а Nginx или Apache продолжит отдавать старую копию.
Когда сертификат на IP не сработает
Частный адрес из RFC 1918 получить публичный сертификат не может. Проблема касается и диапазона 100.64.0.0/10, который выделен для CGNAT. При CGNAT внешний IPv4 принадлежит инфраструктуре провайдера, а входящее соединение обычно нельзя направить на свой сервер. Поэтому Let’s Encrypt не сможет проверить контроль над адресом обычным HTTP-01.
Динамический публичный IP технически можно сертифицировать, но практического смысла обычно мало. Сертификат привязан к точному адресу. После смены IPv4 старый сертификат не подтверждает новый адрес, а новый владелец прежнего IP потенциально получает уже другую сетевую точку. Для подключения с меняющимся адресом доменное имя обычно удобнее.
С IPv6 действует тот же принцип. Сертификат выдаётся на конкретный IPv6, а не на весь выделенный провайдером префикс /64. Не выбирайте временный IPv6, который операционная система периодически меняет ради приватности. Для сервера нужен стабильный адрес. При этом лимит Let’s Encrypt для новых сертификатов считается не по каждому IPv6 отдельно, а по всему /64.
По актуальным лимитам Let’s Encrypt допускает до 50 новых сертификатов за семь дней для одного IPv4 или одной IPv6-сети /64. Обычные продления распознаются отдельно, а продления через ACME Renewal Information освобождены от лимитов. Поэтому короткий срок IP-сертификата сам по себе не означает, что автоматическое продление быстро исчерпает квоту.
Для домашней сети, панели маршрутизатора, лаборатории или сервера с адресом 192.168.x.x лучше выбрать собственный центр сертификации либо самоподписанный сертификат и добавить доверенный корневой сертификат на нужные устройства. Для публичного VPS, API или оборудования без удобного доменного имени сертификат Let’s Encrypt на IP уже может быть полноценным решением. Для административной панели с постоянным IP нужно учитывать дополнительный риск.
Let’s Encrypt отправляет все выпущенные сертификаты в публичные журналы Certificate Transparency. IP из SAN такого сертификата становится доступен для поиска и автоматического сбора, поэтому административную панель нельзя считать скрытой только потому, что у неё нет домена. HTTPS для панели лучше сочетать с VPN, межсетевым экраном, ограничением доступа по IP или другой защитой.
Домен всё равно удобнее, если сервер может сменить адрес, работает через балансировщик, несколько узлов или сеть доставки содержимого. Домен сохраняет постоянное имя сервиса независимо от того, какой IP находится за ним.
Вопросы и ответы
Можно ли получить SSL-сертификат на IP без домена?
Да. Let’s Encrypt с 15 января 2026 года общедоступно выдаёт TLS-сертификаты на публичные IPv4 и IPv6. Домен для такого сертификата не требуется.
Можно ли получить сертификат Let’s Encrypt на 192.168.1.1?
Нет. 192.168.1.1 относится к частному диапазону. Публичные центры сертификации не могут выдавать доверенные TLS-сертификаты на зарезервированные IP. Для локальной сети нужен собственный центр сертификации или самоподписанный сертификат.
Работает ли Let’s Encrypt с IPv6?
Да. В сертификат можно включить публичный IPv6 через параметр Certbot --ip-address. Let’s Encrypt должен иметь возможность подключиться именно к указанному адресу для проверки контроля.
Можно ли включить IPv4 и IPv6 в один сертификат?
Да. Certbot позволяет повторить --ip-address несколько раз. Все адреса попадут в SAN одного сертификата, если проверка каждого адреса завершится успешно.
Нужен ли открытый порт 80?
Для HTTP-01 нужен доступ к порту 80 с интернета. Протокол ACME также допускает проверку IP через TLS-ALPN-01 на порту 443, если выбранный клиент поддерживает такой способ.
Почему IP-сертификат Let’s Encrypt действует только несколько дней?
Для IP-сертификатов Let’s Encrypt требует короткоживущий профиль. Сертификат действует 160 часов. Короткий срок уменьшает последствия утечки закрытого ключа, но требует полностью автоматического продления.
Сработает ли сертификат на IP при CGNAT?
Обычно нет. При CGNAT устройство не управляет внешним публичным IP напрямую, а входящие соединения на нужный порт не доходят до сервера. Для проверки Let’s Encrypt нужен публично маршрутизируемый адрес, контроль которого может подтвердить сервер.
Что лучше: сертификат на IP или домен?
Для постоянного публичного IP оба варианта дают доверенный HTTPS. Домен удобнее при смене адресов, балансировке и переносе сервиса. IP-сертификат полезен, когда сервис должен открываться непосредственно по стабильному публичному адресу.
Настраивайте сертификаты и сетевые службы только на серверах и IP-адресах, которыми вправе управлять. При публикации сервисов в интернете соблюдайте требования законодательства РФ и не открывайте административные интерфейсы без дополнительной защиты доступа.
