Инвентаризация SSL: два просроченных и один с чужим CN

В начале июня в нескольких публикациях по информационной безопасности всплыла история с Comodo и рядом промежуточных CA: у некоторых центров сертификации процедура верификации домена при выдаче сертификата оказалась, мягко говоря, нестрогой. Подробности ещё разбирались, но сам факт того, что CA могут выдавать сертификаты без должной проверки CN, - не гипотетический.

Мы как раз вели проект у одного из клиентов - небольшая производственная компания, несколько внутренних веб-сервисов и корпоративная почта на Exchange. Воспользовались поводом и добавили в работу инвентаризацию SSL. Ожидали найти что-то вроде «один сертификат, всё ок». Нашли три проблемы.

Как делали инвентаризацию

Никакого специального инструментария здесь не нужно. Мы прошли по списку внутренних сервисов, которые клиент вёл в таблице (актуальной - отдельное достижение), и для каждого HTTPS-эндпоинта посмотрели сертификат: срок, CN, цепочку до корневого CA, алгоритм подписи. Где-то openssl s_client, где-то браузер с раскрытием деталей сертификата, для почтового сервера - отдельная проверка через командную строку.

Заняло полдня. Список сервисов был не гигантским: корпоративный портал на IIS, Exchange OWA, внутренний gitlab (тогда ещё не gitlab, самописный git-хостинг), VPN-концентратор, несколько служебных веб-интерфейсов сетевого железа.

Что нашли

Два просроченных сертификата. Оба - на внутренних сервисах, к которым обращаются только из локальной сети. Один просрочен на три месяца, второй - на восемь. Браузеры ругались, но пользователи давно привыкли нажимать «продолжить» и не думать. Это само по себе проблема: когда люди приучены игнорировать предупреждения безопасности в браузере, ценность этих предупреждений обнуляется. Придёт когда-нибудь настоящее предупреждение - его тоже проигнорируют.

Сертификаты были самоподписанными, выданными корпоративным CA, который настроили несколько лет назад и забыли. Сам CA работал, просто никто не следил за сроками.

Один сертификат с некорректным CN. Это интереснее. На VPN-концентраторе стоял сертификат с CN, который не совпадал с реальным именем хоста, по которому к нему обращались клиенты. Обращение шло по внутреннему DNS-имени vpn.company.local, а в сертификате был прописан gateway.company.local - имя, которое когда-то использовалось до переименования сервера.

Технически это означает: клиент при установке VPN-соединения получает предупреждение о несоответствии имени. Большинство VPN-клиентов на тот момент либо пропускали это молча, либо давали предупреждение, которое пользователь принимал. Злоумышленник в локальной сети мог подсунуть сертификат с таким же «левым» CN - и отличить от легитимного стало бы нечем.

Корневой CA не распределён на все машины. Внутренний CA был добавлен в доверенные на машинах домена через групповую политику - это нормально. Но несколько рабочих станций, которые вводили в домен «вручную» без перезагрузки и применения политик, корневой сертификат не получили. Они получали красный экран на всех внутренних HTTPS-сервисах и привыкли к этому.

Почему это не «просто формальность»

Просроченный сертификат в изолированной внутренней сети - это не дыра в периметре, это другое. Он сигнализирует об отсутствии процесса: никто не следит, никто не уведомляет, никто не обновляет. Если процесса нет для сертификатов - с высокой вероятностью его нет и для чего-то другого.

Сертификат с неверным CN на VPN - это уже техническая проблема. Он делает проверку подлинности сервера бессмысленной: пользователь не может убедиться, что он говорит именно с корпоративным VPN-концентратором, а не с чем-то, что его изображает.

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

Что сделали

Порядок действий оказался несложным:

• Перевыпустили оба просроченных сертификата - корпоративный CA работал, операция заняла час.
• Перевыпустили сертификат для VPN с правильным CN, совпадающим с актуальным DNS-именем. Заодно проверили, что имя прописано в DNS и разрешается корректно с клиентских машин.
• Принудительно применили групповую политику на машинах, которые не получили корневой CA. Несколько машин пришлось перезагрузить.
• Сделали таблицу всех внутренних сертификатов с датами истечения и назначили ответственного за отслеживание. Занесли напоминания в календарь за месяц до каждого истечения.

Последнее - самое важное. Перевыпустить сертификат несложно. Сложнее не забыть о нём через год.

Что это значит в более широком контексте

История с Comodo и промежуточными CA касается публичных сертификатов - тех, которые выдают коммерческие удостоверяющие центры для публичных сайтов. Внутренняя инфраструктура работает на собственных CA, и проблемы там другие: не «выдан ненадёжным центром», а «никто не следит».

Хорошая новость - это управляемо. Инвентаризация SSL-сертификатов в рамках аудита инфраструктуры редко занимает больше дня, а находки, как правило, устраняются быстро. Плохая - пока не посмотришь, не узнаешь. У нас не было причин ожидать три проблемы на не самой большой инфраструктуре. Нашли именно потому, что посмотрели.