21 октября 2026Команда Сарнас

eMudhra: как восемь ключей УЦ оказались числами меньше 256

17 октября 2026 года исследователь, подписавшийся «Wayne», отправил командам, которые ведут списки доверенных центров сертификации в Chrome, Firefox, Apple и Microsoft, короткое сообщение: «We have a problem here». Подпись под ним была сделана закрытыми ключами восьми промежуточных УЦ индийской компании eMudhra. Проверить такую подпись может любой: она сходится с открытыми ключами из сертификатов. Значит, ключи, которые должны храниться в секрете, оказались у постороннего.

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

Что такое промежуточный УЦ и почему его ключ так важен

Браузер или операционная система хранит список корневых сертификатов. Корневые ключи берегут особенно строго и почти не используют, поэтому повседневную выдачу сертификатов делегируют промежуточным УЦ: корневой сертификат подписывает промежуточный, а тот подписывает сертификаты сайтов. Проверка идёт по цепочке: сертификат сайта → промежуточный → корневой, который уже есть в списке доверия.

Из этого следует главное. Тот, кто владеет закрытым ключом промежуточного УЦ, может выпустить сертификат для любого домена, и любой клиент, доверяющий корню, примет его как настоящий. Именно поэтому на странице инцидента сказано прямо: злоумышленник с таким ключом мог выдать себя за любой сайт или сервис.

Что пошло не так при создании ключей

Эллиптические ключи на кривой P-384 устроены так: закрытый ключ — случайное число от 1 до огромной границы, порядка 2^384. Открытый ключ получается умножением базовой точки кривой на это число, а обратная операция (по точке найти число) считается невозможной, пока число выбрано случайно из всего диапазона. Эта трудность называется задачей дискретного логарифма.

В eMudhra число выбрали неслучайно. По данным расследования Mozilla, все восемь затронутых ключей — целые числа меньше 256, то есть фактически нули с одним значащим байтом. Перебрать такой диапазон тривиально: достаточно посчитать открытые ключи для чисел от 1 до 255 и сравнить с тем, что записано в сертификате. Mozilla сообщает, что ключи восстанавливались «почти мгновенно», причём независимо друг от друга несколько сторон. Поэтому и фраза на странице инцидента: ключи «может восстановить любой по самим сертификатам».

Как это получилось, объясняет сама компания в предварительном ответе, который Mozilla цитирует. По версии eMudhra, из-за ошибки в скрипте генерации ключей на аппаратном модуле параллельно создалась вторая, более слабая пара ключей. Из-за похожих меток ключей запрос на сертификат (CSR) по ошибке сформировали именно на ней, и корневой УЦ подписал его. Компания отдельно отмечает, что ключи создавались в сертифицированных аппаратных модулях безопасности уровня FIPS 140-2 Level 3, и устройство, по её оценке, не виновато. Это пока предварительное объяснение: Mozilla в обсуждении отмечает, что разбор процесса генерации и отдельной истории с неверными подписями в списках отзыва ещё не завершён.

Сроки такие. Церемония генерации ключей, в ходе которой создали пакет из 24 промежуточных сертификатов, прошла 30 апреля 2025 года. С тех пор и до блокировки в октябре 2026 любой, кто знал, куда смотреть, мог подделывать сертификаты от имени этих промежуточных УЦ — около полутора лет. Известно, что атака была технически возможна; использовал ли её кто-то, неизвестно.

Кого это касается

Затронуты восемь промежуточных УЦ:

шесть для HTTPS: EM DV, EM OV и EM EV TLS CA в вариантах G3B и G3C, цепочка идёт к корню emSign Root TLS CA — G3;
два для подписи кода: EM OV CS CA G3B и G3C, цепочка идёт к emSign Root CS CA — G3.

Кроме того, у этих же ключей были кросс-подписи другого крупного УЦ, Sectigo (восемь дополнительных сертификатов). Кросс-подпись нужна, чтобы промежуточные работали в старых системах, но здесь она расширила охват: те же ключи оказались доверенными и по второй цепочке. Sectigo отозвала эти сертификаты.

Как браузеры отреагировали за несколько часов

Хронология, по данным Mozilla и Chrome, выглядит так (время UTC):

17 октября. Chrome получает сообщение, проверяет и в 19:45 выпускает обновление блокировки для шести HTTPS-сертификатов. Mozilla независимо восстанавливает ключи в 21:48, а в 22:59 завершает блокировку в Firefox.
18 октября. eMudhra отзывает все восемь промежуточных сертификатов с причиной «компрометация УЦ».
19 октября. О проблеме предупреждают разработчиков сторонних списков доверия; Apple блокирует сертификаты.
20 октября. Блокировку включает Microsoft. Mozilla убирает из списка доверия корень emSign ECC Root CA — G3, Chrome готовит то же самое в версии 43 своего корневого списка. Chrome сообщает, что пересматривает и остальные сертификаты eMudhra.

