PKI в эксплуатации: сроки, журналы и проверяемая цепочка

Таблица CA/Browser Forum выбирает максимум по дате выпуска: до 15 марта 2026 года — 398 дней, далее до 15 марта 2027 года — 200, до 15 марта 2029 года — 100, затем — 47. Нижняя дата интервала включена.

Семь дней после 15 марта 2026 года — определение короткоживущего сертификата. Это не общий максимальный срок каждого публичного сертификата.

Продление является новым выпуском. Для него заново выбирают ступень таблицы; срок ранее выданного документа не сокращается только из-за наступления календарной границы.

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

Сутки равны 86 400 секундам. Время сверх целого числа суток, даже одна доля секунды, образует дополнительные сутки при проверке предела. Поэтому максимум не рекомендуется как значение по умолчанию.

В TLS 1.2 и раньше клиент может запросить status_request; согласованный ответ передаётся сообщением CertificateStatus сразу после Certificate.

В TLS 1.3 ответ находится в расширении соответствующей записи CertificateEntry. Форму прежнего отдельного сообщения сюда не переносим.

Пригодный вложенный ответ позволяет обойтись без отдельного запроса к службе статуса. Самостоятельные обращения клиента этим не запрещены.

Сверяем сертификат, подпись, полномочия ответчика и время ответа. Старое или чужое good не становится пригодным благодаря доставке внутри TLS.

RFC 6960 описывает протокол OCSP, а место ответа в TLS задают RFC 6066 и RFC 8446. Ссылку выбираем по объясняемому механизму.

Публично проверяемый журнал только добавляет записи; безусловное доверие самому журналу не предполагается.

SCT обещает включение за установленную задержку MMD. Полученная метка не является доказательством уже состоявшегося включения.

RFC 6962 допускает доставку метки через расширение X.509, расширение TLS или вложенный OCSP. Смена носителя не меняет смысл обещания.

Подписанная SCT не гарантирует правильный выпуск: владелец мог не наблюдать журнал, а центр — не отозвать ошибочный сертификат.

Неожиданная запись требует расследования. Она сама не выбирает якорь, не проверяет имя и не доказывает отказ конкретного клиента.

Корректная политика, полученная по HTTPS, позволяет запомнить узел и переводить будущие обращения на защищённый транспорт.

max-age обязателен и измеряется в секундах; includeSubDomains — отдельное необязательное распространение на поддомены.

Заголовок, полученный только по HTTP, не устанавливает политику HSTS.

При применении политики HTTP меняется на HTTPS, а явно указанный порт 80 — на 443. Это не правило замены любого порта.

Для известного узла HSTS совместимый клиент обязан прервать соединение при ошибке защищённого транспорта; обход предупреждения не соответствует этому требованию.

HSTS не доказывает внутренний TLS за прокси, правильность cookie или отсутствие XSS.

На дату редакторской проверки 8 сентября 2026 года RFC 7469 не переведён в Historic. Статус документа сам не показывает поддержку браузера.

HSTS принуждает к защищённому транспорту, HPKP ограничивает ключи принимаемой цепочки у поддерживающего клиента.

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

Правила требуют защищённую среду, доверенные роли, контроль несколькими людьми и разделение знания.

Применимые требования к модулю соотносят с политикой и регламентом центра. Пункт 6.1.1.1 сам не задаёт конкретную марку или числовой уровень FIPS.

Действия создания ключа журналируются. Для названных в правилах корневых и подчинённых центров нужны также предусмотренные материалы церемонии.

Вне указанной проверенной системы ключ защищают от раскрытия физической защитой, шифрованием либо сочетанием этих способов. Это не общее разрешение любого экспорта.

Модуль не подтверждает автоматически правильность полномочий и решений о подписи. Проверяем управление отдельно от защиты материала.

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

В серверном списке TLS 1.3 сертификат конечного узла обязателен первым, а список не пуст. Это правило относится к аутентификации сертификатом.

Терпимость к лишним сертификатам и прочему порядку рекомендована как SHOULD. Она не гарантирована каждому клиенту и не отменяет обязательный первый элемент.

Пропуск промежуточного сертификата в TLS 1.3 допустим, если известно, что поддерживаемые клиенты им располагают. Сохранённая копия у одного клиента не доказывает наличие у другого.

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