17 października 2026 o 18:05 UTC do Chrome Root Program trafiło zgłoszenie, że ktoś potrafi odtworzyć klucze prywatne ośmiu pośrednich urzędów certyfikacji eMudhra. O 19:45 Chrome rozesłał blokadę, o 22:59 Mozilla zakończyła dystrybucję wpisu w OneCRL. Certyfikaty powstały 30 kwietnia 2025, więc okno ekspozycji liczy osiemnaście miesięcy.
- CA 014klucz prywatnyTLS
- CA 0256klucz prywatnyTLS
- CA 0366klucz prywatnyTLS
- CA 04115klucz prywatnyTLS
- CA 05155klucz prywatnyTLS
- CA 06156klucz prywatnyTLS
- CA 07230klucz prywatnyPODPIS KODU
- CA 08237klucz prywatnyPODPIS KODU
Co się stało między 17 a 20 października
Dotkniętych jest osiem pośrednich CA: sześć do wystawiania certyfikatów TLS i dwa do podpisywania kodu. Ten podział podał Dennis Jackson z Mozilli w mailu do operatorów magazynów zaufania, rozesłanym 19 października przez listę distros i dzień później na oss-security. eMudhra unieważniła całą ósemkę 18 października między 09:24 a 09:38 UTC z powodem ca_compromise, Sectigo unieważniło swoje cross-signy 19 października o 10:35.
Reakcja dostawców była szybka i nierówna. Firefox i Chrome blokowały od 17 października, platformy Apple od 19, Microsoft od 20. Mozilla usunęła korzeń z NSS 3.131.1 i wydała Firefoksa 158.0.1 oraz ESR-y dla użytkowników, do których OneCRL nie dociera. Google zapowiedziało usunięcie emSign ECC Root CA – G3 z magazynu Chrome na 27 października i dodało, że żaden certyfikat z tych pośrednich nie trafił do logów Certificate Transparency, więc klienci egzekwujący CT nie mogli zostać oszukani. Zespół Go wydał awaryjnie wersje 1.26.10 i 1.27.3, w których weryfikator odrzuca łańcuchy przechodzące przez te pośrednie, pod numerem CVE-2026-111943.
Na tym szybka część się kończy. Przeglądarki i duże platformy mają kanały dystrybucji odwołań działające w godzinach, reszta internetu nie ma ich wcale. Filippo Valsorda, który utrzymuje kryptografię w Go, powiedział serwisowi Ars Technica: „To będzie potężna robota porządkowa, większa niż Heartbleed. Ogon będzie bardzo, bardzo długi: urządzenia IoT, kontenery Dockera, zapomniane maszyny z Linuksem, nieutrzymywane narzędzia wiersza poleceń, które wiozą własną kopię korzeni”. Dystrybucje Linuksa wydawały pakiety ca-certificates jeszcze 21 października, a to dopiero początek łańcucha, bo potem ktoś musi je wdrożyć na setkach maszyn.
Cztery, pięćdziesiąt sześć, sześćdziesiąt sześć
Klucze są na krzywej NIST P-384. Klucz prywatny to liczba mniejsza od rzędu krzywej, czyli mniej więcej 2^384, a klucz publiczny zapisany w certyfikacie to ta liczba pomnożona przez stały punkt generatora. Jeżeli liczba jest mała, nie trzeba nic łamać: wystarczy dodawać generator do siebie i porównywać wynik z zawartością certyfikatu.
Sprawdziłem to u siebie, bo takie twierdzenie weryfikuje się w kilka minut. Pobrałem plik impacted-intermediates.json ze strony ujawnienia, wyciągnąłem punkty kluczy publicznych z ośmiu certyfikatów i policzyłem kolejne wielokrotności generatora w czystym Pythonie, bez biblioteki kryptograficznej. Osiem trafień w zakresie od 1 do 255, czas wykonania 13,7 ms. Wartości to 4, 56, 66, 115, 155, 156, 230 i 237. Numerem 4 podpisane jest EM OV TLS CA – G3C, numerem 237 pośrednie EM OV CS CA – G3C służące do podpisywania kodu. Nie potrzeba do tego laboratorium ani budżetu, wystarczy laptop i kwadrans.
Przyczyny eMudhra nie ujawniła. W komunikacie z 20 października potwierdza ceremonię generowania kluczy z kwietnia 2025 i trwające badanie. Wyjaśnienie krążące w relacjach wtórnych, że wadliwy skrypt ceremonii utworzył na HSM drugą, słabą parę kluczy o podobnej etykiecie i to ona trafiła do żądań podpisania, nie ma potwierdzenia u samego CA. Istotne jest co innego: klucze tej jakości przeszły przez ceremonię na certyfikowanym sprzęcie, przez audyt i przez cross-sign u drugiego, niezależnego urzędu.
Warto zauważyć jeden szczegół z plików ujawnienia: certyfikat wystawiony przez eMudhra i jego cross-sign od Sectigo mają ten sam skrót klucza publicznego. To jest dobra wiadomość operacyjna, bo blokada po SPKI, taką wysłał Chrome, zamyka oba łańcuchy naraz. I zła, bo jeden wyciek klucza unieważnia dwie niezależne ścieżki zaufania, w tym tę przez korzeń, którego nikt rozsądny nie usunie ze swojego magazynu.
Komunikat CA odpowiada na inne pytanie
eMudhra podkreśla, że poza jednym wyjątkiem żaden z dotkniętych pośrednich nie był wdrożony produkcyjnie i że żaden nie wystawił certyfikatu końcowego, co potwierdzają zapisy w crt.sh. To jest prawda i nie dotyczy ryzyka. Zagrożeniem nie jest to, co wystawiło CA, tylko to, co może wystawić każdy, kto zna liczbę 4. Taki certyfikat nie musi trafić do logów CT, żeby zadziałał wobec klienta, który CT nie sprawdza, a poza przeglądarkami nie sprawdza go prawie nikt: ani curl, ani moduł ssl w Pythonie, ani agent backupu łączący się z chmurą, ani appliance pobierający sygnatury.
Druga rzecz, która ginie w nagłówkach: usunięcie korzeni emSign nie zamyka sprawy. Każdy z ośmiu pośrednich ma cross-sign Sectigo wystawiony 14 maja 2025, prowadzący do korzenia AAA Certificate Services, obecnego praktycznie w każdym magazynie zaufania i podpisującego ogromną część publicznego internetu. Mozilla wymienia w mailu trzy korzenie i pisze wprost, że ochronę daje odebranie zaufania wszystkim trzem. W praktyce usunięcie AAA Certificate Services zepsuje w organizacji znacznie więcej niż eMudhra, więc realną drogą jest blokada na poziomie pośrednich, po skrócie klucza publicznego. Taką blokadę trzeba czymś dostarczyć, a przeglądarka ma do tego mechanizm, serwer aplikacyjny i urządzenie brzegowe najczęściej nie mają.
Co z tego wynika dla polskiej organizacji?
Trzy rzeczy do zrobienia w tym tygodniu, każda sprawdzalna.
- Przetestuj po jednej maszynie z każdej klasy, nie tylko stacje robocze: serwer Linux, kontroler domeny, obraz kontenera, appliance, agent backupu. Strona ujawnienia wystawia hosty z certyfikatami z dotkniętych pośrednich, w obu wariantach łańcucha. Polecenie curl https://dv-g3b-emudhra.we-have-a-problem.com/ oraz jego odpowiednik dv-g3b-aaa-emudhra mają zwrócić błąd certyfikatu. Odpowiedź 200 oznacza, że dana maszyna nadal ufa kluczowi o wartości 156.
- Na Windows sprawdź, czy maszyna w ogóle pobiera listę certyfikatów niezaufanych. Blokada Microsoftu jedzie przez automatyczny aktualizator CTL, który wymaga dostępu do ctldl.windowsupdate.com i bywa wyłączony kluczem DisableRootAutoUpdate w gałęzi AuthRoot. Stan listy zweryfikujesz poleceniem certutil -verifyCTL Disallowed, a w środowisku odciętym od internetu trzeba pobrać disallowedcertstl.cab i disallowedcert.sst i rozdystrybuować je procedurą opisaną przez Microsoft.
- Zinwentaryzuj magazyny, które wożą własną kopię korzeni: binaria zbudowane w Go (przebudowa na 1.26.10 lub 1.27.3), cacerts w JRE, certifi w Pythonie, Node, obrazy bazowe kontenerów i wszystko, co działa w kontenerach, bo aktualizacja hosta nie zmienia zawartości warstwy obrazu. Osobno potraktuj podpisywanie kodu: dwa z ośmiu pośrednich służyły właśnie do tego, więc reguły dopuszczania plików po wystawcy podpisu wymagają przeglądu.
Osiemnaście miesięcy
Od 30 kwietnia 2025 do 17 października 2026 każdy, kto pobrał te certyfikaty z publicznej bazy CCADB, mógł w kilkanaście milisekund wyliczyć klucz pośredniego CA zaufanego przez wszystkie duże przeglądarki i systemy. Znalazł to pojedynczy badacz przeglądający bazę, a nie ceremonia, audyt, CA wykonujące cross-sign ani programy korzeni, które przez półtora roku trzymały te certyfikaty jako zaufane.
Magazyn zaufania w każdym systemie to lista podmiotów, których wewnętrznych procedur nie da się zweryfikować z zewnątrz, a których błąd jest natychmiast Twoim błędem. Sprawdzić da się tylko jedno: czy mechanizm odbierania zaufania działa u Ciebie szybciej niż w ciągu osiemnastu miesięcy. Dla maszyn w sieci wydzielonej, dla appliance’ów i dla obrazów kontenerów odpowiedź brzmi zwykle nie, i to jest pozycja do dopisania do planu, a nie do zamknięcia tym wpisem.