Скомпрометированы ключи восьми промежуточных CA eMudhra: что обновить на Linux

20 октября 2026 года Mozilla раскрыла компрометацию закрытых ключей восьми промежуточных сертификатов индийского удостоверяющего центра eMudhra. Об инциденте пишут LWN.net и The Register. Ключи были сгенерированы с ошибкой, и восстановить их можно прямо из публичных сертификатов. Тот, у кого есть такой ключ, может выпустить поддельный HTTPS-сертификат на чужой домен, и клиент с устаревшим хранилищем корневых сертификатов ему поверит.

Что произошло

Уязвимость нашёл исследователь 17 октября, когда прогонял проверку по общей базе удостоверяющих центров CCADB. По данным The Register, ключ одного из сертификатов буквально равен числу 4, у остальных — 56, 66, 115, 155, 156, 230 и 237. Для ключа P-384 это значит, что его подбор занимает секунды. Help Net Security со ссылкой на eMudhra объясняет причину: на церемонии генерации ключей в апреле 2025 года скрипт выдал слабые ключи, и сотрудники по ошибке выбрали их вместо правильно сгенерированных.

• 17 октября — Chrome и Firefox заблокировали промежуточные сертификаты.
• 18 октября — eMudhra отозвала их.
• 19 и 20 октября — блокировку включили Apple и Microsoft.
• NSS 3.131.1 — Mozilla убрала из доверенных корень emSign ECC Root CA – G3.
• 22 октября — eMudhra объявила, что уходит с рынка публичных SSL/TLS-сертификатов. Заменить нужно около 30 000 клиентских сертификатов.

Почему это касается серверов, а не только браузеров

Браузеры обновляют списки доверия сами и быстро. Серверное ПО берёт корневые сертификаты из пакета ca-certificates, а многие рантаймы и библиотеки — из собственного встроенного файла. По данным LWN, Ubuntu и Arch уже выпустили обновлённый ca-certificates, Debian готовил своё обновление. В разборе Endor Labs перечислены версии с исправлением: Node.js 22.23.4, 24.22.1 и 26.12.1, Go 1.27.3 и 1.26.10, Python certifi 2026.10.19. Для хранилища cacerts в JDK на момент публикации исправления не было.

Минимальный порядок действий на Debian и Ubuntu:

sudo apt-get update
sudo apt-get install --only-upgrade ca-certificates
sudo update-ca-certificates

На Alpine — apk upgrade ca-certificates, на Fedora и RHEL — dnf upgrade ca-certificates. Обновить пакет на хосте мало: базовые образы контейнеров нужно пересобрать, иначе внутри останется старый бандл. Проверьте и зависимости, которые несут свой PEM-файл: certifi в виртуальных окружениях Python, вендоренные HTTP-клиенты, Electron-приложения.

Мобильные клиенты — отдельный риск

Тот же вопрос стоит перед командами, которые выпускают мобильные приложения. На старых версиях Android системное хранилище корневых сертификатов меняется только с обновлением прошивки, а многие устройства их уже не получают. Если приложение ходит в ваш API без закрепления сертификата (certificate pinning), устаревший телефон всё ещё примет поддельный сертификат, подписанный ключом eMudhra. Здесь мало обновить сервер. Нужно проверить, как клиент проверяет цепочку, и при необходимости выпустить обновление приложения с пиннингом или собственным списком доверия. Этим обычно занимаются те, кто разрабатывает и сопровождает мобильное приложение компании. Для них инцидент — повод пересмотреть сетевой слой клиента, а не только серверные сертификаты.

На серверной стороне проверьте, не выпущен ли ваш собственный сертификат через eMudhra или emSign. Если выпущен — перевыпустите его у другого УЦ заранее, не дожидаясь, пока клиенты начнут получать ошибки. Базовые меры защиты сервера мы собрали в чеклисте после установки.

Совет: добавьте обновление ca-certificates и пересборку базовых образов в регулярное расписание CI. Следующий отзыв корня случится без предупреждения, как и этот.

Вернуться в блог