Certificate Transparency на практике: SCT и оповещения

Коротко. Certificate Transparency (CT, RFC 6962) обязывает центры сертификации (CA) отправлять каждый публично доверенный TLS-сертификат в публичные журналы, куда записи можно только добавлять. Каждый журнал возвращает подписанное обещание включить сертификат — SCT, и CA встраивает полученные SCT в сертификат. Chrome, Safari и Firefox отклоняют публично доверенные сертификаты, если в них недостаточно SCT от достаточного числа независимых журналов. Для вас это означает две вещи. Во-первых, любой может увидеть все сертификаты, выпущенные для ваших доменов, — через Cert Spotter, crt.sh или собственный монитор. Во-вторых, вам следует отслеживать эти журналы: сертификат, который вы не запрашивали, — самый ранний признак захвата DNS, взлома учётной записи или неправильной работы CA.

Как работает CT

Журнал CT — это дерево Меркла, та же структура из хешей, допускающая только добавление, что используется в Git и Bitcoin. Любой может скачать журнал, убедиться, что записи из него никогда не удаляются и не меняются, и получить короткое доказательство того, что конкретный сертификат в него включён. Выпуск сертификата с CT происходит так:

1. CA собирает предсертификат: содержимое итогового сертификата плюс критическое poison-расширение (OID 1.3.6.1.4.1.11129.2.4.3), из-за которого его нельзя использовать как настоящий сертификат.
2. CA отправляет предсертификат в несколько журналов. Каждый журнал возвращает подписанную метку времени сертификата (Signed Certificate Timestamp, SCT) — подпись записи вместе с меткой времени. Это обещание включить запись в журнал в пределах его максимальной задержки слияния (Maximum Merge Delay, MMD).
3. CA выпускает итоговый сертификат, встроив SCT в расширение X.509 (OID 1.3.6.1.4.1.11129.2.4.2).
4. Браузеры проверяют подписи SCT по своему списку доверенных журналов и сверяют их количество со своей политикой.
5. Мониторы читают журналы и сообщают о сертификатах для отслеживаемых имён. Аудиторы проверяют, что журналы остаются согласованными и выполняют свои обещания.

В большинстве случаев в журналы попадают и предсертификат, и итоговый сертификат, поэтому поисковые сервисы часто показывают каждый сертификат дважды.

SCT в настоящем сертификате

openssl x509 -text декодирует встроенные SCT. Вот сертификат, полученный от letsencrypt.org 20 октября 2026 года:

subject=CN=letsencrypt.org
issuer=C=US, O=Let's Encrypt, CN=YE2
notBefore=Sep  4 14:34:32 2026 GMT
notAfter=Dec  3 14:34:31 2026 GMT
            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : D8:09:55:3B:94:4F:7A:FF:C8:16:19:6F:94:4F:85:AB:
                                B0:F8:FC:5E:87:55:26:0F:15:D1:2E:72:BB:45:4B:14
                    Timestamp : Sep  4 15:33:02.377 2026 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:46:02:21:00:D0:2E:25:A4:9D:7F:C8:18:D6:7B:5E:...
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 46:AF:86:3D:3B:3E:E5:9F:A5:77:DE:A8:24:5D:36:B0:
                                D9:ED:22:A2:23:F4:61:77:41:22:94:52:EE:95:50:5F
                    Timestamp : Sep  4 15:33:02.552 2026 GMT
                    Extensions: 00:00:05:00:24:DF:DB:0C
                    Signature : ecdsa-with-SHA256
                                30:44:02:20:31:2F:83:D6:42:65:26:0D:58:D7:DD:C3:...

ID журнала — это хеш SHA-256 открытого ключа журнала. Если найти оба ID в списке журналов Chrome (log_list.json, версия от 19 октября 2026 года), получится вот что:

Два журнала от двух разных операторов — минимум для 90-дневного сертификата. Расширение во втором SCT — не мусор. Журналы, работающие по static-ct-api, записывают в SCT позицию записи в журнале: тип расширения 0 (leaf_index), длина 5 и 40-битный индекс, здесь 618 650 380. Монитор может получить эту запись напрямую, а не искать её.

