Certificate Transparency: почему внутреннее имя может навсегда попасть в открытый доступ
Проверка внешнего периметра иногда выявляет больше, чем публичный DNS. В журналах Certificate Transparency могут обнаружиться имена Jenkins, GitLab Runner, Grafana, тестовых стендов и резервных серверов, хотя в открытой DNS-зоне их никогда не было.
Причина проста: имя становится публичным в момент выпуска сертификата, а не после появления DNS-записи.
Как внутренний хост попадает в CT-журналы
Certificate Transparency - это система открытых журналов, в которых фиксируются сертификаты, выпущенные доверенными удостоверяющими центрами. Механизм появился после случаев ошибочной или злоумышленнической выдачи сертификатов на чужие домены. Идея заключается в том, чтобы владелец домена мог самостоятельно заметить подозрительный выпуск.
Современные браузеры требуют, чтобы публично доверенный сертификат сопровождался SCT - подписанными подтверждениями его регистрации в CT-журналах. Chrome применяет это требование с 30 апреля 2018 года, Safari - с осени того же года, а Firefox подключил аналогичную проверку в версии 135, выпущенной в 2025 году. Без необходимых отметок сертификат может считаться недействительным, поэтому удостоверяющий центр вынужден заранее отправлять сведения в журналы.
Обычно туда попадает precertificate - предварительная версия будущего сертификата. Она содержит те же доменные имена, что и итоговый документ, включая полный список значений поля SAN. Именно SAN часто становится источником утечки: если туда добавить `jenkins.int.example.com`, это имя окажется доступным для поиска любому человеку.
При этом DNS-запись для такого адреса может отсутствовать полностью. Сертификат могли выпустить заранее, когда сервис ещё не опубликован, либо имя могло использоваться только во внутренней сети.
Что можно узнать из открытых записей
Запрос по домену и его поддоменам способен показать историю выпуска сертификатов. Из неё извлекаются не только имена, но и косвенные сведения об инфраструктуре.
Используемые технологии
Названия вроде `jenkins`, `gitlab`, `grafana`, `1c-web`, `vpn` или `kibana` позволяют предположить, какие продукты применяются в компании. После этого становится проще определить типовые точки входа, известные уязвимости и потенциально проблемные версии.
Заброшенные и временные узлы
Имена `backup-old`, `staging-crm`, `vpn-test` или `dev-legacy` нередко принадлежат временным системам, которые забыли отключить. Такие серверы часто обновляют по остаточному принципу, а контроль доступа к ним слабее, чем у производственных сервисов.
Логику внутренней адресации
Если в журнале встречаются `srv01` и `srv04`, можно предположить существование `srv02` и `srv03`. Аналогично, по `test-2` иногда удаётся восстановить целую серию стендов. Для такой гипотезы не требуется отправлять запросы во внутреннюю сеть - достаточно анализа уже опубликованных данных.
Историю изменений
Дата выпуска сертификата помогает восстановить развитие инфраструктуры. Появление `crm-new` весной и прекращение продления сертификата для `crm` несколькими месяцами позже может указывать на миграцию. Новые проекты также нередко становятся видны в CT-журналах ещё до официального запуска.
Почему удалить имя уже нельзя
Публичные CT-журналы устроены по принципу append-only: записи добавляются, но не редактируются и не удаляются. Их целостность подтверждается криптографической структурой дерева подписей.
Отзыв сертификата не стирает факт его выпуска. Обращение в удостоверяющий центр также не удалит имя из исторической записи. Даже если сервер выключен, DNS-зона удалена, а проект закрыт, доменное имя останется доступным в архивах навсегда.
Именно поэтому ошибочный выпуск сертификата на внутреннее имя нельзя рассматривать как кратковременную утечку. Это постоянное раскрытие элемента внутренней структуры.
Wildcard-сертификат как способ сократить раскрытие
Один из вариантов уменьшить объём информации - использовать wildcard-сертификат. Например, сертификат `*.int.example.com` подходит для `jenkins.int.example.com`, `grafana.int.example.com` и других хостов первого уровня.
В журнале в таком случае публикуется одна wildcard-запись, а не перечень конкретных серверов. Однако звёздочка покрывает только один уровень: `*.int.example.com` подходит для `a.int.example.com`, но не для `api.dev.int.example.com`.
Такой подход скрывает список отдельных машин, но всё равно раскрывает факт существования внутренней зоны `int.example.com`.
У wildcard есть и существенный недостаток - общий закрытый ключ. Если злоумышленник получит его на одном из обслуживаемых узлов, под угрозой окажутся все остальные хосты, использующие тот же сертификат. Для сегмента с одинаковым уровнем доверия это может быть приемлемым компромиссом, но объединять таким образом разнородные системы не стоит.
Внутренний удостоверяющий центр
Для непубличных сервисов лучше применять собственный корпоративный CA. Сертификаты, выпущенные внутренним удостоверяющим центром, не должны попадать в публичные журналы CT, поскольку не предназначены для доверия со стороны общего интернета.
Этот вариант требует предварительно установить корневой сертификат на рабочие станции, серверы и мобильные устройства организации. Зато внутренние имена не публикуются, а компания получает централизованный контроль над выдачей, сроками действия и отзывом сертификатов.
Важно разделять публичные и внутренние пространства имён. Публичный сертификат не следует использовать только потому, что он бесплатен и автоматически выпускается через ACME. Для внутренней зоны правильнее настроить ACME-сервер внутри организации или использовать другой механизм автоматической выдачи сертификатов на базе собственного CA.
Как автоматизация увеличила риск
Раньше выпуск сертификата стоил денег и требовал ручных действий. Поэтому оформлять отдельный документ для временного стенда мало кто стал бы. Сегодня ACME-клиенты способны выпускать сертификаты автоматически, быстро и бесплатно. Это удобно, но каждое такое действие может приводить к публикации имени в CT.
Особенно опасны шаблоны автоматизации, которые без проверки добавляют в SAN все найденные DNS-имена. В результате в журнале оказываются не только production-хосты, но и временные стенды, технические алиасы, имена из заявок и случайные записи из конфигурационных файлов.
Что проверить у себя
Начать стоит с инвентаризации доменных имён, которые когда-либо использовались в сертификатах. Нужно сопоставить найденные записи с актуальными DNS-зонами, CMDB, системами мониторинга и реестром серверов.
Отдельно следует проверить:
- сертификаты, содержащие внутренние имена;
- wildcard-сертификаты и область их применения;
- старые записи, которые больше не продлеваются;
- названия тестовых и резервных серверов;
- повторное использование одного закрытого ключа;
- автоматические задания ACME;
- наличие внутренних CA для непубличных сервисов;
- права доступа к каталогам с ключами и сертификатами.
Полезно настроить регулярный мониторинг CT-журналов. Новое имя, выпущенный сертификат или неожиданный центр сертификации должны автоматически попадать на проверку ответственной команде.
Как не допустить повторения
Перед выпуском публичного сертификата нужно фильтровать список SAN и исключать все внутренние, временные и служебные имена. Для внешних сервисов следует использовать понятную модель именования, не раскрывающую лишние детали: например, не включать в публичное имя номер стойки, роль узла или название закрытого проекта.
Тестовые среды лучше размещать в отдельной доменной зоне и обслуживать внутренним CA. Если сервис должен быть доступен только сотрудникам, одного отсутствия DNS-записи недостаточно: необходимо дополнительно ограничить сетевой доступ, настроить аутентификацию и исключить случайную выдачу публичного сертификата.
Certificate Transparency полезно воспринимать не только как канал утечки, но и как инструмент контроля. Те же журналы позволяют владельцу домена обнаружить несанкционированный выпуск сертификата, забытый стенд или ошибку в автоматизации. Регулярная проверка помогает увидеть проблему до того, как ею воспользуются извне.