Проверял, что видно про домен заказчика снаружи, и выписал имена из журналов Certificate Transparency. В списке оказались jenkins, gitlab-runner и пара стендов с именами вида test-2 — ни одного из них в публичном DNS не было.
Имя знает не только команда. Его знает весь интернет, причём с того момента, как вы выпустили на этот хост TLS-сертификат.
Как имя попадает в открытый реестр
Certificate Transparency — это система публичных журналов, куда попадает каждый выпущенный сертификат. Придумана она после нескольких случаев, когда удостоверяющие центры выпускали сертификаты на чужие домены: идея в том, чтобы владелец домена мог заметить такой выпуск, а не узнавать о нём от пострадавших.
Механика такая: Chrome с 30 апреля 2018 года требует, чтобы публично доверенный сертификат сопровождался SCT — подписанными отметками журналов о том, что сертификат в них принят. Apple включила аналогичное требование в Safari осенью 2018-го, Firefox — только в 2025-м, в версии 135. Нет отметок — Chrome и Safari показывают ошибку. То есть удостоверяющий центр вынужден публиковать сертификат, иначе тот бесполезен.
В журнал попадает precertificate — копия будущего сертификата, которую центр логирует до выпуска, чтобы получить отметки. Имена в ней те же самые: полный список поля SAN, тех самых имён, на которые вы сертификат и выпускали.
Журналы доступны любому. Запрос по домену возвращает всё, что когда-либо выпускалось на него и на его поддомены:
$ curl -s 'https://api.certspotter.com/v1/issuances?domain=example.com&include_subdomains=true&expand=dns_names' \ | jq -r '.[].dns_names[]' | sort -u
6 выпусков, 8 уникальных имён *.example.com *.int.example.com *.srv.example.com example.com int.example.com promo.example.com srv.example.com www.promo.example.com
В сыром виде интерфейс отдаёт JSON, здесь оставлены только имена. Тут владелец домена всё сделал правильно: наружу перечислены публичные сервисы, а внутренние зоны закрыты звёздочками — почему это важно, разберу ниже. Гораздо чаще вывод выглядит иначе:
vpn-test.example.com jenkins.example.com grafana.example.com staging-crm.example.com backup-old.example.com 1c-web.example.com kassa.example.com
Ни одного из этих имён нет в публичной зоне. Все они — в открытом журнале, навсегда.
Что из этого списка вычитывается
Стек и инструменты. jenkins, grafana, gitlab, 1c-web называют используемые продукты. Дальше уже известно, какие у них бывают типовые проблемы и какие версии считаются проблемными.
Забытое. backup-old, staging-crm, vpn-test — это хосты, которые заводили под задачу и не выключили. Обновляют их последними, а иногда не обновляют вовсе.
Схема именования. Увидев srv01 и srv04, легко предположить существование srv02 и srv03 — и проверить догадку тем же запросом к журналу, не трогая инфраструктуру вовсе.
Временная шкала. У каждой записи есть дата выпуска. Появление crm-new в апреле и исчезновение продлений у crm в июне — это история миграции, изложенная за вас. Компании и вовсе регулярно рассекречивают себя так: сертификат на домен нового сервиса выпускают до анонса, и по журналам название становится известно раньше, чем его назовёт маркетинг.
Важная особенность: журналы работают по принципу append-only — записи только дописываются в конец, а структура дерева подписей не даёт задним числом ничего убрать. Удалить запись нельзя ни отзывом сертификата, ни обращением в удостоверяющий центр, ни выключением хоста. Имя, попавшее в журнал однажды, остаётся в нём навсегда.
Автоматизация ситуацию усугубила. Раньше сертификат покупали, и на внутренний тестовый стенд его никто бы не стал тратить. Сейчас ACME-клиент выпускает сертификат на каждое имя сам, бесплатно и молча — и каждый такой выпуск публикуется.
Что делать
Wildcard вместо перечисления имён. Один сертификат *.int.example.com закрывает сколько угодно хостов первого уровня внутри зоны — a.int, b.int, но не a.b.int: звёздочка покрывает ровно одну метку. В журнал при этом попадает одна строка со звёздочкой. Именно это видно в выводе выше: наружу ушёл факт существования зоны int, а не список того, что в ней живёт.
Плата за это: один закрытый ключ обслуживает много хостов, и компрометация любого из них бьёт по всем сразу (если злоумышленник похитит закрытый ключ, то сможет выпускать сертификаты на любые поддомены, при этом ваши пользователи, заходя на такие поддомены, не будут видеть предупреждений, так как сертификат будет абсолютно валидным). Для внутреннего сегмента с одинаковым уровнем доверия размен обычно оправдан, для разнородного — нет.
Внутренний удостоверяющий центр для внутренних сервисов. Сертификат, выпущенный вашим собственным CA, в публичные журналы не попадает, потому что публичным доверием он не пользуется — при условии, что и корень у него свой. Приватный промежуточный CA, подписанный публично доверенным корнем, под требования прозрачности попадает наравне с обычным публичным сертификатом. Корневой сертификат раздаётся на рабочие устройства через групповые политики или MDM. Для контура, куда не ходят посторонние браузеры, это правильный вариант по умолчанию.
Перестать считать имя секретом. Хост, доступность которого держится на том, что о нём не знают, защищён ровно до первого выпуска сертификата. Проверка тут простая: если сервис нельзя выставить в интернет под известным именем, то и под неизвестным нельзя — значит, вопрос не в имени, а в аутентификации и в сетевом доступе.
Обратная сторона: журналы полезны и вам
Тот же механизм работает в вашу пользу, если за ним следить.
Подпишитесь на уведомления о новых сертификатах для своих доменов: бесплатные оповещения по почте даёт Cert Spotter от SSLMate, а разово посмотреть уже выпущенное удобно через crt.sh (но он в последнее время часто недоступен). В крупных инфраструктурах это обычно отдельная проверка в конвейере. Смотреть в них надо на два типа событий.
Первое — сертификат на ваш домен, который выпускали не вы. Это либо ошибка удостоверяющего центра, либо кто-то получил контроль над DNS или над содержимым сайта (закрытым ключом с сертификатом), достаточный для прохождения проверки ACME. Оба варианта требуют немедленной реакции.
Второе — сертификаты на имена, похожие на ваши: example-pay.com, exampl3.com, example.com.security-check.ru. Между выпуском такого сертификата и рассылкой обычно проходит от нескольких часов до нескольких дней: фишинговая страница должна открываться по HTTPS без предупреждений, а домену часто дают отлежаться. Это редкий случай, когда защищающаяся сторона узнаёт о подготовке заранее, — и один из немногих сигналов, по которому домен успевают отправить на разделегирование до начала рассылки, а не после.
Что посмотреть у себя
Выполнить запрос из начала статьи по своему основному домену. Читать вывод стоит с конца, от самых старых записей: там обычно и находится то, о существовании чего в компании уже забыли.
Найденное разделить на три части — то, что должно быть снаружи; то, что должно быть внутри и получило публичный сертификат по недосмотру; то, что вообще пора выключить. Третья часть, по моему опыту, оказывается самой большой.