Мгновенно закрыть дыру без обновления программ браузерам помогли механизмы, которые распространяют сведения об отозванных сертификатах отдельно от самих программ: OneCRL в Firefox, CRLite и CRLSet в Chrome. В Chrome блокировка идёт по хешу открытого ключа (SPKI), а не по самому сертификату — это заодно закрывает и кросс-подписи Sectigo, у которых тот же ключ. Два сертификата для подписи кода блокировать отдельно не пришлось: Chrome не принимает цепочки для HTTPS через промежуточные УЦ, ограниченные подписью кода.

Почему браузерам повезло больше остальных

Страница инцидента отмечает две вещи.

Первая: ни один сертификат, выпущенный через эти промежуточные УЦ, не попал в журналы Certificate Transparency за весь период. Chrome, Firefox, Edge и Safari требуют записи в журнале, поэтому поддельный сертификат от этих ключей браузер бы всё равно не принял. Скрытно атаковать пользователей браузеров через эти ключи было нельзя.

Вторая: многие программы вне браузеров Certificate Transparency не проверяют и отзыв не проверяют тоже. Это консольные клиенты вроде curl, пакетные менеджеры, среды выполнения языков, встроенные устройства. Для них единственная защита — обновление списка доверенных корней, а оно приходит с задержкой. Использовал ли кто-то слабые ключи против таких клиентов, неизвестно.

Что сделала eMudhra

По данным в трекере Mozilla, компания перестала выпускать сертификаты из всех цепочек, ведущих к корням G3. Нужно перевыпустить около 30 тысяч действующих сертификатов, примерно 97 % из них получены по протоколу ACME (автоматическому выпуску), так что пересадить клиентов на запасную RSA-цепочку G1 можно с минимальной ручной работой. Компания пообещала перепроверить все церемонии генерации ключей в течение недели.

Открытым остаётся вопрос, затронуты ли другие ключи. Mozilla не смогла восстановить ключи семейств A и A-1 (тоже P-384), несмотря на дополнительные усилия, но и RSA-ключи B/C семейств пока не оценивала. Корень emSign Root CA — G1 из списка не убран.

Что проверить у себя

Обычным пользователям достаточно обновить браузер и операционную систему: блокировки уже раздаются. Остальным стоит проверить три места.

Клиенты вне браузера. Проверка из консоли — два запроса к тестовым узлам, подписанным скомпрометированными ключами:

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

Ошибка сертификата — хороший результат: клиент больше не доверяет этим промежуточным УЦ. Если страница открылась, список доверенных корней устарел.

Пакеты и образы. Исправления вышли в ca-certificates для Ubuntu, Debian, Arch, Fedora, Alpine и Gentoo, в NSS 3.131.1, в наборе корней curl от 20 октября, в certifi 2026.10.19, в Go 1.27.3 и 1.26.10, в Node.js 22.23.4, 24.22.1 и 26.12.1, в pip 26.2.2, в Deno 2.9.8 и в других инструментах. На момент публикации страницы Java, Bun, Erlang certifi и FreeBSD ca_root_nss значились как ожидающие. Полный список поддерживается в репозитории проекта. Если приложение или контейнер несёт собственный набор корней, пересобрать образ нужно самостоятельно.

macOS и встроенные утилиты. Система блокирует сертификаты, но встроенные curl, git, python3, perl, ruby и openssl проверяют цепочку по файлу /etc/ssl/cert.pem без проверки отзыва, а файл не обновлялся. Для них авторы страницы дают команду, которая вычищает два затронутых корня из этого файла; встроенный pip, кроме того, пользуется собственной устаревшей копией корней. Для Linux есть способы вручную отключить доверие к двум корням (Comodo AAA Services и emSign ECC Root CA — G3) до выхода обновления дистрибутива, но для обычных пользователей они не рекомендованы. Для Windows блокировка приходит автоматически через обновление списка доверия, а на изолированных машинах администратор может применить скрипт.

Что из этого следует

Первое: сертификат с правильной подписью и ключ, который нельзя восстановить, — разные вещи. УЦ с аппаратным модулем, аудитом и корнем в списках доверия всё равно ошибся на самом первом шаге, выборе числа. Защитой оказалась не безошибочность, а слои вокруг: публичные журналы, делавшие подделку заметной, и быстрые каналы отзыва в браузерах.

Второе: время реакции у разных частей экосистемы отличалось на недели. Браузеры закрыли проблему за часы, а консольные утилиты, языки программирования и контейнерные образы получают исправление вместе с очередным релизом списка корней. Если ваши сервисы ходят наружу через Go, Node.js или Python, сегодня стоит проверить, какую версию доверенных корней они используют, и включить автоматическую проверку отзыва там, где это возможно.

Третье: восстановление ключей по сертификатам удалось сразу нескольким сторонам независимо за пару часов. Если бы сообщение пришло не от добросовестного исследователя, а от злоумышленника, у остальных не было бы такого запаса времени.

Источники: страница инцидента Денниса Джексона emudhra.we-have-a-problem.com, обсуждение в группе dev-security-policy Mozilla, запись об инциденте в Bugzilla (№ 2083449).