Назад к блогу

Сокращение срока жизни TLS-сертификатов: 90 дней уходят в прошлое

Сокращение срока жизни TLS-сертификатов: 90 дней уходят в прошлое

Let's Encrypt опубликовал точный график отказа от 90-дневных TLS-сертификатов: первые 64-дневные появятся в феврале 2027 года, а к 2028-му срок сократится до 45 дней. Параллельно CA/Browser Forum закрепил общеотраслевые лимиты — до 47 дней к 2029 году. Разбираем, как это отразится на автоматизации выпуска и продления сертификатов.

Let's Encrypt объявил график перехода на короткоживущие TLS-сертификаты: с 10 февраля 2027 года профиль classic начнёт выпускать сертификаты со сроком действия 64 дня, а с 16 февраля 2028 года — 45 дней. Последний 90-дневный сертификат, как ожидается, истечёт 11 мая 2027 года. Действующие сертификаты при этом отзываться не будут.

Изменения затрагивают не только срок жизни сертификата, но и период повторного использования авторизации — время после подтверждения контроля над доменом, в течение которого для него можно выпускать сертификаты. Сейчас он составляет 30 дней, к 2028 году сократится до семи часов.

Что именно меняется

График Let's Encrypt разбит на этапы:

  • 13 мая 2026 года — профиль tlsserver начинает выпускать 45-дневные сертификаты.
  • 14 октября 2026 года — переключение на 64-дневные сертификаты в staging-среде для тестирования.
  • 10 февраля 2027 года — профиль classic по умолчанию переходит на 64-дневные сертификаты с 10-дневным периодом повторного использования авторизации. Любой сертификат, выпущенный или продлённый начиная с этой даты, получит срок действия 64 дня.
  • 16 февраля 2028 года — профиль classic переходит на 45-дневные сертификаты с 7-часовым периодом повторного использования авторизации.

При выпуске можно выбрать и более короткий срок — 45 или 6 дней.

Параллельно CA/Browser Forum принял Ballot SC081v3, который задаёт общую для индустрии планку. Бюллетень расширяет Section 4.2.1, детализируя допустимые периоды повторного использования данных проверки, и Section 6.3.2, задавая график сокращения максимальных сроков действия публичных TLS-сертификатов. Итоговые значения: максимальный срок действия сертификата — с 398 до 47 дней, повторное использование не-SAN данных проверки — с 825 до 398 дней, SAN-данных — с 398 дней до 10 дней. Сокращения предложено начать в марте 2026 года и завершить в марте 2029 года. По графику из русскоязычного источника: с 15 марта 2026 года — до 200 дней, с 15 марта 2027 года — до 100 дней, с 15 марта 2029 года — до 47 дней для сертификата и до 10 дней для DCV.

Предыстория

До этих изменений Let's Encrypt выпускал сертификаты со сроком действия 90 дней. Объявляя о переходе, компания описала его как сокращение срока вдвое — до 45 дней к 2028 году — и сокращение периода повторного использования авторизации с 30 дней до 7 часов к тому же сроку.

В отличие от первоначального плана (90 → 45 дней), в расписании появился промежуточный этап: 10 февраля 2027 года профиль classic переходит на 64-дневные сертификаты, а не сразу на 45. Период повторного использования авторизации на этом этапе сокращается до 10 дней, а не сразу до 7 часов. Финальный переход перенесён на 16 февраля 2028 года.

Русскоязычный источник упоминает, что ранее Apple предложила сократить срок действия сертификатов, а команды Google Chrome и Mozilla поддержали этот шаг. Голосование CA/Browser Forum по Ballot SC081v3 прошло с 25 голосами «за» от издателей сертификатов и 4 голосами «за» от потребителей сертификатов при кворуме 16.

Почему это сделали

Let's Encrypt прямо называет причину: сокращение сроков снижает риск компрометации ключей и неправильной выдачи сертификатов. Компания также указывает, что это ограничивает масштаб компрометации и делает технологии отзыва сертификатов более эффективными.

CA/Browser Forum в бюллетене приводит более развёрнутое обоснование. Сертификаты с некогда корректным, но устаревшим содержимым создают реальный риск для сайтов, владельцев доменов и полагающихся сторон; сокращение сроков действия и периодов повторного использования данных уменьшает вероятность того, что сертификат останется действительным после того, как информация в нём перестала быть точной. Форум ссылается на прошлые и недавние исследования, подтверждающие этот риск — будь то истечение домена, доступ или контроль над ключом со стороны третьих лиц либо другие события, позволяющие третьей стороне выдать себя за чужой домен.

