Срок публичного TLS-сертификата

План продления зависит от даты следующего выпуска. Число, действовавшее для старого сертификата, нельзя автоматически переносить на новый или на сертификаты частной PKI.

1. 01

   В проверенной таблице CA/Browser Forum для публичных серверных TLS-сертификатов предшествующая ступень до 15 марта 2026 года равна 398 дням; с 15 марта 2026 года до 15 марта 2027 года — 200 дням; с 15 марта 2027 года до 15 марта 2029 года — 100 дням; с 15 марта 2029 года — 47 дням. Нижняя дата каждого интервала включается, верхняя — нет.

   Граница применимости: CA/Browser Forum, серверные Baseline Requirements, 6.3.2; проверенный редактором срез от 8 сентября 2026 года. Обязанность издателя; не универсальный предел для частной PKI.

2. 02

   Для выпуска с 15 марта 2026 года до 15 марта 2027 года стандарт рекомендует не превышать 199 дней и запрещает превышать 200 дней. Для остальных ступеней пары «рекомендуемый предел / запрещено превышать» составляют 397/398, 99/100 и 46/47 дней.

   Граница применимости: Различие SHOULD NOT и MUST NOT в 6.3.2 серверных Baseline Requirements; рекомендация не превращена в безусловный запрет.

3. 03

   При расчёте предела сутки равны 86 400 секундам. Превышение целого числа суток, включая доли секунды или дополнительную секунду, учитывается как ещё одни сутки. Поэтому правила рекомендуют не выпускать сертификаты ровно на разрешённый максимум по умолчанию.

   Граница применимости: Правило счёта времени в 6.3.2 серверных Baseline Requirements; относится к периоду действия, а не к выбору рабочего запаса на доставку.

4. 04

   Для выпуска с 15 марта 2026 года короткоживущим считается сертификат со сроком не более семи дней, или 604 800 секунд. Эти семь дней определяют отдельную категорию и не заменяют общий предел 200 дней для выпуска до 15 марта 2027 года.

   Граница применимости: Определение короткоживущего сертификата в 1.6.1 и общий предел в 6.3.2 серверных Baseline Requirements; исключения для категории здесь не перечисляются.

5. 05

   Продление означает новый выпуск. Если новый сертификат выпускается после даты очередного снижения предела, к нему относится новая ступень, даже когда прежний сертификат законно имел больший срок. Получение нового файла ещё не подтверждает его установку на сервис.

   Граница применимости: Практический вывод из таблицы 6.3.2 и процесса нового выпуска ACME; срок старого сертификата не меняется задним числом только из-за перехода календарной границы.

1. Установите, относится ли выпуск к публичным серверным TLS-сертификатам.
2. Зафиксируйте дату выпуска и применимую редакцию правил.
3. Выберите интервал таблицы с включённой нижней границей.
4. Разделите рекомендуемый и обязательный пределы.
5. Проверьте длительность в секундах с учётом правила округления.
6. Не подменяйте общий предел определением короткоживущего сертификата.
7. Отдельно запланируйте доставку и проверку нового сертификата.

• Первичная спецификация

  Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates

  CA/Browser Forum · Server Certificate BR: проверенный редактором срез 8 сентября 2026 года

  Редакторские выписки из 6.3.2, 1.6.1, 6.1.1.1 и 6.2. Номер редакции и commit среза не предоставлены; уровень модуля по 6.2.7 не проверен.

  Открыть первоисточник ↗
• Первичная спецификация

  Automatic Certificate Management Environment

  Internet Engineering Task Force · RFC 8555, March 2019

  Определяет ACME account, order, authorization, challenge, finalize, certificate download и revocation workflow.

  Открыть первоисточник ↗
• Официальная документация

  Recommendation for Key Management: Part 1 — General

  National Institute of Standards and Technology · NIST SP 800-57 Part 1 Revision 5, May 2020

  Определяет key-management functions, lifecycle states, cryptoperiods, protection, backup/recovery, compromise и destruction.

  Открыть первоисточник ↗