15 января 2026 г. — Let’s Encrypt официально объявил о широкой доступности короткоживущих (short-lived) сертификатов с временем жизни около 160 часов (чуть более шести дней), а также SSL-сертификатов, работающих с IP-адресами вместо доменных имен.
Почему Let’s Encrypt ввёл шестидневные сертификаты
До сих пор стандартные сертификаты от Let’s Encrypt действовали 90 дней, что заставляло полагаться на такие механизмы, как OCSP и CRL для отзыва при компрометации ключей. Однако эти системы часто оказываются недостаточно надёжными и оперативными, а уязвимый сертификат может оставаться действительным до своего истечения.
Короткоживущие сертификаты решают эту проблему иначе:
они значительно сокращают окно атаки — максимум до ~6 дней,
делают необходимость ручной отзыва практически неактуальной,
стимулируют автоматизацию обновлений (чего и добивались авторы ACME).
Важно, что такие сертификаты не включены по умолчанию — их надо опционально выбирать с помощью профиля shortlived в ACME-клиенте.
Сертификаты для IP-адресов
Помимо короткой жизни сертификатов, Let’s Encrypt теперь выпускает сертификаты, в которых в качестве идентификатора указан IP-адрес (как IPv4, так и IPv6) вместо доменного имени. Это избавляет от ситуации, когда серверу требуется доменное имя лишь для получения доверенного TLS-сертификата.
Особенности этой поддержки:
IP-сертификаты всегда являются короткоживущими — срок действия ~6 дней,
поддерживаются только challenge-методы
http-01иtls-alpn-01(DNS-challenge для IP недоступен),решает задачи TLS-шифрования для сервисов, где домен отсутствует (например, IoT-устройства, серверы внутри сети или тестовые стенды).
Поддержка IP-сертификатов обсуждалась ещё в 2025 году и сначала была доступна в тестовом режиме, а теперь перешла в полноценный продакшн.
Что это означает для администраторов и разработчиков
Автоматизация — необходимость
Шестидневные сертификаты практически вынуждают автоматизировать обновления. Без надёжной автоматизации вы получите частые истечения и риски разрыва HTTPS-соединений.
Опция, а не принуждение
Let’s Encrypt не делает короткоживущие сертификаты стандартом по умолчанию — этот шаг даёт выбор. Тем не менее, их популярность может вырасти, особенно среди тех, кто уже использует автоматическую ACME-интеграцию.
Будущее сроков жизни сертификатов
Организация также подтвердила, что в ближайшие годы стандартный срок жизни классических сертификатов будет уменьшен с 90 до 45 дней в рамках общего тренда индустрии.
Практические случаи использования
Серверы и сервисы без доменов — HTTPS для сервисов внутри корпоративной сети.
DevOps и CICD среды — автоматическое обновление секретов на каждом деплое. (см. ACME профиль)
Встроенные устройства и IoT — сертификат для подключения по IP, без необходимости DNS.
Вывод
Let’s Encrypt продолжает эволюционировать с акцентом на безопасность и автоматизацию. Шестидневные сертификаты и поддержка IP-адресов — значительный шаг к более гибкому, безопасному и универсальному использованию TLS в разнообразных сценариях. Тем самым Let’s Encrypt все больше придвигает конец эпохи «долгоживущих» SSL-сертификатов.
Эти изменения могут потребовать обновления ваших ACME-клиентов и CI/CD-настроек, но преимущества в безопасности и управляемости очевидны.
MountainGoat
Лол, ага. На тестовые стенды внутри сети. Ещё допишите – в оффлайне.
gev
На локалхост!
achekalin
Ну так-то да, и внутри сеть по https куда удобнее ходить.
Хотя бы потому, что браузеры нынче http не очень уважают.
Да и не везде http даже внутри сети по политикам компаний разрешен.
MountainGoat
Удобнее. Вы как проверку внутреннего IP сервером LetsEncrypt осуществлять собираетесь?
Politura
Чтобы вам выдали сертификат, lets encrypt должен убедиться, что вы владеете ресурсом, на который сертификат выдается, для этого делает запрос на этот ресурс и ожидает определенный ответ от него. Если в качестве ресурса вы предоставите ip адрес вашей внутренней сети, куда уйдет проверяющий запрос lets encrypt?
NAI
при использовании ipv6 запрос может спокойно уйти на конечное устройство.
Тут конечно вопрос к переводу/LE что считать "внутренней сетью" - то что закрыто NATом? То что закрыто файволлом? пулл-адресов выданных конечному пользователю?
gev
Непубличные диапазоны адресов, неадминистрируемые?
NAI
с ipv6 все становится сильно сложнее и проще. Вот SLAAC выдаст всем устройствам вашего дома по публичному ipv6-адресу - все, можете подключаться к своему водонагревателю с любой точки мира. Звучит не очень секьюрно, надо сходить и настроить файрволл. Это как, считать администрируемым или нет?
Это сильно противоречит логике ipv6 - смысл в том чтобы отказаться от NATa. Да, есть Unique-Local и Link-Logical, но основная идея чтобы каждое устройство имело публичный IPv6 адрес из назначенной вам(выданной провайдером) сети.
knnk
Ну странно, да, что кто-то решил, что речь о частных адресах)
Zpon
Плевое дело, надо всего-то реверс прокси развернуть на внешний ip