Кратко

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

Система выпуска получила три SCT и успешно проверила подписи. Сертификат доставлен на нужные точки завершения TLS. Тем не менее часть браузеров разрывает соединение. Это не две несовместимые истины, а два разных контрольных состояния: журнал выдал квитанцию, клиент применил собственные правила.

RFC 9162 определяет SCT как обещание Certificate Transparency-журнала поместить принятую запись в дополняемое Merkle-дерево в пределах Maximum Merge Delay. Позже можно проверить включение и согласованность дерева. RFC отдельно подчёркивает: проверка SCT не заменяет обычную проверку серверного сертификата и цепочки.

Chrome учитывает способ передачи SCT, число разных журналов, независимость операторов и состояние журнала как при создании SCT, так и при проверке сертификата. Для встроенных SCT в сертификате сроком не более 180 дней нынешняя политика требует как минимум два разных журнала и двух разных операторов; при проверке хотя бы один журнал должен оставаться в учитываемом состоянии. Для передачи через TLS действует другая комбинация.

Поэтому показатель «три корректных SCT» неполон. За ним могут скрываться один оператор, изменившийся статус журнала или способ доставки, к которому применяются иные условия.

Решение зависит от списка на стороне клиента

Chrome ежедневно публикует новый список CT-журналов с операторами и состояниями жизненного цикла. Это не вечный перечень доверия: для результата важно, что клиент знает в момент проверки.

Есть и 70-дневный порог свежести. Если клиент долго не получает поддерживаемый новый список, Chrome отключает принудительное применение CT. Успешный тест на старом устройстве может означать отсутствие проверки, а не соответствие современной политике. В доказательстве нужны версия клиента, метка времени списка и состояние CT.

Список Chrome нельзя считать универсальной властью для всех клиентов. Google ограничивает его назначение экосистемой Chrome и предупреждает другие приложения против самостоятельного принуждения на его основе. Apple публикует отдельные правила: различает журналы, одобренные сейчас и ранее, задаёт собственные сочетания SCT и ограничивает вклад одного оператора. Общий протокол не превращает решения клиентов в одну формулу.

Временные шарды ограничивают пригодность журнала

Новые журналы в программе Chrome должны быть разделены по времени. Каждый шард принимает сертификаты, чей notAfter попадает в заявленный диапазон. Значит, выбор журнала зависит от срока сертификата вместе с оператором и текущим статусом.

Руководство Chrome для владельцев сайтов предупреждает, что CT-информация в действующем сертификате способна потерять пригодность до истечения самого сертификата. Тогда нужны новые SCT через TLS либо замена сертификата. Мониторинг одной даты окончания не видит этот более ранний риск.

Проверенные факты здесь — текст RFC и опубликованные политики Chrome и Apple. Требование сверять квитанцию с реальными клиентами является операционным выводом. Открытые источники не показывают состав браузеров, исключения, точки завершения, точность симулятора или аварии конкретной организации. Они также не доказывают текущий сбой какого-либо центра, журнала или браузера. Неизвестное требует собственных измерений.

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

Источники