Certificate Transparency (CT)

Certificate Transparency (RFC 9162) — публичные append-only логи всех выданных TLS-сертификатов. Придумал Google в 2013 после случая с DigiNotar (мошеннически выданные серты на google.com).

С 2018 Chrome (и большинство браузеров) требуют: если серта нет в двух CT-логах — он невалидный. Это заставляет все CA публиковать каждый выданный серт.

Как устроено

1. CA выпускает серт.
2. Одновременно шлёт precert (специальную версию) в 2+ CT-логов.
3. Логи возвращают SCT (Signed Certificate Timestamp) — подписанное «мы получили и обещаем опубликовать в течение MMD (Maximum Merge Delay, обычно 24 часа)».
4. CA вклеивает SCT в финальный серт (в extension или через OCSP-stapling / TLS extension).
5. Браузер при подключении проверяет: SCT есть? логи подписи знают? — тогда серту доверяет.

Структура лога — Merkle tree. Каждая новая запись добавляет лист, корень хеша обновляется. Из-за append-only + доказательств Меркла, лог не может «забыть» уже выданный серт без обнаружения.

Основные логи

Chrome требует SCT минимум из 2 разных операторов.

Мониторинг CT

Любой может смотреть логи и искать серты по своим доменам. Так ты узнаешь если кто-то выпустил серт на твой домен без ведома.

• crt.sh — search UI по всем логам.
• CertStream — websocket-поток всех новых сертов в реальном времени.
• Cert Spotter — сервис нотификаций.
• Facebook CT tool.

Что даёт CT

• Аудит. Если CA выпустил левый серт — он засветится в логе, будет скандал, CA лишится доверия (реальные примеры: WoSign, Symantec, Camerfirma — все умерли).
• Мониторинг. Ты как владелец домена видишь все свои серты + серты «на твой домен» от чужих CA.
• Раскрытие субдоменов. Побочный эффект: все серты публичны, включая для внутренних субдоменов (internal-admin.corp.example.com). Bug bounty hunters этим пользуются.

Обход раскрытия субдоменов

• Wildcard-серт *.example.com — не палит конкретные субдомены.
• Redacted labels (deprecated в RFC 9162, но исторически): ?.example.com.

См. также

• TLS, HTTPS
• CAA, OCSP, CRL, Pinning, DANE