Сертификаты и Certificate Transparency

Каждый выпущенный TLS-сертификат попадает в публичный лог — и вместе с ним в открытый доступ утекают имена ваших поддоменов.

Certificate Transparency (CT) — система публичных, проверяемых, неизменяемых журналов, в которые удостоверяющие центры обязаны записывать каждый выпущенный TLS-сертификат.

CT придумали ради безопасности: чтобы любой мог обнаружить мошеннически выпущенный сертификат на чужой домен. Побочный эффект — мощнейший источник пассивной разведки. Как только вы выпускаете сертификат на secret-project.example.com, это имя навсегда оказывается в публичном логе. Защитник обязан читать эти логи раньше атакующего, чтобы знать полный список своих активов.

Зачем это знать защитнику

CT-логи — едва ли не лучший пассивный способ перечислить поддомены: без единого запроса к вашим серверам разведчик получает имена, которые вы нигде не публиковали, но «засветили» при выпуске сертификата. Тестовые стенды, внутренние панели, проекты «в разработке» — всё это раскрывается через CT. Поэтому CT-мониторинг — обязательная часть инвентаризации активов (asset management) и обнаружения теневого ИТ (shadow IT).

Как устроены CT-логи

Когда УЦ выпускает сертификат, он отправляет его в несколько независимых логов и получает SCT (Signed Certificate Timestamp) — подписанное обещание, что сертификат записан. Браузеры (Chrome, Safari) требуют валидные SCT, иначе считают сертификат недоверенным. Логи устроены как append-only Merkle-деревья: записи нельзя удалить или подменить незаметно. Это гарантирует прозрачность, но и означает, что имя из сертификата нельзя «отозвать» из публичности.

Что именно утекает

В сертификате публичны: основное имя (CN) и список SAN (Subject Alternative Names) — все домены и поддомены, на которые он выписан, даты выпуска и истечения, удостоверяющий центр. Особенно «болтливы» wildcard- и многодоменные сертификаты, а также практика выписывать отдельный сертификат на каждый сервис.

Subject: CN=example.com
Subject Alternative Names:
  example.com
  www.example.com
  api.example.com
  staging.example.com      <-- утечка тестового стенда
  internal-tools.example.com  <-- утечка внутренней панели
Not Before: 2026-01-15
Not After:  2026-04-15
Issuer: Let's Encrypt

Как читать CT для самоаудита

Публичные интерфейсы поиска по CT (например, агрегаторы CT-логов) позволяют выгрузить все сертификаты по вашему домену. Удобно автоматизировать через API и сводить в список уникальных имён:

# Запросить CT-агрегатор по своему домену и вытащить уникальные имена:
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].name_value' \
  | tr ',' '\n' \
  | sed 's/^\*\.//' \
  | sort -u

Получив список, защитник сверяет его с реестром известных активов: каждое имя должно соответствовать ресурсу, который вы признаёте своим и держите под контролем. Незнакомые имена — повод для расследования: либо забытый сервис, либо теневой проект, либо (редко) попытка выпустить сертификат на ваш бренд.

Как это работает под капотом

Каждый лог — это сервер с криптографически связанным журналом. Новая запись добавляет лист в Merkle-дерево, а корневой хеш периодически подписывается (Signed Tree Head). Любой наблюдатель может скачать записи и математически убедиться, что журнал не переписывали. Именно неизменяемость делает CT надёжным для обнаружения мисью-выпуска — и одновременно означает, что опубликованное имя остаётся публичным навсегда. Отсюда главный вывод для защиты: то, что попадёт в SAN, скрыть уже нельзя, поэтому думать о приватности нужно до выпуска сертификата.

Как защититься

Мониторьте CT-логи на свои домены. Настройте регулярный сбор по %.example.com и алерт на любое новое имя. Так вы первыми узнаёте и о новых поддоменах, и о попытках мисью-выпуска на ваш бренд.
Не светите внутренние имена. Для строго внутренних сервисов используйте приватный УЦ (внутренний PKI) — такие сертификаты не попадают в публичные CT-логи. Публичный сертификат = публичное имя.
Применяйте wildcard осознанно. *.example.com не раскрывает конкретные поддомены в SAN — это снижает утечку имён, но требует аккуратного хранения приватного ключа (один ключ на много сервисов).
Включите CAA-записи. DNS-запись CAA ограничивает, какие УЦ вправе выпускать сертификаты на ваш домен, — это снижает риск мисью-выпуска злоумышленником.
Ведите реестр активов. Сверяйте имена из CT со списком известных сервисов; всё незнакомое — расследуйте и закрывайте.

Правовая рамка: чтение публичных CT-логов полностью законно — это открытые данные. Незаконным становится последующее действие: попытка получить доступ к найденному чужому сервису. Используйте CT-разведку только для инвентаризации своей или разрешённой инфраструктуры.

Итоги

Каждый публичный TLS-сертификат навсегда попадает в неизменяемые CT-логи вместе со всеми именами из SAN.
CT — лучший пассивный способ перечислить поддомены: имена утекают без единого запроса к вашим серверам.
Скрыть имя после выпуска нельзя — приватность нужно планировать до выпуска сертификата.
Защита: мониторинг CT на свои домены, приватный PKI для внутренних сервисов, CAA-записи и реестр активов.