Źródła sprawdzone 22 października 2026 r. czasu pekińskiego. Aodbiorcy: użytkownicy indywidualni, operatorzy witryn, programiści i administratorzy systemów.
Poważne słabości umożliwiły odzyskanie grupy kluczy prywatnych eMudhra/emSign pośrednich CA. Dotyczy to klientów korzystających z systemu certyfikatów publicznych do uwierzytelniania witryn internetowych, interfejsów API i oprogramowania. Zaufanie publiczne obejmuje główne systemy operacyjne, ale zestaw zhakowanych kluczy i potencjalny wpływ na klienta mają różne zakresy. 15
W tekście głównym zastosowano nawiasy kwadratowe do numerowania odpowiednich źródeł, a wszystkie odnośniki zewnętrzne wymieniono w załączniku. Podana wersja to wersja bazowa, która zawiera poprawkę dotyczącą tego incydentu na dzień weryfikacji. Podczas wdrażania priorytet ma zaktualizowana wersja stabilna w tej samej obsługiwanej gałęzi.
TL;DR
Potwierdzono, że klucze prywatne Eight pośrednich CA zostały naruszone. Bieżące raporty nie stwierdzają, że główne klucze prywatne lub ogólnie kryptografia HTTPS zostały złamane. Aktualizacje obejmują znaczną część ekosystemu zaufania publicznego; ryzyko resztkowe zależy od rzeczywistego zastosowania.15
- Użytkownicy indywidualni: aktualizują przeglądarki, systemy operacyjne i komponenty bezpieczeństwa. W przypadku Android zaktualizuj także usługi Google Play. Użyj Firefox Android 158.0.2 lub nowszego. 12
- Servers: aktualizuje pakiety
ca-certificates/NSS dystrybucji i sprawdza magazyny zaufania dołączone do aplikacji. Aktualizacja samego hosta jest niewystarczająca. 7810 - Środowiska programistyczne: aktualizacja Node 24 do 24.22.1 lub nowsza wersja w tej branży, stosownie do przypadku. W środowiskach Python zaktualizuj przynajmniej do wersji pip 26.2.2, certifi 2026.10.19 i uv 0.13.4. Zdobądź naprawione pliki binarne Go lub przebuduj je; zaktualizować Java zgodnie z zaleceniami dostawcy. 12–15
- Aktywuj aktualizacje: zrestartuj usługi, których to dotyczy, oraz odbuduj i ponownie wdróż kontenery. W przypadku Cloudflare Tunnel zaktualizuj cloudflared do 2026.10.2 lub nowszego. 7
- Certyfikaty witryn internetowych: zastępują łańcuch, którego dotyczy problem, jeśli zawiera on unieważniony lub zablokowany produkt pośredni CA lub opiera się na niezaufanym katalogu głównym. Ponowne wystawienie certyfikatu nie zastępuje aktualizacji magazynów zaufania klienta. 158
- Weryfikacja: przetestuj rzeczywistą ścieżkę TLS każdej aplikacji. Rozróżnij odrzucenie certyfikatu od przekroczenia limitu czasu i błędów DNS. Pozostaw weryfikację certyfikatu włączoną; nie używaj
-klub pomiń weryfikację, aby ukryć błędy. 7
1 Fakty i przyczyny zdarzenia
potwierdzone fakty
Mozilla i Google potwierdziły defekty w ośmiu pośrednich kluczach prywatnych eMudhra CA. Badacz dostarczył dowód kontroli klucza prywatnego; Mozilla niezależnie odzyskał klucze i odtworzył problem. Sześć pośrednich urzędów certyfikacji obsługuje TLS, a dwa obsługują podpisywanie kodu. 25
Wada leży w wygenerowanych kluczach: te pośrednie urzędy certyfikacji używają krzywej P-384, ale ich klucze prywatne to liczby całkowite poniżej 256. Nie jest to bezpieczne wybieranie losowych kluczy z zamierzonego dużego zakresu. Odzyskanie tych słabych kluczy nie oznacza, że prawidłowo wygenerowane klucze P-384 mogą zostać złamane. 2
Określenie „certyfikat został złamany” należy tu dokładnie rozumieć jako „można odzyskać odpowiedni klucz prywatny”. Certyfikat i zawarty w nim klucz publiczny są z natury publiczne; tak naprawdę należy zachować w tajemnicy klucz prywatny, który może wygenerować ważny podpis.
Kwestie związane z procesem generowania kluczy są nadal badane
Wstępny opis eMudhra śledzi problem podczas ceremonii wygenerowania klucza w kwietniu 2025 r. Wyjaśnienie obejmuje etap enkapsulacji i dekapsulacji klucza: oprócz oryginalnego silnego klucza pojawia się kolejny zestaw słabych kluczy, które są następnie wykorzystywane do stosowania i wydawania certyfikatów. Firma nadal twierdzi, że dokładna przyczyna nie została ostatecznie ustalona. 6
Dlatego można stwierdzić, że klucze te są poważnie słabe i zostały naruszone; awarii nie można dalej opisać, ponieważ udowodniono, że pewne sprzętowe źródło liczb losowych HSM jest wadliwe, ani nie można jej opisać jako ogólnego przełomu kryptograficznego RSA, ECC lub TLS.
Co oznacza brak zaufania do certyfikatu głównego?
Przeglądarka lub system operacyjny może bezpośrednio zablokować certyfikat lub klucz publiczny pośrednika CA, którego dotyczy problem, lub może usunąć prowadzące do nich zaufanie root. Ten ostatni środek spowoduje również odrzucenie niektórych legalnych certyfikatów w tym samym katalogu głównym.
Google zaplanował usunięcie emSign ECC Root CA - G3, aby chronić użytkowników magazynu głównego Chrome, którzy nie otrzymują aktualizacji z CRLSet. Oczekuje się, że usunięcie magazynu głównego zostanie przesunięte w analogicznym okresie od 27 do 28 października czasu pekińskiego; pierwotna godzina Google to poranek 27 października, czasu letniego pacyficznego w USA. Plan ten różni się od wdrożonego wcześniej awaryjnego blokowania klucza publicznego. 1
Nieufność wobec roota jest środkiem reakcji; samo w sobie nie dowodzi, że główny klucz prywatny został naruszony.
2 Dlaczego potencjalny wpływ obejmuje ekosystem zaufania publicznego
Zhakowane klucze i dotknięte ścieżki zaufania
| Przedmiot wyroku | Zakres tego zdarzenia |
|---|---|
| Zidentyfikowano problematyczny klucz | 8 pośrednich kluczy prywatnych CA dla eMudhra |
| Platformy, które mogą wymagać działania | Publiczny sklep główny, przeglądarka, system operacyjny, środowisko wykonawcze języka, pakiet oprogramowania i ekosystem kontenerów |
| Prawdopodobnie podszywano się pod tożsamość TLS | Witryny lub usługi odwiedzane przez klientów, które nadal akceptują powiązany z nimi sfałszowany łańcuch certyfikatów |
| Czy to oznacza, że wszystkie urządzenia zostały przejęte? | Nie; warunki zaufania, lokalizacja sieci atakującego i inne strategie weryfikacji określają możliwość wykorzystania |
| Czy to oznacza, że wszystkie zaświadczenia prawne są nieważne? | Nie; powiązane unieważnienie zależy od tego, którym katalogom głównym lub łańcuchom certyfikatów klient nie zaufał. |
Red Hat wyraźnie ogranicza wykorzystanie do warunków, w których klient nadal akceptuje odpowiedni łańcuch, osoba atakująca posiada złamany klucz prywatny i jest w stanie przechwycić połączenie w sieci. Pokrycia ryzyka nie należy mylić z liczbą ataków, które miały miejsce. 10
Strony internetowe korzystające z innego CA również mogą zostać podszyte
Załóżmy, że witryna faktycznie korzysta z certyfikatu Let’s Encrypt, a klient odwiedzającego ufa jednocześnie wielu publicznym CA. Osoba atakująca może spróbować użyć zhakowanego pośrednika CA w celu utworzenia kolejnego certyfikatu dla tej samej nazwy domeny. Klienci zazwyczaj nie wymagają z góry, aby w nazwie domeny można było używać wyłącznie Let’s Encrypt; jeśli fałszywy łańcuch jest nadal akceptowany, z którego faktycznie korzysta witryna CA, nie wystarczy, aby wykluczyć takie ataki. 8
Mechanizm ten wyjaśnia: Zastąpienie innego certyfikatu CA, który pierwotnie był normalny, nie spowoduje automatycznej naprawy zaufania klienta do zaatakowanego certyfikatu CA. To, co naprawdę należy odciąć, to droga, na której klienci mogą akceptować fałszywe tożsamości.
Trzy skutki należy rozpatrywać oddzielnie
Ryzyko podszywania się pod tożsamość: Klienci, którzy nie zablokowali odpowiedniego łańcucha, mogą zaakceptować tożsamość sfałszowaną przez atakującego, powodując wysyłanie wrażliwych żądań do fałszywych usług.
Uzasadnione ryzyko dostępności usług: usunięcie zaufania root może spowodować błędy certyfikatów w przypadku legalnych witryn internetowych, które mogą wymagać migracji do innego akceptowanego łańcucha.
Ryzyko związane z wdrożeniem: system operacyjny może zostać naprawiony, podczas gdy magazyn zaufania dołączony do aplikacji, środowisko wirtualne, stary obraz kontenera lub skompilowany program zachowują stare zachowanie sprawdzania poprawności.
Te trzy zakresy nie są identyczne. Odpowiedź Cloudflare obejmuje zdalną weryfikację tożsamości, współdzielone magazyny zaufania, obrazy podstawowe i pojedyncze aplikacje, co ilustruje, dlaczego te dwa ostatnie zadania należy wykonywać oddzielnie. 7
3 Dotknięte CA i dostawcy certyfikatów
Dostawca i typ wpływu
| dostawcy lub systemu | Rola w tym zdarzeniu | Granice, które należy rozróżnić |
|---|---|---|
| eMudhra／emSign | Pośredni klucz prywatny CA został bezpośrednio naruszony. | Nie możesz zapisać wszystkich korzeni eMudhra i wszystkich certyfikatów jako pękniętych |
| Łańcuch podpisów krzyżowych powiązany z Sectigo | Dla tej samej partii kluczy publicznych, których dotyczy problem, wydano certyfikat krzyżowy A, tworząc kolejną ścieżkę zaufania. | Odpowiedni certyfikat krzyżowy lub klucz publiczny musi zostać zablokowany; Nie udowodniono, że główny klucz prywatny Sectigo został naruszony. |
| Odpowiednie poziomy certyfikatów dla Internet2/InCommon | Niektóre legalne certyfikaty wymagają usunięcia katalogu głównego emSign ECC, co wiąże się z migracją | Jest to skutek uboczny pierwotnej nieufności i nie można go liczyć jako środka spośród 8 słabych kluczy CA |
| Let’s Encrypt, DigiCert, Google Trust Services, GlobalSign itp. | W tym raporcie nie jest wymieniony jako strona, której klucz prywatny został naruszony | Uzasadnione certyfikaty nie są jednolicie unieważniane; podatni na zagrożenia klienci mogą nadal akceptować fałszywe certyfikaty podszywające się pod obsługiwane przez nich witryny internetowe |
| CDN, platforma chmurowa, sprzedawca certyfikatów | Ewentualnie dostarcz odpowiednie certyfikaty lub skorzystaj z publicznego magazynu zaufanych certyfikatów podczas łączenia się z źródłem i API | Aby sprawdzić rzeczywisty łańcuch certyfikatów i walidator, nie patrz tylko na platformę lub nazwę produktu |
Powiadomienie Mozilla dokumentuje zhakowane klucze i podpisy krzyżowe Sectigo. Publiczna dyskusja na temat incydentów Google dotyczy migracji legalnych hierarchii Internet2/InCommon. 25 Cloudflare poprawia usługę adresowania i zaufanie klientów; nie wskazują one na naruszenie własnych kluczy prywatnych CA Cloudflare. 7
Łańcuch certyfikatów TLS i podpis krzyżowy
Poniższa relacja opisuje tym razem tylko ścieżki powiązane z TLS. Nie obejmuje ścieżek podpisywania kodu ani nie oznacza, że ścieżki te są nadal zaufane na wszystkich platformach. 17
emSign ECC Root CA - G3→emSign Root TLS CA - G3→ Dotknięty TLS Pośredni CA Klucz publiczny → Fałszywy certyfikat dla domeny docelowejAAA Certificate Services→ Dotknięty TLS Pośredni CA Klucz publiczny → Sfałszowany certyfikat dla domeny docelowej
emSign Root TLS CA - G3 jest jednym z bezpośrednich wystawców półproduktów TLS, których dotyczy problem, i sam w sobie może być kotwicą zaufania w niektórych sklepach. emSign ECC Root CA - G3 zapewnia kolejną warstwę podpisu krzyżowego. Sectigo AAA Certificate Services tworzy dodatkową ścieżkę do tych samych pośrednich kluczy publicznych CA. 17
Dlatego podczas naprawy istnieją dwie różne szczegółowości:
- Zablokuj dokładny pośredni CA lub klucz publiczny:, może to zachować inne prawidłowe hierarchie w tym samym katalogu głównym, gdzie walidator obsługuje ten mechanizm.
- Usuń zaufanie root: może to chronić klientów bez pośrednich możliwości blokowania CA, ale może mieć wpływ na kompatybilność. Wszystkie inne ścieżki akceptowane przez klienta również muszą zostać uwzględnione. 5
„Usuń wszystkie katalogi główne Sectigo/eMudhra” nie powinno być traktowane jako masowy, ogólny krok, ani samo usunięcie certyfikatu o podobnej nazwie nie powinno oznaczać zamknięcia wszystkich ścieżek.
4 Zasięg systemu operacyjnego i przeglądarki
Główna platforma
| Platforma | Znane usposobienie | Zakres, który należy sprawdzić podczas użytkowania |
|---|---|---|
| Windows i Windows Server | Dystrybucja Microsoft zablokowana przez automatyczną aktualizację listy zaufanych certyfikatów | Czy urządzenie otrzymało aktualizację; samodzielny CA bundle niekoniecznie korzysta ze ścieżki weryfikacji Windows |
| macOS, iOS, iPadOS itp. Platforma Apple | Koordynator incydentu potwierdził, że Apple uruchomił odpowiednią blokadę | Nie ma gwarancji, że każda starsza wersja i aplikacja innej firmy będzie objęta takim samym zakresem |
| Android | Google dystrybuuje równoważne bloki poprzez usługę Google Play | ROM bez serwisu Google Play należy zweryfikować zgodnie z zapowiedzią producenta; użyj wbudowanego weryfikatora w celu dodatkowej weryfikacji |
| Ubuntu | Udostępniono poprawki pakietu certyfikatów systemowych, obejmujące wiele gałęzi bieżących i starych wersji | Stara wersja ESM obsługuje warunki, pakiet certyfikatów wewnętrznych kontenera i wbudowaną bibliotekę aplikacji |
| Debian i Devuan | Debian zarejestrowany ca-certificates naprawiony | Musisz sprawdzić aktualnie używaną gałąź i zainstalowany pakiet. Nie możesz skopiować numeru wersji innej gałęzi. |
| RHEL i pochodne | Oficjalna lista to RHEL 6, 7, 8, 9, 10 i obejmuje powiązane produkty oraz obrazy, których może to dotyczyć | W chwili sprawdzania ogłoszenie nie zawierało jeszcze pełnej listy poprawek i errat; Komunikatu „Nie znaleziono aktualizacji” nie można uznać za niezmiennego |
| Fedora, Arch, Gentoo, Alpine itp. | Opiekun zdarzenia sporządził odpowiednią dokumentację napraw | Niezależnie potwierdzone przez wydanie, gałąź wersji i obraz |
| FreeBSD | Oficjalnie wyświetla listę wszystkich obsługiwanych wersji i zapewnia naprawy magazynu zaufania systemu | Po aktualizacji zrestartuj odpowiedni proces demona zgodnie z zapowiedzią; sprawdź oddzielnie magazyn zaufanych aplikacji niezależnej. |
Podsumowanie Windows, Apple i wydań można znaleźć w 4; dla Android, patrz 1; dla Ubuntu, Debian, RHEL i FreeBSD Ewidencja wystawcy wykazana jest odpowiednio w 8–11.
Systemy, które nie są już obsługiwane, urządzenia offline, NAS, routery i inne środowiska wbudowane muszą potwierdzić, czy nadal ufają odpowiedniemu łańcuchowi i czy mają kanały do otrzymywania odwołań lub aktualizacji oprogramowania. Sama nazwa platformy nie zastępuje sprawdzenia rzeczywistego zachowania weryfikacyjnego.
Ochrona przeglądarki różni się od ochrony systemu operacyjnego
Chrome wykorzystuje CRLSet do dystrybucji bloków awaryjnych; Firefox wykorzystuje mechanizmy takie jak OneCRL. Wydano również Firefox z informacjami o blokowaniu, aby zapewnić dodatkową ochronę konfiguracji, które nie otrzymują prawidłowo ustawień zdalnych. 13
Niektóre konfiguracje Firefox Android nie zastosowały poprawnie zaktualizowanej listy podczas uruchamiania, co według Mozilla zostało naprawione przez 158.0.2.. Dlatego też status wcześniejszej wersji 158.0.1 nie może zostać rozszerzony, aby uwzględnić wszystkie chronione konfiguracje Android Firefox. 2
Podjęto kroki w celu weryfikacji systemu Apple i Windows, ale nie oznacza to, że wszystkie programy wiersza poleceń na tej samej maszynie zostaną poddane weryfikacji systemowej. Opiekun wydarzenia szczególnie przypomniał, że niektóre wbudowane narzędzia macOS korzystają z niezależnych plików certyfikatów; Podczas sprawdzania należy zapisać rzeczywiste zaplecze TLS i źródło CA. 4
Granice ochronne dla przejrzystości certyfikatów
Google potwierdził, że przed wdrożeniem bloku sześć pośrednich TLS CA nie wystawiło certyfikatu TLS, który został wpisany do dziennika CT. Dlatego klienci Chrome, którzy wymuszają CT, mają dodatkową ochronę. Fakt ten nie wyklucza możliwości, że inni klienci nie wykonujący CT zaakceptowali nieudokumentowane certyfikaty. 15
„Okazuje się, że można go powiązać z zaufanym rootem”, „istnieją potencjalne warunki wykorzystania” i „nastąpił atak” to trzy różne oceny i nie należy ich zastępować.
5 Środowisko programistyczne i podstawy naprawy środowiska wykonawczego
Poniżej znajduje się zestawienie potwierdzonych poprawek i nie jest wymagane długoterminowe przypinanie tych wydań. Dystrybucje mogą naprawiać starsze numery wersji, wycofując łatki. Należy również przejrzeć zawarte w nich porady dotyczące bezpieczeństwa.
| komponenty | Potwierdzona wersja lub metoda aktualizacji | Uwagi dotyczące wdrożenia |
|---|---|---|
| Node.js 24 | 24.22.1 lub zaktualizuj stabilną wersję tej samej gałęzi | Zawiera aktualizacje repozytorium głównego i odrzucanie zablokowanych publicznych pęków kluczy; sprawdź ścieżkę Node rzeczywiście używaną przez usługę i uruchom ponownie |
| Python certifi | 2026.10.19 lub nowsza wersja | Sprawdź każde rzeczywiste środowisko działania; nie można zaktualizować tylko jednego pakietu w ramach globalnego Python |
| pip | 26.2.2 lub nowsza wersja | Oddzielnie zaktualizuj pip w starym środowisku wirtualnym i sprawdź wersję po utworzeniu nowego środowiska |
| uv | 0.13.4 lub nowsza wersja | Zaktualizuj kopię narzędzia w postaci, w jakiej zostało faktycznie zainstalowane |
| Go | 1.27.3 lub 1.26.10, dostępna jest również zaktualizowana wersja odpowiedniej gałęzi | Przebuduj i wdróż odpowiednie programy po zaktualizowaniu łańcucha narzędzi lub uzyskaj plik binarny naprawy od dostawcy |
| Oracle JDK | Poprawki Critical dla odpowiednich obsługiwanych linii wersji | Różni wydawcy JDK śledzą własne ogłoszenia; nie ma jednego numeru wersji, który miałby zastosowanie do wszystkich wydań Java |
| Cloudflare Tunnel | cloudflared 2026.10.2 lub nowsza wersja | Zaktualizuj działające usługi; wdrożenie kontenera wymaga wymiany obrazu i ponownego wdrożenia |
| Cloudflare One／WARP | Stała wersja klienta odpowiadająca platformie lub zaktualizowana wersja stabilna | Środki po stronie klienta i serwera są potwierdzane oddzielnie. Informacje na temat konkretnych wersji platform znajdują się w załączniku 7 |
Oryginalne instrukcje dla Node, Python, Go, Oracle i Cloudflare są dostępne odpowiednio w 13, 12, 14, 15, 7.
Problem z niezależną bazą danych certyfikatów Python
Urzędnicy Python wskazali, że stary pip będzie korzystał z kombinacji zaufania systemowego i wbudowanego certifi. Zwykła modyfikacja bazy certyfikatów systemu lub dodanie pliku CA do pip nie może w sposób niezawodny wykluczyć wbudowanego starego zaufania. Dlatego PIP_CERT, REQUESTS_CA_BUNDLE lub --cert nie mogą być używane jako uniwersalne zamienniki naprawcze dla starszego pip. 12
Po aktualizacji sprawdź istniejące środowiska wirtualne. Sprawdź także wersję pip faktycznie zainstalowaną w nowo utworzonych środowiskach, aby starsze komponenty bootstrap nie wprowadzały ponownie podatnych na ataki narzędzi. W przypadku pierwszej aktualizacji postępuj zgodnie ze źródłami pobierania i krokami weryfikacji SHA-256 w poradniku Python przed aktualizacją innych pakietów. 12
Go i inne skompilowane programy
Poprawka dla Go zmieniła logikę sprawdzania poprawności dla crypto/x509. 14 Z punktu widzenia mechanizmu wdrażania aktualizacja kompilatora na maszynie deweloperskiej nie spowoduje ponownego zapisania już wdrożonego pliku binarnego. Aby uzyskać nową blokadę warstwy kodu, należy aplikację przebudować i wymienić lub zastosować zaktualizowaną wersję dostarczoną przez dostawcę. To, czy starszy program może również skorzystać z aktualizacji roota systemu, zależy od faktycznej ścieżki weryfikacji, z której korzysta.
Kontenery i aplikacje pakietowe
Pakiet certyfikatów systemowych, zależności aplikacji i czas działania w kontenerze są zwykle określane na podstawie zawartości obrazu. Aktualizacja hosta nie jest równoznaczna z aktualizacją zawartości obrazu; należy zaktualizować podstawowy obraz i zależności, a faktycznie działającą instancję należy odbudować, wdrożyć i sprawdzić. Aplikacje w pakietach i programy komputerowe dostarczane z własnym środowiskiem wykonawczym również powinny być aktualizowane zgodnie z kanałami wydań dostawców. 710
6 Instrukcje wykonania naprawy
Najpierw określ obiekt kontroli
Zaleca się zapisanie poniższych informacji dla usług, które mają być chronione, a następnie wybranie odpowiedniej ścieżki naprawy. Jest to lista kontrolna wdrożenia, która nie wymaga obecności wszystkich komponentów w każdym systemie.
| Projekt | Co należy zapisać |
|---|---|
| Zastosowania i zastosowania | Przeglądarka, klient płatności API, usługa wysyłania wiadomości e-mail, narzędzie do pobierania, odwrotne proxy itp. |
| pozycja robocza | Host, kontener, maszyna wirtualna, aplikacja komputerowa lub urządzenie mobilne |
| Sprawdź wdrożenie | Walidator systemu operacyjnego, biblioteka OpenSSL, Node, Python, Java lub aplikacja na zamówienie |
| zaufane źródło | Pakiet systemowy CA, certifi, JDK magazyn zaufania, wbudowana CA bundle lub konfiguracja korporacyjna |
| Stan naprawy | Zainstalowana wersja, źródło poprawki, możliwość ponownego uruchomienia lub ponownego wdrożenia |
| Wyniki akceptacji | Czy łańcuch, którego dotyczy problem, zostanie odrzucony, czy normalne połączenie biznesowe powiodło się i czas sprawdzenia |
Przewodnik programisty dla Cloudflare wyraźnie stwierdza, że SDK może delegować weryfikację innym komponentom; tylko aktualizacja najwyższego poziomu SDK niekoniecznie zmienia rzeczywistą politykę zaufania. 7
Systemy operacyjne i przeglądarki
Windows: umożliwia włączenie i weryfikację automatycznych aktualizacji listy zaufanych certyfikatów. Rozpowszechniaj aktualizacje poprzez ustalone zasady zarządzania. Urządzenia offline lub urządzenia z wyłączonymi automatycznymi aktualizacjami wymagają zastosowania blokady w ramach odpowiedniego procesu zarządzania. Sprawdź osobno programy, które nie korzystają z walidacji systemu Windows. 4
Apple Platforma: Kompletne aktualizacje systemu, komponentów bezpieczeństwa i aplikacji. Aby zapoznać się z narzędziami programistycznymi macOS, sprawdź także jego zaplecze TLS, pliki certyfikatów i źródła instalacji. Nie można ocenić, że cała maszyna została naprawiona tylko dlatego, że Safari odrzucił łańcuch testowy. 4
Android: aktualizacja usług Google Play na urządzeniach, które ją posiadają. Google stwierdza, że ponowne uruchomienie urządzenia może spowodować natychmiastową aktualizację. W przypadku urządzeń bez tych usług postępuj zgodnie z zaleceniami dostawcy lub ROM; Oświadczenie o zasięgu Google nie ma automatycznego zastosowania do każdego urządzenia Android. 1
Ubuntu/Debian: zaktualizuj pakiety certyfikatów z obsługiwanych repozytoriów i sprawdź poradę dotyczącą zainstalowanej dystrybucji. Na przykład system oparty na APT może wykorzystywać:
sudo apt update
sudo apt install --only-upgrade ca-certificates
dpkg-query -W -f='${Package} ${Version}\n' ca-certificatesOdpowiednie aktualizacje dla Ubuntu 22.04, 24.04, 26.04 i 26.10 stanowią wsparcie standardowe; wcześniejsze wersje powinny sprawdzić obsługę ESM i stan magazynu. Po pomyślnym zakończeniu komendy nadal należy porównać wersję pakietu poprawek w biuletynie. 89
RHEL i powiązane produkty: Sprawdź pakiet certyfikatów i erratę bezpieczeństwa według kanału produktu. Sprawdzanie wersji można wykonać za pomocą:
rpm -q ca-certificatesUżyj obsługiwanego mechanizmu aktualizacji DNF/YUM, aby uzyskać poprawki dostawców; jeśli kanał nie dostarczył jeszcze poprawki, nie uważaj „braku pakietu do aktualizacji” za bezpieczny. Jeśli konieczne jest tymczasowe usunięcie zaufania głównego, zastosuj środki wyraźnie wymienione przez producenta i oceń zgodność legalnych certyfikatów biznesowych. 10
FreeBSD: zaktualizuj odpowiednią gałąź systemu zgodnie z oficjalnymi zaleceniami, a następnie zrestartuj demony, korzystając z konfiguracji zaufania OpenSSL, której dotyczy problem, lub zrestartuj system. 11
Aplikacje i obrazy
Po zakończeniu odpowiednich aktualizacji środowiska wykonawczego i zależności certyfikatów sprawdź ścieżkę pliku wykonywalnego, w którym faktycznie działa usługa, aby uniknąć sytuacji, w której terminal przełączył się na nową wersję, a demon nadal korzysta ze starego katalogu instalacyjnego. W przypadku wielośrodowiskowego Python, kontenerów usług i aplikacji, które mają własne środowisko wykonawcze, należy je sprawdzić osobno.
W przypadku komponentów, które wymagają odbudowania, zapisz wersję kompilacji, wersję zależności i identyfikator obrazu wdrożenia. Obiekt akceptacji jest faktycznie działającą instancją i nie może po prostu sprawdzić nowego znacznika w maszynie kompilacji lub rejestrze obrazu. 71214
Migracja certyfikatu strony internetowej
Jeśli łańcuch witryny zawiera odwołany lub zablokowany produkt pośredni CA lub ostatecznie opiera się na niezaufanym katalogu głównym, uzyskaj inny łańcuch, który nadal akceptują klienci. Zainstaluj kompletny łańcuch certyfikatów serwera i sprawdź każdy ruch przychodzący, w tym moduły równoważenia obciążenia, odwrotne proxy, punkty końcowe CDN i bezpośrednio dostępne źródła. 15
To, czy wymagana jest migracja, zależy od rzeczywistego łańcucha. Filtrowanie wyłącznie według marki sprzedaży certyfikatów może nie uwzględniać relacji związanych z odsprzedażą lub podpisaniem krzyżowym; samo oczekiwanie na regularne odnowienie wygaśnięcia niekoniecznie musi zakończyć migrację przed aktualizacją magazynu głównego.
W przypadku innych normalnych certyfikatów witryn internetowych wydanych przez CA, które nie opierają się na katalogu głównym, którego dotyczy problem, nie ma potrzeby ponownego ich podpisywania z powodu tego zdarzenia. Jednocześnie sam serwer witryny internetowej powinien nadal przeprowadzać kontrole naprawy po stronie klienta podczas wywoływania usług zewnętrznych.
7 Sprawdź, czy poprawka rzeczywiście zaczęła obowiązywać
Sprawdzanie wersji i sprawdzanie zachowania są wykonywane oddzielnie
Sprawdzanie wersji służy do potwierdzania, czy zostały wdrożone poprawki lub poprawione komponenty; kontrole behawioralne służą potwierdzeniu, że aplikacja faktycznie korzysta z oczekiwanej ścieżki weryfikacji. Te dwie kontrole rozwiązują różne problemy i żadnego z nich nie można zastąpić komunikatem „Polecenie aktualizacji zostało wykonane pomyślnie”.
Opiekun wydarzenia zapewnia miejsce testowe i materiały do łańcucha certyfikatów, a wejście znajduje się w dodatku 4. Należy go zweryfikować w rzeczywistym środowisku operacyjnym docelowej aplikacji, zachowując normalną konfigurację weryfikacji certyfikatu. 47
| Sprawdź wyniki | Wnioski, które można wyciągnąć |
|---|---|
| Jawnie odrzuć, ponieważ łańcuch, którego dotyczy problem, nie jest zaufany | Wskazuje, że testowana ścieżka weryfikacji odrzuciła łańcuch |
| Zaakceptuj normalnie uszkodzony łańcuch | Wskazuje, że ścieżka wymaga dalszej naprawy lub sprawdzenia konfiguracji. |
| Błąd DNS, przekroczenie limitu czasu połączenia, odrzucenie serwera proxy lub usługa nieosiągalna | Nie można na tej podstawie stwierdzić, że ryzyko certyfikatu zostało wyeliminowane. |
| Przeglądarka odrzuca, ale wywołanie aplikacji nie jest sprawdzane | Może jedynie potwierdzić przeglądarkę, a nie program działający w tle. |
| Łańcuch A został odrzucony | Nadal należy rozważyć, czy klient akceptuje inną ścieżkę podpisu krzyżowego |
Test powinien również obejmować normalne połączenia biznesowe, aby uniknąć pomylenia wszystkich niepowodzeń żądań z pomyślnymi naprawami po niepowodzeniach biznesowych spowodowanych utratą zbyt dużego zaufania.
Sugerowane warunki ukończenia
- Źródło aktualizacji i wersja komponentów, których dotyczy problem, są udokumentowane.
- Odpowiednia działająca instancja została ponownie uruchomiona, przebudowana lub ponownie wdrożona.
- Rzeczywista aplikacja odrzuca łańcuch, którego dotyczy problem, a weryfikacja TLS dla normalnej działalności nadal działa.
- Nie ma konfiguracji umożliwiającej tymczasowe wyłączenie weryfikacji certyfikatu w celu przywrócenia połączenia.
- W przypadku migracji certyfikatu strony internetowej wszystkie wejścia zewnętrzne zostały przełączone i zweryfikowane.
Powyższe warunki ukończenia stanowią sugestie dotyczące akceptacji obsługi i konserwacji dla tej utylizacji; nie jest to równoznaczne z udowodnieniem, że w sprzęcie nie występują inne problemy związane z bezpieczeństwem.
8 Historyczne granice ruchu i ryzyka HTTPS
Trzy typy kluczy mają różne zastosowania
| klucz | Główny cel |
|---|---|
| Klucz prywatny CA | Podpisz tożsamość i klucz publiczny powiązany w certyfikacie |
| Klucz prywatny witryny internetowej | Potwierdź tożsamość serwera w uwierzytelnionym certyfikacie uzgadnianiu TLS |
| klucz sesji | Chroń dane faktycznie przesyłane w ramach połączenia |
Uzyskanie klucza prywatnego CA nie jest równoznaczne z uzyskaniem klucza prywatnego serwisu ani wszystkich kluczy sesyjnych. A normalne połączenie z zachowaniem tajemnicy przekazywania przy użyciu tymczasowej wymiany kluczy nie ujawni automatycznie sesji historycznych tylko dlatego, że długoterminowy klucz podpisujący zostanie później naruszony. Odpowiednie atrybuty bezpieczeństwa TLS 1.3 można znaleźć w RFC 8446. 16
Główne ryzyko pojawia się tym razem na etapie uwierzytelniania: jeśli klient zaakceptuje certyfikat fałszywego serwera, może nawiązać połączenie z atakującym, które jest nadal zaszyfrowane. TLS 1.3 wymaga również zaufanego uwierzytelniania; zwykła aktualizacja wersji protokołu nie zastępuje blokowania CA.
Oceny, które można, a których nie można w tej chwili dokonać
Potwierdzono: określone pośrednie klucze prywatne CA zostały naruszone; dotknięte ścieżki zaufania publicznego mają szeroki zasięg; główne platformy i kilka ekosystemów oprogramowania podjęło działania. 145
W wyniku tego incydentu nie ustalono:, że wszyscy użytkownicy doświadczyli ataków typu man-in-the-middle, że inne klucze prywatne CA zostały naruszone, że cały historyczny ruch HTTPS można odszyfrować lub że aktualizacja jednej przeglądarki chroni wszystkie aplikacje na urządzeniu.
Ostateczną ocenę dotyczącą konkretnej usługi należy oprzeć na jej łańcuchu certyfikatów, zasadach weryfikacji, aktualnie działających komponentach i statusie aktualizacji, a nie tylko na tym, czy na pasku adresu widnieje informacja HTTPS.
Dodatek A Nazwa półproduktu, którego dotyczy CA
Poniższe nazwy ułatwiają kontrolę zasobów. Nazwy nie zastępują odcisków palców certyfikatów ani identyfikatorów klucza publicznego. Do automatycznego dopasowywania należy używać dokładnych identyfikatorów opublikowanych przez opiekunów lub dostawców incydentów, w tym certyfikatów z podpisem krzyżowym. 5
| Środkowy CA | Cel | Organizacje stowarzyszone |
|---|---|---|
| EM EV TLS CA - G3B | TLS | eMudhra BV |
| EM OV TLS CA - G3B | TLS | eMudhra BV |
| EM DV TLS CA - G3B | TLS | eMudhra BV |
| EM EV TLS CA - G3C | TLS | eMudhra Inc |
| EM OV TLS CA - G3C | TLS | eMudhra Inc |
| EM DV TLS CA - G3C | TLS | eMudhra Inc |
| EM OV CS CA - G3B | podpisywanie kodu | eMudhra BV |
| EM OV CS CA - G3C | podpisywanie kodu | eMudhra Inc |
TLS nie jest dokładnie tym samym mechanizmem sprawdzania poprawności i unieważniania, co podpisywanie kodu. Głównym tematem tego artykułu jest HTTPS/TLS; środowisko podpisywania kodu powinno w tym celu zastosować oprogramowanie Microsoft, JDK lub powiązanego dostawcy oprogramowania, a wyniki testu przeglądarki nie powinny być traktowane jako akceptacja podpisania kodu. 515
Dodatek B Link referencyjny
Poniższe źródła zostały zweryfikowane w dniu 22 października 2026 r. Ogłoszenie kroczące może być w dalszym ciągu aktualizowane, a status i wersję w tekście należy rozumieć na podstawie daty niniejszego dokumentu.
Fakty dotyczące incydentów i obsługa platformy
[1] Google Chrome i Android Oficjalne ogłoszenie Opisuje wady klucza prywatnego, blokowanie SPKI, dystrybucję usług Google Play, ochronę CT i plany usuwania repozytorium głównego Chrome. Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates
[2] Mozilla Bugzilla 2083449 Zapis zdarzenia Zawiera oryginalne raporty, niezależną weryfikację, badanie procesu generowania, późniejsze poprawki dla Firefox Android i dyskusje na temat migracji certyfikatów prawnych; skoncentruj się na komentarzach 5, 11, 29 i 30. eMudhra Private key compromise of Intermediate Certificates
[3] Mozilla Firefox Informacja dotycząca bezpieczeństwa Opis awaryjnej dystrybucji OneCRL i późniejszej utylizacji Firefox/NSS. Protecting Firefox users following the compromise of eMudhra intermediate certificates
[4] Koordynator zdarzeń Dennis Jackson Podsumowanie konserwacji i portal wykrywania Zawiera dodatkowe instrukcje dotyczące stanu naprawy platformy i oprogramowania, wejścia do testu, materiałów dotyczących łańcucha certyfikatów publicznych i środowisk takich jak Windows/macOS. Wyniki testów reprezentują jedynie faktycznie przetestowane ścieżki weryfikacji. eMudhra Intermediate CA Compromise
[5] Mozilla Informacja dla administratorów dystrybucji i zaufanych magazynów Opisuje 6 TLS i 2 pośrednie podpisywanie kodu CA, Sectigo podpisywanie krzyżowe, unieważnianie i granice przetwarzania zaufania głównego, a także podaje dokładną identyfikację certyfikatu i klucza publicznego. oss-security eMudhra Intermediates Compromise
[6] eMudhra Oficjalny komunikat wydarzenia Podaj wstępne wyjaśnienie producenta dotyczące procesu generowania klucza; dokładna pierwotna przyczyna będzie nadal uzależniona od zakończenia zakończonego dochodzenia. eMudhra Statement on Recent Certificate Security Incident
[7] Cloudflare Oficjalne instrukcje dotyczące zdarzeń i napraw Obejmuje WARP, Cloudflare Tunnel, weryfikację miejsca pochodzenia, zależności środowiska wykonawczego, aktualizacje obrazów i metody weryfikacji. 8 eMudhra certificates are compromised Here is what you need to know
Systemy operacyjne i dystrybucje
[8] Ubuntu Oficjalne powiadomienie o naprawie Wyświetla listę pakietów poprawek ca-certificates, kanałów wsparcia i docelowych kroków aktualizacji dla każdej wersji. eMudhra CA compromise fixes available
[9] Debian Oficjalny rejestr problemów i napraw Zapis poprawek opiekuna i odpowiadający mu pakiet wersji należy traktować jako standard, a wczesne tymczasowe sugestie podczas dyskusji na temat problemu nie powinny być traktowane jako ostateczne rozwiązanie. Debian bug 1151413 eMudhra Intermediate CA key compromise
[10] Red Hat Oficjalny biuletyn bezpieczeństwa RHSB 2026 012 Zawiera listę numerów RHEL 6 do 10, powiązane skutki dla produktów i kontenerów oraz wpisy dotyczące wydania poprawek i tymczasowej utylizacji. Certificate compromise eMudhra
[11] FreeBSD Oficjalny biuletyn bezpieczeństwa Podaj gałęzie systemu, których dotyczy problem, wersje naprawy i wymagania dotyczące ponownego uruchomienia usługi. FreeBSD SA 26 73 caroot
Środowisko wykonawcze i protokoły
[12] Python Oficjalny opis wydarzenia Zapewnia podstawy naprawy dla pip, certifi, uv itp., wyjaśnia problem starego niezależnego magazynu zaufanych certyfikatów pip i zapewnia początkową metodę aktualizacji z weryfikacją SHA-256. Information for Python users regarding eMudhra emSign CA certificate security incident
[13] Node.js 24.22.1 Oficjalna wersja Zawiera aktualizacje magazynu głównego NSS i odrzuca zmiany zawierające zablokowane łańcuchy certyfikatów klucza publicznego. Node.js 24.22.1 security release
[14] Go Oficjalna wersja zabezpieczeń Opis Aktualizacja filtrowania łańcucha certyfikatów crypto/x509 dla Go 1.27.3/1.26.10. Go 1.27.3 and Go 1.26.10 are released
[15] Oracle JDK Oficjalne instrukcje utylizacji Wyjaśnij krytyczną poprawkę JDK i powiązane środki konfiguracyjne, gdy nie można jej natychmiast zaktualizować. Distrusting eMudhra Intermediate Certificates in Oracle JDK
[16] TLS 1.3 Standard protokołu RFC 8446 Instrukcje dotyczące uwierzytelniania tożsamości, wymiany kluczy tymczasowych i tajemnicy przekazywania znajdują się w dodatku E.1. The Transport Layer Security Protocol Version 1.3
[17] Certyfikat główny związany ze zdarzeniem i dane relacji wystawienia Używane do zrozumienia relacji bezpośredniego emitenta i podpisu krzyżowego; status włączenia magazynu głównego nie może zastąpić najnowszego statusu unieważnienia lub zablokowania klienta. Root certificate relationships JSON