Let's Encrypt выдает SSL по IP: как это работает и как настроить без домена
С 15 января 2026 года Let's Encrypt официально запустил бесплатные TLS-сертификаты для IP-адресов. Звучит просто: больше не нужен домен, чтобы получить "зеленый замок" в браузере, достаточно публичного IP. Но у этой свободы есть цена: сертификаты короткие, проверки строже, а автоматизация из приятной опции превращается в обязательное условие.
Что именно изменилось 15 января 2026 и почему это важно
Раньше публичный TLS в привычном виде почти всегда крутился вокруг доменных имен: сертификат подтверждает, что вы контролируете имя, а браузер сверяет его с адресной строкой. С IP все было сложнее: технически в стандартах это разрешено давно, но массового бесплатного варианта не было, и большинство админов даже не рассматривали идею всерьез. Теперь ситуация изменилась: Let's Encrypt разрешил выпуск сертификатов, где идентификатором выступает сам IP, причем поддерживаются и IPv4, и IPv6.Ключевая деталь: IP-сертификаты выдаются только как "краткоживущие", сроком на 160 часов, то есть чуть больше 6 дней. Это выглядит странно, пока не вспоминаешь природу IP: адреса могут мигрировать между владельцами и инфраструктурой заметно чаще, чем домены. Укороченный срок снижает шанс, что чей-то "вчерашний" сертификат внезапно начнет легитимировать "сегодняшний" сервис на том же адресе.
В реальности это открывает нишевые, но очень практичные сценарии: дефолтная заглушка по IP для хостинга, быстрый доступ к серверу без домена, защищенный доступ к домашним устройствам на белом IP, краткоживущие бэкенды в облаке, стенды для тестирования, и отдельный класс инфраструктуры вроде DNS-over-HTTPS. В 2026 году это уже не "игрушка для гиков", а рабочий инструмент, если у вас есть дисциплина в автоматизации.
Почему сертификат всего на 6 дней: логика безопасности без романтики
Короткий срок действия решает сразу две старые проблемы TLS. Первая - компрометация ключа: если ключ утек, классическая схема опиралась на отзыв сертификата, но отзыв в вебе исторически работает так себе. Многие клиенты продолжают доверять сертификату до истечения срока, даже если он уже отозван, и это оставляет широкое окно уязвимости.Вторая проблема - сама природа IP-адресов. Домен обычно живет годами и меняет владельца редко, а вот IP может переехать из одного пула в другой, сменить арендатора, или в случае облака вообще быть временным. Частая ревалидация тут не прихоть, а страховка от кривых сценариев, когда право на адрес уже изменилось, а доверие клиента еще нет.
Поэтому "6 дней" - это не наказание, а расчет. Но расчет с последствиями: ручное продление становится почти бессмысленным, а любой сбой в автоматике превращается в простой сервиса. Если вы не готовы жить в режиме "обновление как дыхание", лучше остаться на домене и классической схеме.
Ограничения и требования: что нужно знать до первой попытки
Чтобы получить IP-сертификат, вам нужен ACME-клиент, который умеет выбирать профили сертификатов. В Let's Encrypt это реализовано через механизм ACME Profiles, и для IP обязательно требуется профиль shortlived. Если клиент не поддерживает профили или не умеет передавать нужный профиль, заявка будет отклоняться, и вы будете видеть ошибки в духе "профиль не разрешает IP". Это не "у вас руки кривые", это значит, что клиент надо обновлять или менять.Второй жесткий момент - методы валидации. DNS-01 тут не применяется по очевидной причине: вы не доказываете контроль над доменом, вы доказываете контроль над конкретным IP. Поэтому остаются только http-01 или tls-alpn-01. То есть вам нужно уметь временно отдавать challenge по HTTP на 80 порту или принимать ALPN-проверку на 443 порту. Если ваш провайдер режет входящий 80, или вы не контролируете 443, план ломается еще до старта.
Третье - короткий цикл продления. 160 часов - это не про "раз в месяц проверю". Это про постоянный график, мониторинг, и желательно поддержку рекомендаций по продлению вроде ARI, чтобы клиент обновлял сертификаты вовремя и без дерганья. Если автоматизация слабая, IP-сертификаты превращаются в генератор ночных аварий.
Пошаговый план настройки: от идеи до работающего HTTPS по IP
Шаг 1. Проверьте модель доступа к сервису. Вам нужен публично доступный IP и понимание, по какому порту клиенты будут подключаться. Если это обычный веб, речь почти всегда про 443 и иногда про 80 для валидации. Если это инфраструктурный сервис, важно заранее решить, выдержите ли вы требования http-01 или tls-alpn-01.Шаг 2. Убедитесь, что 80 и 443 доступны извне. Для http-01 требуется входящий 80/tcp на тот же IP, на который вы выпускаете сертификат. Для tls-alpn-01 требуется 443/tcp. Если у вас за NAT и нет проброса, или IP не ваш, выпуск сертификата для IP бессмысленен, даже если технически клиент "умеет".
Шаг 3. Выберите ACME-клиент с поддержкой профилей. Критерий простой: клиент должен уметь передать профиль shortlived. Если вы работаете в Kubernetes, проверьте поддержку профиля в cert-manager и задайте профиль в Issuer/ClusterIssuer. Если вы на отдельном сервере, проверьте документацию вашего клиента, умеет ли он выбор профиля вообще, и как именно он это делает.
Шаг 4. Включите профиль shortlived для заявки. Это обязательное условие для IP. На практике это выглядит как параметр "profile: shortlived" в настройках клиента или в объекте запроса. Без этого Let's Encrypt будет вести себя так, будто вы пытаетесь выпустить "обычный" сертификат на IP, а это запрещено политикой выпуска.
Шаг 5. Настройте метод валидации. Если проще временно поднять ответ на 80 порту, выбирайте http-01. Если у вас 80 закрыт, но 443 стабилен и вы уверенно управляете TLS-терминацией, рассмотрите tls-alpn-01. Важно: это не теоретическая галочка, это реальный доступ извне, иначе валидация не пройдет.
Шаг 6. Сделайте обновление полностью автоматическим. Для 6-дневного сертификата здоровый режим - попытка продления раз в сутки или хотя бы раз в 12-24 часа, плюс уведомления при сбое. Хороший тон - не ждать "последнего дня", потому что любой провал валидации или сетевой глитч может съесть остаток срока.
Шаг 7. Проверьте клиентскую сторону и цепочку доверия. После выпуска убедитесь, что сервер отдает полный цепочный комплект, а клиенты не ругаются. Короткоживущие сертификаты должны работать прозрачно, но ошибки в цепочке или в настройке веб-сервера никто не отменял.
Пример для Kubernetes: cert-manager и профиль shortlived
Если вы крутите сервис в Kubernetes, то один из самых понятных сценариев - cert-manager, потому что у него есть документированная поддержка выбора профиля ACME. В этом подходе вы описываете Issuer/ClusterIssuer, указываете сервер Let's Encrypt, задаете профиль shortlived и выбираете solver для http-01 (через Ingress) или tls-alpn-01, если ваша схема это поддерживает.Ниже пример, который показывает сам принцип. Конкретные поля solver зависят от вашего ingress-контроллера, но идея одна: профиль shortlived плюс http-01, а в качестве идентификатора вы используете IP, на который смотрит Ingress или LoadBalancer.
Код:
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-shortlived
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: [email protected]
privateKeySecretRef:
name: le-shortlived-account-key
profile: shortlived
solvers:
- http01:
ingress:
class: nginxГде это реально полезно: 5 сценариев без маркетинговой пыли
1) Заглушка по IP для хостинга и провайдеров. Классика: человек вводит IP в браузере, а вместо страшного предупреждения получает корректную страницу. Для хостинга это мелочь, которая неожиданно влияет на доверие пользователей и поддержку.2) Домашние устройства на белом IP. NAS, панель управления роутером, веб-интерфейсы IoT. Если домена нет и покупать не хочется, IP-сертификат позволяет включить HTTPS без плясок с DNS. Но тут особенно важен контроль доступа, потому что открывать домашнее устройство в интернет "просто потому что есть SSL" - плохая идея.
3) Эфемерные инстансы в облаке. Быстрые окружения, временные админские панели, сервисы на период миграции. Там домен иногда только мешает, а IP меняется часто, и короткий сертификат ложится в эту логику естественно.
4) Стейджинг и тестовые стенды DevOps. Когда нужно проверить реальное TLS-поведение клиента или прокси, но домен тянуть не хочется. Да, можно self-signed, но публичный сертификат снимает массу "если бы" в тестировании.
5) Инфраструктурные сервисы вроде DoH. Для некоторых клиентов наличие публично доверенного сертификата на конкретный адрес повышает качество проверки подлинности сервиса. Это не универсальный паттерн, но в инфраструктуре такие мелочи иногда решают половину проблем с совместимостью.
Почему дальше будет только жестче: сокращение сроков до 45 дней
IP-сертификаты сейчас стали самой заметной новостью, но фоновое движение шире: индустрия в целом сокращает срок жизни сертификатов. Let's Encrypt расписал таймлайн заранее, и он выглядит как постепенное "закручивание гаек" не ради боли, а ради снижения рисков компрометации и повышения дисциплины продления.По плану, с 13 мая 2026 появится opt-in профиль tlsserver, который будет выдавать 45-дневные сертификаты. Затем 10 февраля 2027 профиль classic по умолчанию перейдет на 64 дня, а 16 февраля 2028 classic дойдет до 45 дней, при этом сократится и период повторного использования авторизации. Если вы привыкли к автоматике "раз в 60 дней", это будет ломать выпуск, и лучше адаптироваться заранее.
Вывод простой: если вы уже умеете жить на 6-дневных сертификатах, переход на 45 дней пройдет для вас почти незаметно. А если вы продлеваете вручную или по расписанию "как получится", то ближайшие пару лет будут неприятным аттракционом. В этом смысле IP-сертификаты - это не просто новая функция, а тест на зрелость вашей инфраструктуры.
Выводы
Let's Encrypt дал бесплатный HTTPS по IP, но сделал его взрослым: только 160 часов, только профиль shortlived, только http-01 или tls-alpn-01, только автоматизация. Это честная сделка: вы получаете простую точку входа без домена, а взамен обязуетесь держать продление и мониторинг в порядке.Если у вас есть белый IP и вам нужно быстро поднять защищенный доступ без доменной возни, новая схема реально удобна. Но если вы не готовы к дисциплине обновлений, лучше не начинать с IP-сертификатов и не превращать TLS в лотерею. Здесь выиграет не тот, кто "поставил галочку", а тот, кто настроил процесс так, чтобы он работал даже ночью и без настроения.
Редакция PavRC