Скомпрометированный удостоверяющий центр: что я проверяю в сертификатах своих серверов

Приватные ключи восьми промежуточных сертификатов удостоверяющего центра eMudhra утекли. Этим сертификатам доверяли браузеры, операционные системы и почти всё, что ходит по HTTPS. У кого ключи, тот может выпустить поддельный сертификат на любой домен и выдать свой сервер за чужой: за банк или за API вашего платёжного сервиса. Браузеры закрыли это за день. Серверы и ноутбуки сотрудников сами не закроют, и этим придётся заняться тому, кто за них отвечает.

Кто что написал

Cloudflare 20 октября описала инцидент в блоге: о компрометации они узнали 19 октября около 17:00 UTC, примерно за сутки обновили клиенты WARP и cloudflared и закрыли CDN и Zero Trust. Следов эксплуатации у себя не нашли. Два совета оттуда стоит запомнить. Первый: смотреть ниже SDK. Клиент API может проверять сертификат через HTTP-библиотеку, рантайм языка, операционную систему или свой список доверия, и обновление одного SDK ничего из этого не меняет. Второй: когда после обновления в логах появятся ошибки сертификатов, не чинить их отключением проверки.

Ubuntu 20 октября выпустила обновления пакета ca-certificates и библиотеки libnss3 для всех релизов от 14.04 до 26.10. Сам eMudhra в их корневом хранилище не был, но его подписали два других корня, emSign Root TLS CA G3 и Comodo AAA Certificate Services, и оба удалили. Если включены автоматические обновления, а с 16.04 они включены по умолчанию, патч приедет в течение суток. С Java отдельная история: её хранилище синхронизируется с системным через пакет с нерешённой ошибкой, и там нужны ручные действия. 21 октября Oracle выпустила для своей Java CVE-2026-91403.

Simon Willison 20 октября собрал короткую сводку: сертификаты ведут к корням, которым доверяют Mozilla, Microsoft, Apple и Chrome, и любой софт со своим списком доверия нужно обновлять. Для Python уже вышли uv 0.13.4, pip 26.2.2 и certifi 2026.10.19.

Weaviate 22 октября рассказала, как обновлялась сама: весь парк клиентов и платформу перевели на Go 1.27.3 меньше чем за 17 часов, корпоративных клиентов за шесть. Судя по тексту, обновлением была версия языка: тот самый случай «ниже SDK» из текста Cloudflare.

Почему это касается проката, а не только Cloudflare

Возьмём прокат автомобилей. Сайт бронирования стоит на сервере, менеджеры работают с ноутбуков, оплату подтверждают через платёжный сервис, договоры уходят на почту. Сертификат самого сайта в этой истории ни при чём. Опасность там, где сервер проката сам ходит к API платёжного сервиса и к CRM, а менеджер с ноутбука заходит в банк из кафе по чужому Wi-Fi. Если на пути стоит тот, у кого есть утёкшие ключи, он покажет серверу или ноутбуку поддельный «платёжный сервис», и проверка сертификата это пропустит, пока список доверия не обновлён.

Вывод: проверять нужно списки тех, кому доверяют ваши машины, когда сами к кому-то подключаются. На одном сервере таких списков несколько.

Что я проверяю у себя

За мной серверы нескольких компаний: сервер PDR-компании в США на Debian в Google Cloud, с 2022 года, сервер гидропонной фермы там же, и общий сервер студии на 2 ГБ памяти, где в Docker за Nginx работают мой сайт и сервис «Кофе вместе» с сертификатом Let's Encrypt. Вопросы безопасности в PDR-компании идут ко мне, и при крупных взломах в мире я проверяю, касается ли это нас. Эта история как раз из таких.

Первое: системный пакет ca-certificates на каждом сервере. На Debian он называется так же, как на Ubuntu.

Второе: что внутри контейнеров. У образа Docker свой список доверия, обновление хоста его не трогает, образы нужно пересобрать. На сервере студии сборке иногда не хватает памяти, поэтому образ собирается вне сервера и загружается готовым.

Третье: рантаймы. Node.js носит собственный список корневых сертификатов, у Python свой certifi. Про их обновления на этой неделе я пишу отдельно, в обзоре про патчи Node.js, Python и Next.js.

Четвёртое: кто куда ходит. В «Кофе вместе» сервер сам обращается к оптовому API Tasty Coffee и к Google Таблице через внутренние прокси. В PDR-компании парсеры на Python ходят к сервисам Anthropic, OpenAI и Gemini, телефония к Twilio, а PDF собирает Puppeteer со своим Chrome. У каждого из этих путей своя проверка сертификата, и успешный тест в браузере про них ничего не говорит.

Пятое: сертификат Let's Encrypt на сервере студии я не трогаю. Его выдал другой центр, и, по моему пониманию, эта история его не касается.

Что я бы сделал в небольшой компании

Обновить операционные системы на серверах и на рабочих ноутбуках, включая пакет сертификатов. На Ubuntu это обычный apt upgrade.

Составить список программ, которые сами ходят наружу по HTTPS: сайт к платёжному сервису, интеграции с CRM, парсеры, бот в мессенджере. Для каждой узнать, через что она проверяет сертификат: система, рантайм или библиотека.

Пересобрать Docker-образы с обновлёнными базовыми образами и перезапустить контейнеры. Обновить один хост недостаточно.

После обновления посмотреть логи. Если что-то перестало подключаться, разобраться, к кому и почему. Выключать проверку «на время» нельзя.

Сказать сотрудникам, что обновления на ноутбуках и телефонах на этой неделе откладывать не стоит.

О том, зачем системе свой сервер и кто отвечает за доступ, статья Сервер: данные, доступ и выполнение процесса; как держать инфраструктуру, которую можно выпускать и восстанавливать, описано на странице DevOps и инфраструктура. Серверы из этого текста есть в кейсах «Кофе вместе» и технического партнёрства с PDR-компанией. Из близких обзоров: PHP2Shell и проверка своих серверов, неделя патчей Node.js, Python и Next.js и ключи на один запуск вместо вечных; раньше я писал про API-ключи и то, как пережить утечку. Если не уверены, кому доверяют ваши серверы, опишите, что у вас где стоит, и я скажу, с чего начать. Обсудить задачу.