Поиск по журналам сертификатов

Реестр, который может прочитать любой

Сертификат TLS выпускает удостоверяющий центр (CA), а браузер доверяет любому сертификату, подписанному любым из примерно сотни центров в его списке. Годами это означало, что один небрежный или взломанный центр мог выпустить действующий сертификат для домена вашего банка, и никто бы этого не заметил.

Certificate Transparency (CT) закрывает эту брешь. Центры обязаны отправлять каждый сертификат в публичные журналы, куда можно только дописывать, и с апреля 2018 года Chrome отклоняет сертификаты без доказательства записи в журнал. Safari применяет то же правило. Журналы ведут такие компании, как Google, Cloudflare, DigiCert, Sectigo и Let’s Encrypt, и искать в них может любой.

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

Что поиск делает с журналом

Мы запрашиваем crt.sh, публичный индекс журналов CT, по зарегистрированному домену и всему, что под ним. Результаты хранятся один час. Затем мы обрабатываем их так:

• Каждый сертификат считается один раз. Каждый выпуск появляется в журналах дважды, как предсертификат и как итоговый сертификат. Записи с одинаковым издателем и серийным номером объединяются.
• Поддомены собираются из имён в каждом сертификате и сортируются по дате их последнего сертификата. Wildcard-имена вроде *.example.com выводятся отдельно.
• 40 самых свежих имён разрешаются в DNS, чтобы проверить, ведут ли они ещё куда-нибудь.
• Издатели подсчитываются, всего и за последние 90 дней, и сравниваются с вашей записью CAA, если вы её публикуете.

Когда у домена очень длинная история, crt.sh возвращает только её часть или не успевает ответить. Страница сообщает, когда это случается, и переходит к сертификатам, которые ещё действуют.

Висячие CNAME и захват поддомена

Допустим, status.example.com когда-то был CNAME на example.herokuapp.com. Кто-то удалил приложение и забыл про запись DNS. Теперь псевдоним указывает на имя, которое свободно для регистрации, и любой, кто создаст приложение с этим именем на той же платформе, получит трафик вашего поддомена. Дальше он может показывать страницу входа под вашим доменом и получить для неё действующий сертификат.

Столбец статуса показывает, что DNS говорит сегодня.

Разрешается

У имени есть адрес. Делать ничего не нужно.

Цель исчезла (красный)

CNAME на платформу, которая, как известно, позволяет занимать брошенные имена, например GitHub Pages, Heroku, Azure, Amazon S3, Netlify или Shopify, и цель возвращает NXDOMAIN. Считайте это срочным.

Цель исчезла (жёлтый)

Та же ситуация с сервисом, который мы не знаем.

Исчез / Нет адреса

Самого поддомена больше нет. Это безвредно, хотя его имя остаётся в журналах.

Исправление занимает один шаг. Удалите запись CNAME или заново создайте ресурс на платформе, если поддомен ещё нужен. И впредь делайте «удалить запись DNS» частью закрытия любого размещённого сервиса.

Как читать таблицу издателей

У большинства доменов один-два центра. Let’s Encrypt и Google Trust Services встречаются часто, потому что хостинги и CDN запрашивают у них сертификаты автоматически. Издатель помечается как Необычный в двух случаях. Либо он выпускал сертификаты за последние 90 дней и отсутствует в вашей записи CAA, либо записи CAA у вас нет, а на его долю приходится не больше двух сертификатов на домене, у которого их десять или больше.

Необычный не значит враждебный. Подключение CDN, конструктора сайтов или нового сервиса посадочных страниц часто приводит за собой новый центр. Спросите того, кто управляет этими сервисами. Если никто не может объяснить сертификат, найдите его серийный номер по ссылке на crt.sh в последней таблице и попросите этот центр его отозвать.

Чтобы впредь ограничить, кто может выпускать сертификаты, опубликуйте записи CAA, в которых названы только те центры, которыми вы пользуетесь:

example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 issue "pki.goog"