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 дней в рамках общего тренда индустрии.

Практические случаи использования

  1. Серверы и сервисы без доменов — HTTPS для сервисов внутри корпоративной сети.

  2. DevOps и CICD среды — автоматическое обновление секретов на каждом деплое. (см. ACME профиль)

  3. Встроенные устройства и IoT — сертификат для подключения по IP, без необходимости DNS.

Вывод

Let’s Encrypt продолжает эволюционировать с акцентом на безопасность и автоматизацию. Шестидневные сертификаты и поддержка IP-адресов — значительный шаг к более гибкому, безопасному и универсальному использованию TLS в разнообразных сценариях. Тем самым Let’s Encrypt все больше придвигает конец эпохи «долгоживущих» SSL-сертификатов.

Эти изменения могут потребовать обновления ваших ACME-клиентов и CI/CD-настроек, но преимущества в безопасности и управляемости очевидны.

Комментарии (29)


  1. MountainGoat
    16.01.2026 21:02

    • решает задачи TLS-шифрования для сервисов, где домен отсутствует (например, IoT-устройства, серверы внутри сети или тестовые стенды).

    Лол, ага. На тестовые стенды внутри сети. Ещё допишите – в оффлайне.


    1. gev
      16.01.2026 21:02

      На локалхост!


    1. achekalin
      16.01.2026 21:02

      Ну так-то да, и внутри сеть по https куда удобнее ходить.

      Хотя бы потому, что браузеры нынче http не очень уважают.

      Да и не везде http даже внутри сети по политикам компаний разрешен.


      1. MountainGoat
        16.01.2026 21:02

        Удобнее. Вы как проверку внутреннего IP сервером LetsEncrypt осуществлять собираетесь?


      1. Politura
        16.01.2026 21:02

        Чтобы вам выдали сертификат, lets encrypt должен убедиться, что вы владеете ресурсом, на который сертификат выдается, для этого делает запрос на этот ресурс и ожидает определенный ответ от него. Если в качестве ресурса вы предоставите ip адрес вашей внутренней сети, куда уйдет проверяющий запрос lets encrypt?


        1. NAI
          16.01.2026 21:02

          при использовании ipv6 запрос может спокойно уйти на конечное устройство.

          Тут конечно вопрос к переводу/LE что считать "внутренней сетью" - то что закрыто NATом? То что закрыто файволлом? пулл-адресов выданных конечному пользователю?


          1. gev
            16.01.2026 21:02

            Непубличные диапазоны адресов, неадминистрируемые?


            1. NAI
              16.01.2026 21:02

              неадминистрируемые

              с ipv6 все становится сильно сложнее и проще. Вот SLAAC выдаст всем устройствам вашего дома по публичному ipv6-адресу - все, можете подключаться к своему водонагревателю с любой точки мира. Звучит не очень секьюрно, надо сходить и настроить файрволл. Это как, считать администрируемым или нет?

              Непубличные диапазоны адресов

              Это сильно противоречит логике ipv6 - смысл в том чтобы отказаться от NATa. Да, есть Unique-Local и Link-Logical, но основная идея чтобы каждое устройство имело публичный IPv6 адрес из назначенной вам(выданной провайдером) сети.


        1. knnk
          16.01.2026 21:02

          Ну странно, да, что кто-то решил, что речь о частных адресах)


        1. Zpon
          16.01.2026 21:02

          Плевое дело, надо всего-то реверс прокси развернуть на внешний ip