Декодер SCT выполняет этот поиск за вас. Он показывает название каждого журнала, его состояние в списках Chrome и Apple и то, удовлетворяет ли набор SCT политике каждого браузера. Декодер сертификатов показывает расширение с SCT вместе с остальным содержимым сертификата.

SCT могут попасть в браузер тремя способами:

• Встроенными в сертификат, как в примере выше. Так делают почти все CA, и от вас это ничего не требует.
• В TLS-расширении signed_certificate_timestamp. Сервер отправляет SCT, которые получил сам. Это поддерживают немногие серверы.
• В прикреплённом ответе OCSP (stapling). Chrome принимал такие SCT только «в версиях до версии 148», а поскольку Let's Encrypt и другие CA отказываются от OCSP, этот путь уходит в прошлое (см. OCSP и CRL в 2026 году).

Что требуют браузеры

Все три основных браузерных движка требуют CT для сертификатов от CA, входящих в их публичные программы корневых сертификатов.

Источники: политика CT в Chrome, политика CT Apple (апрель 2025 года) и страница о CT Mozilla. По данным MDN, Firefox требует CT на десктопе с версии 135 (февраль 2025 года), а на Android — с версии 145 (ноябрь 2025 года). Параметр security.pki.certificate_transparency.mode показывает режим: значение 2 означает, что проверка CT обязательна.

Два практических следствия:

• Браузеры перестают требовать CT, если их список журналов слишком устарел. Chrome требует CT, только пока его самому свежему списку журналов меньше 70 дней, а список Firefox устаревает через 10 недель. На машине, которая не обновлялась месяцами, требование CT вообще не действует, поэтому не тестируйте на ней ошибки CT.
• На частные CA требование не распространяется. В заметках для организаций Chrome сказано, что CT «применяется только к публично доверенным CA». Сертификатам от корневого сертификата, который вы установили сами, SCT не нужны, да и журналы их всё равно не примут.

Сами журналы

В списке журналов Chrome от 19 октября 2026 года значится 21 журнал RFC 6962 в состоянии usable, а также 2 — в состоянии read-only и 3 — в состоянии retired. Кроме того, в нём 22 журнала static-ct-api в состоянии usable и 37 — в состоянии qualified. Журналы в состоянии usable или qualified ведут 11 операторов: Cloudflare, DigiCert, Geomys, GoDaddy, Google, HARICA, IPng Networks, Let's Encrypt, Microsec, Sectigo и TrustAsia. Журналы разбиты на шарды по времени. Журнал с именем 2026h2 принимает только сертификаты, срок действия которых истекает во втором полугодии 2026 года. Так размер каждого журнала остаётся ограниченным, а сам журнал можно вывести из эксплуатации, когда срок действия его сертификатов истечёт.

Журналы обоих типов принимают сертификаты через одни и те же эндпоинты RFC 6962 (add-chain, add-pre-chain). Различаются они тем, как их читают мониторы. Журнал RFC 6962 отвечает на динамические вызовы API:

{"tree_size":2980148930,"timestamp":1792499093002,"sha256_root_hash":"wr3F5apMl2E7wQHqbAA1yKsqaZbAzBXTT8WTAeRAy8M=","tree_head_signature":"BAMARzBFAiEAsC3Pr7fsPwy0vchrMDIXka7HxrZANu5tcXclDCUqqSYCIGJ64SaIT0tjM5hCGfycNGPfu6FP8q8RvW14Q4SoyvVU"}

Это почти три миллиарда записей в одном шарде за полгода. Журнал static-ct-api («тайловый», tiled) публикует подписанную вершину дерева (signed tree head) в виде текстовой контрольной точки (checkpoint), а записи — в виде неизменяемых тайлов по 256 записей, которые можно кешировать в CDN:

tuscolo2026h2.sunlight.geomys.org
1007870339
aRhh7dPjYarH0itUM1LD+XJw7CW41z1+9tSnf3AizuY=

