Допустим, удостоверяющий центр по ошибке выпустил сертификат для моего домена другому человеку. Сертификат правильно подписан, цепочка ведёт к доверенному корню, имя домена совпадает, срок действия не истёк. С точки зрения обычной проверки X.509 перед браузером может лежать совершенно корректный сертификат, хотя получать его посторонний не должен был.
Для такой проблемы и появилась Certificate Transparency. CT не мешает удостоверяющему центру ошибиться и не доказывает, что сертификат «честный». Система делает выпуск публично наблюдаемым. SCT подтверждает взаимодействие с признанным журналом прозрачности, а механизмы отзыва сообщают браузеру, что ранее допустимому сертификату доверять больше нельзя. У Chrome одним из таких механизмов служит CRLSet. Смешивать CT, SCT и CRLSet в одну «проверку сертификата» неправильно.
Что именно делает Certificate Transparency
Обычная схема HTTPS начинается с удостоверяющего центра, или CA. Владелец домена запрашивает сертификат, CA проверяет право управлять доменом и подписывает сертификат своей цепочкой. Браузер доверяет сертификату не потому, что знает владельца сайта лично, а потому, что доверяет корневому сертификату CA и успешно проверяет всю цепочку.
Слабое место очевидно. Если доверенный CA ошибся, его систему взломали или подчинённый удостоверяющий центр нарушил правила, злоумышленник теоретически может получить криптографически корректный сертификат для чужого имени.
Certificate Transparency добавляет публичный журнал выдачи. На практике CA обычно сначала формирует precertificate, предварительную версию будущего сертификата, и отправляет её в несколько CT-журналов. В ответ получает Signed Certificate Timestamp, SCT. Затем CA включает полученные SCT в итоговый сертификат.
Запрос сертификата
|
v
Проверка домена у CA
|
v
Precertificate
|
+---------+---------+
| | |
v v v
CT log CT log CT log
| | |
SCT SCT SCT
| /
| /
v v v
Итоговый сертификат
|
v
БраузерSCT часто описывают как доказательство того, что сертификат уже находится в журнале. Формулировка не совсем точна. В классических журналах RFC 6962 SCT представляет собой криптографически подписанное обязательство журнала включить полученную запись не позднее установленной задержки. Новые журналы на базе Static CT API устроены немного иначе и позволяют связать SCT с уже определённой позицией записи. Для браузера главное другое. SCT должен быть криптографически корректным и исходить из журнала, который политика браузера признаёт допустимым.
Сам журнал представляет собой добавляемую структуру на основе дерева Меркла. Старые записи нельзя тихо заменить или вырезать, не нарушив криптографическую согласованность дерева. Мониторы могут скачивать журнал, сравнивать его состояния и искать сертификаты для интересующих доменов.
Современная экосистема CT уже не сводится к одному RFC. Браузерные реализации исторически выросли из RFC 6962, существует RFC 9162, а Chrome и Apple поддерживают также новый Static CT API. В Chrome переход зашёл довольно далеко. С апреля 2026 года сертификату больше не требуется хотя бы один SCT именно из журнала RFC 6962. Допустимый набор может состоять только из SCT от Static CT журналов. Текущие требования Chrome описаны в его CT-политике.
Для SCT, встроенных прямо в сертификат, Chrome сейчас требует два SCT от разных журналов при сроке действия сертификата до 180 дней включительно и три при более длинном сроке. Среди засчитанных SCT должны присутствовать как минимум два разных оператора журналов. Политика учитывает также состояние журнала в момент выдачи SCT и в момент проверки.
Здесь есть любопытный эффект последних изменений Web PKI. Для публичных TLS-сертификатов, выпущенных с 15 марта 2026 года, максимальный срок действия сократился до 200 дней. Значит, сертификат на 181-200 дней всё ещё попадает в категорию, где Chrome требует три встроенных SCT, а сертификату на 180 дней или меньше достаточно двух при соблюдении остальных требований. Дальше срок жизни будут сокращать ещё сильнее, до 100 дней, а затем до 47.
Ещё одна свежая деталь касается способа доставки SCT. Раньше Chrome мог учитывать SCT, переданный внутри прикреплённого OCSP-ответа. Начиная с Chrome 148 такой способ больше не засчитывается для выполнения CT-политики. Остаются SCT внутри сертификата и SCT, переданные через TLS. Практически почти все публичные CA давно предпочитают встраивать SCT непосредственно в сертификат.
У Firefox и платформ Apple собственные правила. Firefox применяет обязательную CT-проверку на настольных системах с версии 135, позднее механизм появился и на Android. Apple тоже требует CT для публично доверенных TLS-сертификатов. Поэтому фраза «браузер проверяет SCT» скрывает важную деталь. Конкретное количество SCT, допустимые журналы и способы доставки определяет политика конкретного поставщика.
Почему SCT не доказывает, что сертификат правильный
Представим, что CA ошибочно подтвердил чужому человеку контроль над example.com. После такой ошибки CA отправляет precertificate в CT-журнал. Журнал не обязан проводить повторную проверку владения доменом. Если цепочка соответствует условиям приёма журнала, тот фиксирует запись и выдаёт SCT.
В итоге вредоносный или ошибочно выпущенный сертификат вполне способен иметь прекрасные SCT.
Certificate Transparency отвечает на вопрос «виден ли выпуск», а не на вопрос «правильно ли CA выпустил сертификат».
Именно публичность превращает CT в средство обнаружения. Владелец домена может постоянно следить за появлением сертификатов с собственными именами. Если ночью появляется неизвестный сертификат от незнакомого CA, команда безопасности получает сигнал и начинает разбираться.
Практическая ценность такого подхода уже проверена историей. В 2015 году Symantec через принадлежащий ей Thawte выпустила без разрешения Google EV-precertificate для google.com и www.google.com. Google обнаружила выпуск именно через Certificate Transparency. Дальнейшая проверка вскрыла гораздо более широкие проблемы с тестовой выдачей сертификатов. Хороший пример показывает сильную сторону CT лучше любой теории. Система не помешала CA выпустить неправильный сертификат, но сделала действие видимым.
Предшествовавший CT инцидент DigiNotar показывает обратную картину. После компрометации удостоверяющего центра злоумышленники получили мошеннические сертификаты для крупных доменов, включая Google, а масштаб происшествия долго оставался неясным. Именно такие аварии показали, насколько плохо работает модель, где выпуск сертификатов фактически видят только CA и заказчик.
Есть и неприятная сторона прозрачности. Имена из публичных сертификатов становятся открытыми. Если компания выпускает сертификат для secret-project.example.com, рассчитывать на секретность имени уже нельзя. Сканеры CT регулярно используют такие записи для поиска новых поддоменов, тестовых сред и внешних сервисов.
CT-журналы содержат публичные данные, но публичность не даёт права атаковать найденные системы. Проверять чужие узлы нужно только законными способами, с учётом законодательства своей страны, включая российское, правил сервисов и разрешённых границ доступа. Данные CT нельзя использовать для несанкционированного доступа, слежки или взлома.
Где появляется CRLSet и почему CT недостаточно
Допустим, мониторинг сработал. Компания нашла чужой сертификат, CA подтвердил ошибку и отозвал сертификат. Запись из Certificate Transparency никуда не исчезает. И не должна исчезать, иначе журнал перестал бы выполнять свою задачу.
Теперь нужен другой механизм, который сообщит браузеру, что сертификат больше нельзя принимать.
Классический вариант называется Certificate Revocation List, CRL. CA периодически публикует подписанный список отозванных сертификатов. Клиент может скачать CRL и найти там серийный номер проверяемого сертификата.
Другой вариант, Online Certificate Status Protocol, OCSP, позволяет спросить о конкретном сертификате у сервера CA. Подход экономит трафик по сравнению с загрузкой крупных списков, но создаёт проблемы с задержками, отказоустойчивостью и приватностью. Запрос к OCSP-серверу способен раскрыть информацию о том, сертификат какого сайта интересует пользователя.
Chrome пошёл своим путём и использует CRLSet. Браузер периодически получает компактный набор сведений об отозванных сертификатах и цепочках. Согласно описанию Chromium, CRLSet прежде всего предназначен для быстрой блокировки сертификатов в аварийных ситуациях. Дополнительно Chrome включает часть обычных отзывов, собранных из CRL удостоверяющих центров.
Отсюда следует принципиальное ограничение. CRLSet никогда не был полной базой всех отозванных сертификатов интернета. Если сертификата нет в CRLSet, нельзя делать вывод, что CA его не отзывал.
Chrome также обычно не выполняет для каждого соединения живой запрос OCSP или загрузку CRL. Такой подход уменьшает задержки и не заставляет браузер сообщать CA, какие сайты открывает пользователь.
Firefox сегодня использует другой механизм, CRLite. Mozilla построила компактную локальную структуру на основе опубликованных CA списков отзыва и сертификатов из CT. Firefox регулярно обновляет данные и проверяет сертификат локально. Получилась интересная связь двух систем. Certificate Transparency помогает получить множество известных сертификатов, а CRL дают сведения об отзыве, после чего Firefox объединяет данные в структуру для локальной проверки.
| Механизм | Что показывает | Чего не показывает |
|---|---|---|
| Certificate Transparency | Публичный след выпуска сертификата или precertificate | Не подтверждает законность выдачи |
| SCT | Криптографически подтверждает участие допустимого CT-журнала | Не доказывает право получателя на домен |
| CRL | Какие сертификаты CA объявил отозванными | Сам по себе не гарантирует мгновенную доставку статуса браузеру |
| OCSP | Статус конкретного сертификата у CA | Не решает полностью проблемы приватности и доступности |
| CRLSet | Отобранные Chrome сведения об отзыве и аварийных блокировках | Не содержит полный список всех отзывов |
| CRLite | Позволяет Firefox проверять большую базу отзывов локально | Не имеет отношения к CRLSet и не используется Chrome |
Как проверить собственный сертификат
Для первого знакомства достаточно OpenSSL. Получаю сертификат сервера и всю переданную цепочку.
openssl s_client
-connect example.com:443
-servername example.com
-showcertsСохраняю конечный сертификат в leaf.pem и разбираю его.
openssl x509 -in leaf.pem -text -nooutУ сертификата со встроенными SCT OpenSSL обычно показывает раздел CT Precertificate SCTs. Внутри будут идентификаторы журналов, временные метки и подписи.
Само наличие такого раздела ещё не означает, что сертификат удовлетворяет текущей политике Chrome, Firefox или Apple. Нужно учитывать количество SCT, операторов журналов, состояние каждого журнала, момент выдачи SCT и срок действия сертификата. Кроме того, SCT может передаваться не внутри сертификата, а через TLS, поэтому анализ одного файла сертификата не всегда описывает всю картину.
Для поиска по журналам удобно использовать crt.sh. Сервис позволяет искать сертификаты и precertificate по имени домена. Здесь встречается ещё одна причина для ложной тревоги. Один выпуск иногда отображается несколькими похожими записями, поскольку CT может содержать precertificate и соответствующий итоговый сертификат. Совпадающие имена и близкие даты сами по себе не означают, что CA несколько раз выдавал сертификат злоумышленнику.
Для реального мониторинга я бы не ограничивался ручным поиском. Система должна получать новые CT-записи для корпоративных доменов и сравнивать их с ожидаемыми выпусками.
Новая запись CT
|
v
Наш домен или поддомен
|
v
Известный выпуск
/
да нет
| |
v v
архив проверка
|
+-- CA
+-- SAN
+-- серийный номер
+-- срок действия
+-- ожидаемый сервис
|
v
тревогаПолезно отдельно учитывать wildcard-сертификаты, автоматические продления ACME, сертификаты CDN, облачных балансировщиков и Kubernetes. Иначе монитор быстро утонет в легитимных событиях.
Если появляется действительно неизвестный сертификат, последовательность действий простая. Сначала проверить, не выпустила ли его другая команда или облачный сервис. Затем определить CA и изучить имена SAN. Если выпуск несанкционированный, обратиться к удостоверяющему центру за отзывом и одновременно проверить способ подтверждения домена, DNS, учётные записи регистратора, облачную инфраструктуру и секреты автоматизации. Сам факт отзыва устраняет сертификат, но не объясняет, как посторонний смог его получить.
Я бы поэтому не писал, что Certificate Transparency позволяет «убедиться, что никто не выпустил левый сертификат». CT даёт возможность увидеть зарегистрированный выпуск и заметить то, чего быть не должно. SCT подтверждает участие журналов, но не честность сертификата. CRLSet решает уже следующую задачу и помогает Chrome быстро блокировать часть известных проблемных сертификатов.
Хорошая модель защиты складывается из нескольких независимых слоёв. CA проверяет право на домен. Браузер проверяет цепочку и имя. CT делает выпуск наблюдаемым. Мониторинг замечает аномалии. Отзыв меняет статус скомпрометированного сертификата. CRLSet, CRLite и другие браузерные механизмы доставляют сведения об отзыве пользователям. Убрать любой слой можно, но тогда одна ошибка снова получает слишком большой шанс остаться незамеченной.
