На прошлой неделе выяснилось, что удостоверяющий центр Fina без согласования с Cloudflare выпустил 12 TLS‑сертификатов на IP‑адрес 1.1.1.1 — публичный DNS‑резолвер Cloudflare. Сертификаты датированы периодом с февраля 2024 по август 2025 года и были замечены благодаря публикациям в журналах Certificate Transparency и обсуждению в рассылке Mozilla dev-security-policy. Cloudflare признала выпуск неправомерным.
Что именно произошло: цепочка доверия и охват Windows
Сертификаты издавал подчиненный центр Fina RDC 2020, входящий в иерархию Fina Root CA. Корневому сертификату Fina доверяет Microsoft, поэтому доверие распространялось на Windows и Microsoft Edge. Это повышало риск для части пользователей, использующих 1.1.1.1 в системах Microsoft.
Риск для DoH/DoT: как несанкционированный сертификат помогает MITM
TLS‑сертификат удостоверяет домен или IP и связывает его с открытым ключом. Если злоумышленник располагает сертификатом и соответствующим приватным ключом, он может криптографически имитировать целевой адрес и проводить манипуляции в стиле man‑in‑the‑middle. В контексте DNS over HTTPS (DoH) и DNS over TLS (DoT) это означает потенциальное перехватывание, расшифровку и модификацию DNS‑запросов к 1.1.1.1.
Cloudflare отдельно подчеркнула, что трафик, защищенный WARP VPN, не затронут. Тем не менее компания исходит из наихудшего сценария: «мы должны предполагать, что приватный ключ существует вне контроля Cloudflare».
Как отреагировали Cloudflare, Microsoft и разработчики браузеров
Cloudflare сообщила, что оперативно связалась с Fina, Microsoft и регулятором TSP, требуя ревокации и пересмотра доверия. Microsoft в ответ заявила о немедленных шагах по блокировке проблемных сертификатов. Представители Google, Mozilla и Apple отметили, что их браузеры никогда не доверяли корню Fina, поэтому пользователям Chrome, Firefox и Safari действий предпринимать не требуется.
Почему так случается: особенности PKI и роль Certificate Transparency
Глобальная PKI — это распределенная система доверия, в которой сбой одного УЦ способен повлиять на безопасность множества сервисов. Прозрачность обеспечивает Certificate Transparency: все выпуски публикуются в открытых журналах, что и позволило выявить инцидент. Однако обнаружение инцидента зависит от регулярного мониторинга этих журналов.
Cloudflare признала собственные недочеты: уведомления по IP‑сертификатам для 1.1.1.1 не сработали, фильтрация была недостаточно точной, а из‑за «шума» оповещения включались не для всех объектов. Компания заявила о переработке мониторинга CT и автоматизации реагирования.
Позиция Fina: «внутреннее тестирование» и человеческий фактор
Fina объяснила выпуск «внутренним тестированием процесса в продакшн‑среде» и ошибочным вводом IP‑адресов. По заявлению УЦ, приватные ключи не покидали контролируемую среду и были уничтожены до отзыва сертификатов; сами сертификаты, в соответствии с процедурой, опубликованы в CT. Проверить эти утверждения извне невозможно, что и заставляет Cloudflare закладываться на риск компрометации ключей.
Контекст и уроки для отрасли
История повторяет системные проблемы PKI: от DigiNotar (2011) до санкций в адрес части инфраструктуры Symantec (2017) — ошибки или злоупотребления УЦ приводят к подрыву доверия на глобальном уровне. Текущий случай подчеркивает важность автоматизированного наблюдения за CT и минимизации доверия по принципу наименьших привилегий.
Рекомендации для организаций: включить постоянный мониторинг CT для доменных имен и, при необходимости, IP‑адресов; автоматизировать оповещения и ревокацию; использовать OCSP stapling и проверять актуальность CRL/OCSP на рабочих станциях Windows; применять certificate pinning в собственных приложениях, где это безопасно; периодически аудировать доверенные корневые УЦ и, при наличии оснований, ограничивать доверие к спорным корням.
Инцидент с Fina демонстрирует, что устойчивость инфраструктуры доверия определяется не только технологией, но и процессами. Чем быстрее компании внедряют мониторинг CT, автоматизируют реакцию на мисс‑эмиссии и сокращают поверхность доверия, тем ниже риск для пользователей DoH/DoT и критически важного трафика. Проверьте свои механизмы наблюдения уже сегодня и убедитесь, что родительские и промежуточные УЦ в вашем контуре действительно заслуживают доверия.