— tuscolo2026h2.sunlight.geomys.org W+DWDWi4dqCfFx8da0IS4+jwHKVL6ETEHGQCHn5y8rKflUhLRtLHQ3c6...
— grease.invalid Aui1jDc8Y7Uve7seHd/Pg1p+wHSUmw0+MTNyEKEAAbHaE5bY3Gi/MUZ3zBuk+NxUyhJL...
— tuscolo2026h2.sunlight.geomys.org 7BiSLwAAAaFZRnbMBAMARzBFAiA++3wWdtsK2H8l3IxZh6H/OQml...

Первые строки — это origin, размер дерева и корневой хеш. Строки, начинающиеся с «—», — подписи. Обратите внимание: URL для мониторинга (skylight) отличается от URL для отправки сертификатов (sunlight). Оба указаны в списке журналов.

Как найти свои сертификаты

Два публичных поисковых сервиса охватывают практически все журналы.

Cert Spotter API (SSLMate). Эндпоинт issuances возвращает сертификаты домена, срок действия которых ещё не истёк. Без ключа можно сделать ограниченное число запросов в час. Для работы в продакшене SSLMate просит зарегистрироваться и получить ключ. Вот сертификаты для ecdsa.com:

curl -s "https://api.certspotter.com/v1/issuances?domain=ecdsa.com&include_subdomains=true&expand=dns_names&expand=issuer"

{
  "id": "16609031524",
  "tbs_sha256": "8c6f1f0bef5434da2012d5f29eab13f00bcec659f17832c07872ff600f61ecf5",
  "cert_sha256": "1396447e3454a081fe4e48dc1d5de18b7e3cf857ec1d7ff3c987d091c9024b04",
  "dns_names": [
    "ecdsa.com"
  ],
  "pubkey_sha256": "9a1fa381dad4630b83cf3a1a1a7a3da7f04577db8a41933dd9bac49dabfa8c29",
  "issuer": {
    "friendly_name": "Let's Encrypt",
    "pubkey_sha256": "2e8307068b6db620e4a39d068b5dee5d6ef5788cbb2c0b6d23ead84fcc17178c",
    "name": "C=US, O=Let's Encrypt, CN=YR1"
  },
  "not_before": "2026-08-19T14:52:58Z",
  "not_after": "2026-11-17T14:52:57Z",
  "revoked": false
}

Всего в ответе было 5 выпусков; вот они в сжатом виде:

16609031524 2026-08-19 2026-11-17 Let's Encrypt ecdsa.com
16609045002 2026-08-19 2026-11-17 Let's Encrypt ecdsa.com,www.ecdsa.com
17525925247 2026-10-01 2026-12-30 Let's Encrypt *.ecdsa.com,ecdsa.com
17875915585 2026-10-19 2027-01-17 Let's Encrypt ecdsa.com,www.ecdsa.com
17878726033 2026-10-20 2027-01-18 Let's Encrypt ecdsa.com

Результаты идут в том порядке, в котором их обнаружил SSLMate. Чтобы получить следующую страницу, передайте последний id в параметре after=. Пустой массив приходит с заголовком Retry-After, поэтому эндпоинт можно опрашивать как ленту новых выпусков. Обратите внимание, что даёт поле pubkey_sha256: если сравнить его с ключами ваших серверов, станет видно, какие сертификаты действительно развёрнуты, а какие были выпущены и так и не использовались.