Отдельно Форум отмечает, что удостоверяющие центры иногда выпускают сертификаты в нарушение политик, требований или спецификаций, а более частая проверка информации и снижение максимального срока действия уменьшают риск неправильной проверки и масштаб её последствий. Сокращение максимального срока действия также помогает быстрому переходу между криптографическими алгоритмами при обнаружении слабости.

Форум указывает и на проблемы существующих механизмов отзыва: службы статуса сертификатов, такие как CRL и OCSP, по его оценке, неадекватно защищают полагающиеся стороны при текущем масштабе интернета — из-за проблем с приватностью, производительностью, своевременностью статусов и точностью данных. Отзыв сертификатов не всегда происходит своевременно и надёжно, а сами службы статуса создают нагрузку на полагающиеся стороны и пользователей сайтов.

Что это меняет на практике

Ключевое изменение для инфраструктуры — переход от жёстко заданного расписания продления к механизму, при котором удостоверяющий центр сам сообщает клиенту, когда продлевать. Let's Encrypt рекомендует включить его, чтобы продление происходило вовремя. Способ включения зависит от конкретного ACME-клиент, поэтому нужно смотреть его документацию.

Если клиент ещё не поддерживает ARI, нужно настроить расписание, совместимое с 45-дневными сертификатами. Продление на жёстко заданном интервале 60 дней перестанет быть достаточным. Приемлемым поведением считается продление примерно на двух третях срока жизни текущего сертификата. Ручное продление не рекомендуется: при более коротких сроках жизни делать это придётся чаще.

Let's Encrypt рекомендует искать захардкоженные числа 83, 80 и 60 в cron-задачах, скриптах-обёртках и runbook'ах — это распространённые прежние целевые значения продления для 90-дневных сертификатов. Их следует обновить так, чтобы продление происходило примерно на ⅔ срока жизни сертификата. Это подготовит инфраструктуру к 64-дневному сроку по умолчанию, а затем и к 45-дневному в 2028 году. Если продление автоматизировано и клиент поддерживает ARI, менять ничего не нужно.

Также рекомендуется проверить, поддерживает ли ACME-клиент ARI, и при отсутствии — обновить скрипты продления, а также настроить уведомления на случай истечения сертификата или сбоя продления. Для мониторинга предлагается ssl_exporter — плагин Prometheus — либо любое средство, работающее по принципу dead man's switch. Скрипты контроля сроков действия сертификатов сравнивают число дней до истечения с порогом 14 дней и предупреждают о скором истечении; в них отмечена необходимость снижать этот порог при уменьшении сроков жизни сертификатов.

Новый DNS-челлендж

DNS-челлендж — это способ доказать удостоверяющему центру, что заявитель контролирует домен, разместив в его DNS-зоне специальную TXT-запись. Let's Encrypt совместно с партнёрами в CA/Browser Forum и IETF стандартизирует новый метод валидации — DNS-PERSIST-01. Его ключевое преимущество в том, что DNS TXT-запись, подтверждающая контроль над доменом, не обязана меняться при каждом продлении. Запись можно настроить один раз и затем автоматически продлевать сертификаты без необходимости автоматически обновлять DNS. Это также снижает зависимость от повторного использования авторизации, поскольку DNS-записи могут оставаться неизменными без дальнейшего участия ACME-клиента.

По данным русскоязычного источника, в DNS-PERSIST-01 TXT-запись привязывает право управления именем не к токену, уникальному для каждого заказа сертификата, а к долговременному ACME-аккаунту, которому разрешено выпускать сертификаты. Ожидается, что DNS-PERSIST-01 станет доступен в 2026 году.

Ограничения и открытые вопросы

CA/Browser Forum признаёт, что деприкация криптографических алгоритмов — обычно сложный процесс, затрагивающий критичные для безопасности свойства использования сертификатов, а слабость может быть выявлена в алгоритме, библиотеке или аналогичном компоненте в любой момент, с предупреждением или без него.

Надёжность сервисов статуса сертификатов непоследовательна, в том числе потому, что для эффективности статусов требуется действие нескольких сторон. Не каждый потенциально проблемный сертификат отзывается, тем более своевременно. Решения этих проблем требуют действий нескольких сторон, не все из которых представлены в CA/Browser Forum, и не полностью входят в сферу способности Форума гарантировать их принятие.

Форум также признаёт, что снижение сроков действия и периодов повторного использования данных требует изменений далеко за пределами его прямого охвата, поэтому функционально невозможно определить все возможные переменные и факторы до принятия изменений.

Let's Encrypt обещает делиться дополнительными обновлениями, напоминаниями и другими изменениями в рассылке technical updates.

Источники

Похожее