У crt.sh (Sectigo) есть веб-интерфейс и вывод в JSON (https://crt.sh/?q=example.com&output=json). Сервис бесплатный и хранит очень длинную историю, включая сертификаты с истёкшим сроком действия. Но это ещё и сильно загруженный общий сервис: 20 октября 2026 года все 4 наших JSON-запроса вернули 502 Bad Gateway. Считайте его удобным дополнением, а не зависимостью вашего мониторинга.

Инструмент истории CT показывает сертификаты домена во времени: издателя, срок действия и имена каждого из них.

Мониторинг своих доменов

Поиск отвечает на вопрос «что уже есть?», а мониторинг — на вопрос «что появилось нового?» и оповещает вас в течение минут или часов после выпуска. Варианты:

• Готовый сервис мониторинга. Cert Spotter в виде сервиса от SSLMate и личные кабинеты нескольких CA присылают письма или вебхуки о новых сертификатах для ваших доменов.
• certspotter с открытым исходным кодом (v0.25.0, сентябрь 2026 года) сам читает журналы. Вы перечисляете имена в ~/.certspotter/watchlist (точка в начале охватывает все поддомены, например .example.com), а он при каждом совпадении отправляет вам письмо или запускает скрипты из ~/.certspotter/hooks.d. Начиная с v0.24 в нём есть ещё и certspotter-authorize: эта команда помечает ожидаемые сертификаты, чтобы оповещения приходили только о неожиданных.
• Поисковый API как лента. Опрашивайте эндпоинт issuances в Cert Spotter с параметром after= и сравнивайте каждый новый сертификат с тем, что выпустила ваша автоматизация.

О чём оповещать:

1. Издатель, которым вы не пользуетесь. Сверяйтесь со своими записями CAA. Сертификат от CA, которому ваши записи CAA запрещают выпуск, — это инцидент на стороне CA, и о нём обязательно нужно сообщить этому CA.
2. Незнакомые имена, особенно забытые поддомены. Сертификат для old-campaign.example.com может означать, что кто-то захватил висячую DNS-запись.
3. Открытый ключ, которого вы не создавали, для имени, которым управляет ваша автоматизация.
4. Wildcard-сертификаты, если ваша политика их не предусматривает.

С 47-дневными сертификатами легитимные выпуски становятся частыми. Без certspotter-authorize или сверки с записями вашего ACME-клиента усталость от оповещений приведёт к тому, что вы пропустите тот единственный сертификат, который действительно важен.

CT и внутренние имена

Всё, что есть в публично доверенном сертификате, публикуется, причём навсегда: каждое имя из списка SAN. Внутренние имена хостов вроде jenkins.corp.example.com или staging-payments.example.com становятся публичными в тот момент, когда вы получаете для них публичный сертификат, и их видит любой, кто читает журналы, в том числе те, кто ищет цели для атак. Варианты из заметок Chrome для организаций и общепринятой практики:

• Используйте частный CA для внутренних имён. Требования CT на него не распространяются, и ничего не публикуется.
• Используйте wildcard-сертификат (*.corp.example.com), если без публичного сертификата не обойтись. Он раскрывает зону, но не каждый хост.
• Не рассчитывайте на то, что можно попросить публичный CA не отправлять сертификат в журналы. Такой сертификат не будет работать ни в одном браузере, который требует CT.

Частые ошибки

• SCT как доказательство включения. SCT — это обещание включить запись в журнал в пределах MMD. Аудиторы и мониторы проверяют, что журналы это обещание выполняют.
• Подсчёт дубликатов. Записи предсертификата и сертификата одного и того же выпуска в большинстве поисковых сервисов выглядят как две строки. У них совпадают издатель и серийный номер, поэтому перед подсчётом сертификатов убирайте дубликаты по этой паре.
• Поиск сведений об отзыве в CT. Отозванный сертификат навсегда остаётся в журнале. Отзыв — отдельная система.
• Проверка требований CT в старом браузере. Браузер сам перестаёт требовать CT, когда его список журналов устаревает.
• Мониторинг только через один бесплатный сервис. crt.sh бывает недоступен. Используйте второй источник или собственный монитор.

Источники

• RFC 6962: Certificate Transparency (предсертификаты, SCT, API журналов). RFC 9162 описывает версию CT 2.0, которую браузеры не используют.
• static-ct-api: API чтения тайловых журналов и расширение leaf_index.
• Политика CT в Chrome, список журналов Chrome, CT для организаций.
• Политика Certificate Transparency Apple и список журналов.
• MDN: Certificate Transparency, страница о Certificate Transparency Mozilla и примечания к выпуску Firefox 135.
• SSLMate: Cert Spotter API и certspotter на GitHub.

Вывод команд получен 20 октября 2026 года с OpenSSL 3.5.7 и curl 8.14.1 в node:24.22.0-trixie.