Kluczem była liczba 4: kto decyduje, którym stronom ufa twoje oprogramowanie

To jest artykuł przetłumaczony maszynowo. Oryginalna wersja jest dostępna w języku angielskim.

Ostatnia aktualizacja: 25 października 2026 · 17 min czytania

Mamy tu problem

W sobotę 17 października 2026 roku o 18:05 UTC do programu certyfikatów głównych Chrome’a (Chrome Root Program) wpłynęło zgłoszenie od badacza bezpieczeństwa, którego publicznie przedstawiono tylko jako Wayne’a. Twierdził, że ma klucze prywatne ośmiu urzędów certyfikacji prowadzonych przez eMudhrę, notowaną na giełdzie spółkę z siedzibą w Bengaluru w Indiach. Na dowód podpisał każdym z ośmiu kluczy tę samą krótką wiadomość: „Mamy tu problem – Wayne”.

Nie musiał się nigdzie włamywać. Gdy sprawa wyszła na jaw, badacz bezpieczeństwa Scott Helme opisał, jak te klucze wyglądały. Jednym z nich była po prostu liczba 4. Dwa inne to 56 i 115. Helme powiedział, że odtworzył je wszystkie z ich publicznych certyfikatów na swoim laptopie i że zajęło mu to mniej niż sekundę. Niezależna weryfikacja przeprowadzona przez dziennikarzy potwierdziła, że klucz prywatny stojący za urzędem „EM OV TLS CA – G3C” eMudhry to 4.

Cała ósemka to pośrednie urzędy certyfikacji, robocza warstwa firmy certyfikacyjnej, która podpisuje poświadczenia dla innych. Sześć z nich mogło wystawiać certyfikaty dla stron internetowych i tym sześciu ufały programy certyfikatów głównych Chrome’a, Mozilli, Microsoftu i Apple’a. Pozostałe dwa służyły do podpisywania kodu, czyli wystawiania certyfikatów, którymi producenci oprogramowania podpisują swoje programy, i ufał im Microsoft. Ich klucze wygenerowano nieprawidłowo, więc każdy, kto wiedział, gdzie szukać, mógł je obliczyć z samych certyfikatów, które z założenia są publiczne. Było to możliwe od chwili utworzenia certyfikatów w kwietniu 2025 roku.

O 19:45 UTC, godzinę i czterdzieści minut po nadejściu zgłoszenia, Chrome zdążył już potwierdzić ustalenia i wysłać użytkownikom blokadę. Nikt nie musiał instalować aktualizacji ani ponownie uruchamiać przeglądarki.

Szybkość miała znaczenie ze względu na to, co potrafi taki klucz. Ktoś, kto miałby którykolwiek z sześciu kluczy do certyfikatów stron i mógłby przechwycić czyjeś połączenie, zdołałby podsunąć sfałszowany certyfikat banku, poczty elektronicznej czy dowolnej innej strony, bez względu na to, z usług jakiej firmy certyfikacyjnej korzysta prawdziwa witryna, a oprogramowanie ufające łańcuchowi eMudhry by go przyjęło. Na drodze stały dwa główne zabezpieczenia: publiczny system logów zwany Certificate Transparency, którego część oprogramowania bezwzględnie wymaga, a znaczna część nie, oraz blokady, które poszczególne programy zdążyły na czas otrzymać.

To, czy sfałszowany certyfikat by zadziałał, zależało od decyzji, których zwykle nie widać: kto ręczy za stronę internetową, kto decyduje, że temu poręczycielowi należy wierzyć, i jak szybko można tę wiarę odebrać, gdy poręczyciel okaże się zawodny.

Za co ręczy certyfikat

Certyfikat strony internetowej to mały podpisany dokument, który wiąże nazwę, na przykład adres internetowy banku, z kluczem publicznym. Klucze publiczne występują w parach z kluczami prywatnymi. Klucz prywatny pozostaje tajny i służy do składania podpisów cyfrowych; klucz publiczny pozwala każdemu sprawdzić, że podpis pochodzi od jego partnera. Gdy twoja przeglądarka łączy się ze stroną, strona dowodzi, że ma klucz prywatny pasujący do klucza publicznego w jej certyfikacie. Sam certyfikat stwierdza, że ten klucz publiczny należy do tej nazwy, a urząd certyfikacji, czyli CA, ręczy za to stwierdzenie, podpisując je.

Przed podpisaniem certyfikatu strony CA musi sprawdzić, czy wnioskodawca kontroluje domenę. Jedna z zatwierdzonych metod polega na tym, że wnioskodawca dostaje losową wartość, a CA szuka jej potem w rekordach DNS domeny, publicznej książce adresowej internetu, gdzie umieścić ją mógł tylko ktoś, kto domenę kontroluje. CA może też potwierdzić, że wnioskodawca rzeczywiście ma klucz prywatny, który chce poświadczyć, za pomocą testu technicznego zwanego dowodem posiadania, choć standard, na którym to wszystko się opiera, pozwala mu również poprzestać na słowie wnioskodawcy.

Żadna przeglądarka nie mogłaby sama sprawdzić każdego CA na świecie, więc zaufanie przekazuje się dalej, w łańcuchu. Na szczycie są certyfikaty główne (root), zapisane na liście zwanej magazynem zaufania, którą dostajesz wraz z systemem operacyjnym lub przeglądarką. Certyfikaty główne upoważniają pośrednie urzędy certyfikacji, a te wystawiają certyfikaty, których używają strony internetowe. Gdy twoje oprogramowanie widzi certyfikat strony, podąża za podpisami w górę, od strony przez pośredni CA do certyfikatu głównego, i akceptuje stronę tylko wtedy, gdy łańcuch kończy się na certyfikacie głównym z jego magazynu, każdy podpis się zgadza, certyfikat jest ważny i obejmuje odwiedzaną nazwę, a żadna z pozostałych reguł oprogramowania tego nie zabrania.

Programy certyfikatów głównych, prowadzone przez producentów systemów operacyjnych i przeglądarek, takich jak Apple, Google, Microsoft i Mozilla, sprawdzają urzędy certyfikacji i decydują, które certyfikaty główne trafią do magazynu. Dlatego klucz prywatny pośredniego CA jest tak cenny. Jeśli nie ograniczono go do określonych nazw, a w przypadku eMudhry tego nie zrobiono, pośredni CA może podpisać certyfikat dla dowolnej domeny, a taki certyfikat da się zweryfikować w górę, aż do zaufanego certyfikatu głównego. Klucz samego certyfikatu głównego może pozostać bezpiecznie zamknięty; codzienne podpisywanie wykonuje klucz pośredniego CA, a jeśli on wycieknie, wycieka razem z nim poręczenie certyfikatu głównego.

Nic z tego nie mówi, czy strona internetowa jest uczciwa, choć ikonę kłódki w przeglądarce powszechnie się tak odczytuje. Gdy Google zbadał tę kwestię w 2021 roku, tylko 11% uczestników poprawnie rozumiało, co oznacza kłódka, a niemal wszystkie strony phishingowe korzystały z HTTPS, więc też ją wyświetlały. W 2023 roku Google ogłosił, że Chrome zastąpi kłódkę inną ikoną. Podstawowy certyfikat mówi tylko tyle, że połączenie prowadzi do tego, kto ma klucz dla danej nazwy. Niektóre certyfikaty podają też organizację stojącą za stroną; żaden nie ręczy za jej intencje.

Jest jeszcze jedna warstwa. Mechanizm Certificate Transparency, opisany przez inżynierów Google’a w 2013 roku, umieszcza certyfikaty w publicznych logach, w których każdy może skontrolować, co wystawił dany CA. Jego twórcy zakładali, że oprogramowanie klienckie w końcu zacznie odrzucać każdy certyfikat, którego nie zalogowano, tak by certyfikat trzymany poza logami, wystawiony przez CA czy przez złodzieja z kluczem CA, został odrzucony. Chrome robi to domyślnie przy każdym połączeniu, które opiera się na jego magazynie zaufania.

Ostrzeżenie bez odpowiedzi

Zasady tworzenia kluczy CA są surowe. W przypadku kluczy certyfikatów głównych i niektórych kluczy pośrednich Baseline Requirements, branżowy regulamin, który programy certyfikatów głównych przeglądarek i urzędy certyfikacji utrzymują wspólnie, nakazują CA postępować według spisanego skryptu generowania kluczy i zapewnić, by ceremonię obserwował wykwalifikowany audytor albo by nagrano ją w całości na wideo. Każdy klucz CA musi być generowany wspólnie przez kilka osób, z których żadna nie ma całej wiedzy potrzebnej, by zrobić to w pojedynkę.

30 kwietnia 2025 roku eMudhra utworzyła partię 24 certyfikatów pośrednich. Należały do trzech serii, oznaczonych literami A, B i C, miały dwa rodzaje kluczy, RSA i klucze na krzywej eliptycznej typu P-384, oraz cztery przeznaczenia. Osiem złamanych kluczy to wszystkie klucze P-384 z serii B i C. Wszystkich osiem było liczbami całkowitymi mniejszymi niż 256. Każdy z nich, zapisany w całości, był długim ciągiem zer z czymś w ostatnim bajcie.

Dlaczego ten klucz dało się odgadnąć

Klucz prywatny na krzywej P-384 to po prostu liczba, wybrana losowo z przedziału od 1 do ustalonej granicy, która sama ma 384 bity długości. Klucz publiczny oblicza się z klucza prywatnego za pomocą rachunku, który łatwo wykonać w przód, a przy porządnie losowej liczbie nie sposób go odwrócić. Klucz publiczny jest zapisany w certyfikacie. Liczba 4 to całkowicie poprawny klucz prywatny; to także jedna z pierwszych liczb, jakie ktokolwiek by wypróbował. Mozilla zwróciła uwagę, że tak małe klucze można odzyskać niemal natychmiast: wystarczy obliczyć klucze publiczne dla 1, 2, 3 i tak dalej aż do 256 i porównać każdy z tym z certyfikatu. Gdy dwa się zgadzają, klucz prywatny to liczba, od której się zaczęło. Porządnie losowy klucz nie daje takiej krótkiej listy. Jak ujął to Scott Helme, przedział mieści mniej więcej 10 do potęgi 115 możliwości, „więc nikt nigdy nie będzie tego przeszukiwał”. Dennis Jackson z Mozilli powierzył to zadanie także agentom AI działającym lokalnie. Odzyskały klucz za pierwszym podejściem, na podstawie prostego polecenia.

Jak ceremonia generowania kluczy mogła wyprodukować tak małe liczby? Według wstępnego wyjaśnienia eMudhry, opublikowanego 19 października, skrypt użyty tamtego dnia zawierał błąd. Firma twierdzi, że zatwierdziła jednorazową zmianę zwykłej procedury, by przetestować eksport kluczy, że błąd w kodzie sprawił, iż sprzęt utworzył obok właściwych kluczy drugą, słabszą parę, i że słabe klucze zostały potem przez pomyłkę użyte do złożenia wniosków o certyfikaty, bo miały podobnie wyglądające etykiety. Według firmy klucze wygenerowano w sprzętowych modułach bezpieczeństwa firmy Utimaco, odpornych na manipulację urządzeniach przeznaczonych do tworzenia i strzeżenia kluczy CA.

eMudhra sama nazywa to wyjaśnienie wstępnym, a główna zagadka pozostaje w nim otwarta. Jeden z komentujących w publicznym zgłoszeniu błędu Mozilli zauważył, że albo klucze wytworzono poza bezpiecznym sprzętem i wbrew zasadom do niego wczytano, albo sprzęt dało się w jakiś sposób skonfigurować tak, by sam tworzył wadliwe klucze. Inny uczestnik dyskusji, na publicznej liście mailingowej Mozilli, zasugerował, bez potwierdzenia, że oprogramowanie wzięło za sam klucz niewielki plik wskazujący na prawdziwy klucz w sprzęcie. Mozilla, choć próbowała znacznie usilniej, nie zdołała odzyskać kluczy P-384 serii A z tej samej partii. 20 października wysłała eMudhrze pytania z 24-godzinnym terminem; do 23 października nie dostała odpowiedzi, a to, jak powstały słabe klucze, pozostało niewyjaśnione.

Udokumentowane jest natomiast to, że problem dał o sobie znać ponad rok wcześniej. W czerwcu 2025 roku publiczny serwis monitorujący wykazał, że eMudhra udostępnia sześć list unieważnionych certyfikatów z nieprawidłowymi podpisami dla tych samych certyfikatów pośrednich. Lista unieważnionych certyfikatów, czyli CRL, to podpisany rejestr certyfikatów, które CA unieważnił, a jej podpis musi dać się zweryfikować kluczem publicznym z certyfikatu tego CA. W ówczesnym raporcie eMudhra napisała, że pierwsze ostrzeżenie wysłała jej e-mailem 3 czerwca 2025 roku Sectigo, inna firma certyfikacyjna, i że wewnętrzne filtry zatrzymały wiadomość w kwarantannie, więc nikt jej nie zobaczył. Wadliwe listy wymieniono 6 czerwca.

W październiku 2026 roku eMudhra wyjaśniła, na czym polegała tamta poprawka. Listy podpisano najpierw oryginalnymi, porządnie losowymi kluczami; ponieważ certyfikaty zawierały publiczne połówki słabych kluczy, te podpisy nie przechodziły weryfikacji, więc firma podpisała listy ponownie wadliwymi kluczami. W czerwcu 2025 roku eMudhra miała zatem dowód, że jej certyfikaty nie pasują do kluczy, których, jak sądziła, używa, i naprawiła listy.

Program certyfikatów głównych Chrome’a zapytał, dlaczego eMudhra po prostu ponownie podpisała listy, zamiast wstrzymać działalność, zbadać, skąd dla tych CA wzięły się dwie pary kluczy, i unieważnić certyfikaty. eMudhra twierdzi, że jej certyfikaty główne i wystawiające urzędy certyfikacji przeszły niezależne audyty dwa lata z rzędu. 14 października 2026 roku, trzy dni przed zgłoszeniem Wayne’a, opublikowała listę unieważnionych certyfikatów dla innego certyfikatu głównego, emSign Root TLS CA – G1, której podpis również nie dawał się zweryfikować.

Dwa rodzaje wyłącznika

Pierwszy ruch Chrome’a był szybki, bo wymierzono go w klucze. Chrome prowadzi listę blokad zwaną CRLSet, którą Google rozsyła do przeglądarek w tle. Aktualizacja wdrożona o 19:45 UTC blokowała odciski kluczy publicznych sześciu certyfikatów pośrednich. Ponieważ blokada wskazywała klucze, obejmowała każdy certyfikat, który ich używał, także te, które fałszerz mógłby utworzyć później. Mozilla zablokowała certyfikaty w Firefoksie za pomocą własnej listy, OneCRL, i skończyła o 22:59 UTC. OneCRL działa bez aktualizacji Firefoksa, a nawet bez jego ponownego uruchomienia.

Lista rozsyłana w tle chroni tylko to oprogramowanie, które ją otrzymuje. 20 października Mozilla wydała aktualizację Firefoksa dla użytkowników, u których konfiguracja nie pozwoliła liście blokad dotrzeć, a później poprawkę dla niektórych profili Firefoksa na Androida, które jej nie stosowały. Google zaczął wysyłać równoważną blokadę na urządzenia z Androidem przez Usługi Google Play około 22:00 UTC w poniedziałek 19 października i następnego dnia poinformował, że większość z nich ją otrzymała. Microsoft i Apple poszły w ich ślady w ciągu kilku dni, choć opublikowane relacje różnią się co do dokładnej daty działania Apple’a.

Ruszyły się też urzędy certyfikacji. eMudhra do 09:38 UTC 18 października oznaczyła wszystkie osiem certyfikatów jako unieważnione, podając jako powód kompromitację CA. Sectigo, która podpisała krzyżowo te certyfikaty pośrednie, 19 października zakończyła unieważnianie swoich certyfikatów krzyżowych. Chrome doprowadził też do tego, by logi Certificate Transparency odrzucały każdy certyfikat prowadzący łańcuchem do skompromitowanych CA, tak że sfałszowany certyfikat nie mógł już zebrać wpisów w logach, których wymaga oprogramowanie sprawdzające CT.

Cięższym narzędziem jest usunięcie certyfikatu głównego, który upoważnił certyfikaty pośrednie. 20 października, odnotowawszy, że kilka osób zdążyło już niezależnie odzyskać klucze, Mozilla zdecydowała o awaryjnym usunięciu ze swojego magazynu zaufania certyfikatu emSign ECC Root CA – G3, certyfikatu głównego eMudhry stojącego nad złamanymi certyfikatami pośrednimi. Firefox tego nie potrzebował; OneCRL już chronił Firefoksa. Chodziło o wszystkich pozostałych, którzy korzystają z listy certyfikatów głównych Mozilli albo z listy od niej pochodnej, bez OneCRL. Mozilla ostrzegła, że ta zmiana sprawi, iż niektóre serwery staną się dla tych użytkowników niedostępne, dopóki nie przejdą na nowe łańcuchy certyfikatów.

Chrome usunął ten sam certyfikat główny ze swojego magazynu. Google spodziewał się, że zmiana dotrze do wszystkich urządzeń korzystających z Chrome Root Store we wtorek 27 października 2026 roku rano czasu pacyficznego, a wcześniej do testowych wersji Canary i Beta. Google powiedział wprost, że w efekcie niektóre prawowite certyfikaty prowadzące łańcuchem do tego certyfikatu głównego przestaną działać w Chrome.

Oba wyłączniki różnią się tym, co wyłapują i komu szkodzą. Usunięcie certyfikatu głównego przecina każdą ścieżkę, która przez niego prowadzi, także ścieżki uczciwych stron, ale omija ścieżki przez inne certyfikaty główne, a certyfikaty pośrednie eMudhry miały jeszcze jedną. Sectigo poświadczyła je krzyżowo, łącząc te same klucze z certyfikatem głównym AAA Certificate Services, wystawionym pod marką Comodo. Chrome wyrzucił ten certyfikat główny w kwietniu 2025 roku, ale niektóre systemy wciąż mu ufały: Ubuntu usunęło emSign ECC Root CA – G3 ze wszystkich wspieranych wydań, a ze starszych wydań, które wciąż go zawierały, także certyfikat główny Comodo. Blokada przypisana do samego certyfikatu pośredniego wyłapuje wszystkie drogi naraz. Takie podejście przyjął język programowania Go: od wersji wydanych 19 października mechanizm sprawdzania certyfikatów w Go odfiltrowuje każdy łańcuch zawierający jeden ze skompromitowanych certyfikatów pośrednich, bez względu na to, na jakim certyfikacie głównym się kończy.

Aktualizacja dla wszystkich pozostałych

18 października Mozilla napisała w swoim publicznym zgłoszeniu błędu, że martwi ją szerszy ekosystem, bo wiele urządzeń końcowych nie ma skutecznego sposobu na otrzymywanie informacji o unieważnieniach. Przeglądarki miały swoje listy rozsyłane w tle. Wiele innego oprogramowania nawiązującego bezpieczne połączenia nie ma niczego podobnego.

Strona śledząca incydent, publiczna witryna założona przez Dennisa Jacksona z Mozilli, jasno wyliczała, kto jest narażony. Aplikacje i biblioteki dostarczające własny zestaw zaufanych certyfikatów głównych potrzebowały aktualizacji oprogramowania. Podobnie aplikacje zbudowane na Electronie, frameworku, na którym działają programy desktopowe takie jak Slack i Discord; poprawkę Electrona przejmują one dopiero wtedy, gdy zostaną przebudowane na załatanym wydaniu.

Część luk tkwiła we własnych plikach zaufania systemów operacyjnych. Jak podawała 22 października strona incydentu, macOS blokował skompromitowane certyfikaty pośrednie, ale jego wbudowane narzędzia wiersza poleceń, w tym curl, git i python3, sprawdzały certyfikaty względem osobnego pliku, nie biorąc pod uwagę unieważnień, a ten plik nie został zaktualizowany. W Ubuntu magazyn zaufania Javy wymagał po aktualizacji systemu ręcznej interwencji z powodu problemu z synchronizacją, którego Canonical do 22 października nie rozwiązał, a przeglądarki zainstalowane jako pakiety snap w ogóle nie korzystały z systemowego magazynu.

Inne luki tkwiły w bibliotekach, które mają własne listy. Go dostarczyło poprawkę w wydaniach bezpieczeństwa 1.27.3 i 1.26.10, pod numerem CVE-2026-111943. Szeroko używany pythonowy pakiet certyfikatów certifi 18 października usunął wszystkie cztery certyfikaty główne emSign, a potem przywrócił trzy, których problem nie dotyczył, w wydaniu oznaczonym 2026.10.19; automatyczne wydanie z 23 października znów usunęło dwa z tych trzech. A niektóre produkty mogli naprawić tylko ich producenci: zespół bezpieczeństwa Talos firmy Cisco wskazał wirtualne sieci prywatne jako te, które prawdopodobnie będą wymagały aktualizacji.

Pod tym wszystkim leżał mechanizm Certificate Transparency. Większość przeglądarek go egzekwuje, ale wielu klientów spoza świata przeglądarek, w tym curl, tego nie robi. Sfałszowany certyfikat zrobiony jednym z kluczy eMudhry i nigdy niezalogowany zostałby odrzucony przez Chrome’a, ale mógłby zostać przyjęty przez tych klientów, o ile nadal ufaliby łańcuchowi eMudhry i nic innego by go nie zatrzymało, na przykład aplikacja, która akceptuje tylko znane certyfikaty własnych serwerów.

Są mocne argumenty za tym, że system zadziałał. Przed blokadą Chrome’a z 17 października w Certificate Transparency nie zalogowano żadnego certyfikatu strony internetowej prowadzącego łańcuchem do sześciu certyfikatów pośrednich, więc od utworzenia kluczy w kwietniu 2025 roku do tej blokady żaden sfałszowany za ich pomocą certyfikat nie mógł zostać użyty przeciwko klientom egzekwującym CT. Talos podał, że według stanu na 21 października, godz. 14:00 UTC, nie zaobserwował żadnego złośliwego użycia w praktyce. eMudhra twierdzi, że tylko jeden z dotkniętych certyfikatów pośrednich trafił kiedykolwiek do użytku produkcyjnego i że żaden z nich nigdy nie wystawił certyfikatu stronie internetowej ani producentowi oprogramowania.

W odniesieniu do oprogramowania, które przez cały czas egzekwowało CT, ten argument jest słuszny, a ochrona wynikała ze stałej reguły, nie z weekendowej akcji ratunkowej. Zasięg tej ochrony jest węższy, niż sugeruje hasło „system zadziałał”. Firefox na Androida zaczął egzekwować Certificate Transparency dopiero od wersji 145, udostępnionej użytkownikom po raz pierwszy 11 listopada 2025 roku. Aplikacje na Androida mogą korzystać z wbudowanych mechanizmów sprawdzania CT dopiero od Androida 16, a domyślnie dostają je tylko wtedy, gdy zbudowano je dla Androida 17.

Akcja ratunkowa miała znaczenie także dla tego, co przyszło potem. Pierwsze powiadomienie Mozilli skierowane do opiekunów pochodnych magazynów zaufania celowo nie wspominało, że klucze może odzyskać każdy. Do 20 października nie miało to już większego znaczenia: kilka osób niezależnie je odzyskało, a Helme opublikował wszystkie osiem tych wartości. Gdy klucze stały się praktycznie publiczne, to blokady i odrzucenia w logach CT stały między nimi a każdym nowym fałszerstwem. Do 24 października nie opublikowano niczego, co pokazywałoby, czy między kwietniem 2025 a październikiem 2026 roku atakujący użyli wadliwych kluczy przeciwko klientom, którzy nie sprawdzają CT.

Kto trzyma rękę na wyłączniku

Decyzje o tym, którym certyfikatom głównym ufają przeglądarki i systemy operacyjne, należą do programów certyfikatów głównych, a ich zasady dają właścicielom dużą swobodę. Polityka Chrome’a stanowi, że Google włącza lub usuwa certyfikaty „według własnego wyłącznego uznania” i że każdy włączony certyfikat musi przynosić użytkownikom korzyść przewyższającą ryzyko jego utrzymania. Polityka Mozilli stanowi, że może ona wyłączyć lub usunąć certyfikat według własnego wyłącznego uznania, w dowolnym momencie i z dowolnego powodu. Mozilla zaznacza też, że nie pobiera opłat za włączenie.

Z tej swobody korzystano na różne sposoby. W 2014 roku, gdy indyjskie National Informatics Centre wystawiło nieautoryzowane certyfikaty dla kilku domen Google’a, Chrome nie wyrzucił stojącego nad nim certyfikatu głównego India CCA. Ograniczył ten certyfikat do listy domen indyjskich. Trzy lata wcześniej reakcja wobec holenderskiego urzędu certyfikacji była całkowita: 3 września 2011 roku Google postanowił odrzucać wszystkie urzędy certyfikacji prowadzone przez DigiNotar, a siedemnaście dni później holenderski sąd ogłosił upadłość spółki.

DigiNotar, 2011

Włamanie do DigiNotar wyszło na jaw dzięki zwykłemu użytkownikowi. 28 sierpnia 2011 roku klient irańskiego dostawcy internetu ParsOnline napisał na forum pomocy Google'a o ostrzeżeniu dotyczącym certyfikatu, które pokazał mu Chrome. Certyfikat podawał się za certyfikat Google'a i pochodził od DigiNotar, firmy, do której systemów ktoś się włamał. Śledczy z firmy bezpieczeństwa Fox-IT, pracujący na zlecenie rządu holenderskiego, ustalili później, że fałszywy certyfikat obejmujący adresy google.com posłużył do zakrojonego na szeroką skalę ataku na około 300 000 użytkowników, niemal wszystkich w Iranie, których ruch do Google'a był prawdopodobnie przechwytywany lub przekierowywany. Szacunek ten wyprowadzili z 298 140 różnych adresów sieciowych, które sprawdzały status sfałszowanego certyfikatu, i nazwali go bardzo zgrubnym przybliżeniem. 3 września holenderski rząd publicznie cofnął zaufanie do DigiNotar. Pod koniec października 2026 roku nie było doniesień o żadnym ataku z użyciem kluczy eMudhry. DigiNotar pokazał, do czego zdolna jest moc podpisu urzędu certyfikacji w rękach kogoś, kto jest gotów z niej skorzystać.

Włączenie do magazynu zaufania Chrome’a, napisał Google, wymaga od właściciela CA nieustannego wykazywania kompetencji technicznych i rygoru operacyjnego potrzebnych do ochrony użytkowników Chrome’a, i dodał, że „wnikliwie bada”, czy pozostałe certyfikaty CA eMudhry powinny w nim zostać. 23 października eMudhra napisała w publicznym zgłoszeniu błędu, że intensywna uwaga mediów społecznościowych oraz analizy inwestorów i klientów sprawiły, że rzetelna analiza zdarzenia stała się „praktycznie niemożliwa”. Chrome odpowiedział tego samego dnia, że to żadne usprawiedliwienie i że eMudhra wciąż ma zobowiązania wobec „miliardów” ludzi polegających na systemie, narażonych przez jej błąd.

Zarząd eMudhry już 22 października postanowił wycofać się z globalnego rynku certyfikatów SSL/TLS. Firma twierdzi, że ta działalność to bardzo niewielka część jej operacji.

Te same firmy wspólnie z urzędami certyfikacji ustalają też reguły w organizacji o nazwie CA/Browser Forum. W głosowaniu zakończonym 11 kwietnia 2025 roku, dziewiętnaście dni przed tym, jak eMudhra wygenerowała wadliwe klucze, Apple, Google, Microsoft i Mozilla zagłosowały za skróceniem czasu ważności certyfikatów stron internetowych, a za opowiedziało się także 25 wystawców certyfikatów, wśród nich eMudhra. Projekt wychodził z założenia, że unieważnianie nie chroni należycie ludzi w skali internetu, a wygasanie owszem. Stwierdzono w nim: „Okresy ważności certyfikatów i ich egzekwowanie przez strony ufające są niezwykle niezawodne”. Zgodnie z zasadami obowiązującymi w październiku 2026 roku certyfikaty stron internetowych wystawione od 15 marca 2026 roku mogą być ważne najwyżej 200 dni, od 15 marca 2027 roku 100 dni, a od 15 marca 2029 roku 47 dni.

Te limity dotyczą certyfikatów używanych przez strony internetowe, według daty ich wystawienia. Tekst reguły nie ogranicza czasu ważności certyfikatów CA, które znalazły się w centrum tego incydentu, więc krótszy czas ważności nie doprowadziłby do wygaśnięcia certyfikatów pośrednich eMudhry. Unieważnianie też nie zniknęło. Let’s Encrypt, bezpłatny urząd certyfikacji, w sierpniu 2025 roku wyłączył swoją usługę OCSP, która pozwalała przeglądarkom pytać o certyfikaty jeden po drugim, bo każde zapytanie zdradzało CA, która strona jest odwiedzana i z jakiego adresu sieciowego. Awaryjne blokady z 17 października były w istocie listami unieważnień, które producenci przeglądarek sami ułożyli i rozesłali.

Ten układ oddaje ogromną władzę w ręce kilku prywatnych podmiotów, w większości amerykańskich. Przypadek eMudhry pokazuje, jak ta władza jest sprawowana: w otwartym zgłoszeniu błędu, gdzie każdy może przeczytać pytania, terminy i odpowiedzi, z uzasadnieniami publikowanymi przez firmy, które usuwają certyfikaty.

Certyfikaty, które muszą się przenieść

Usunięcie certyfikatu głównego ogłasza się szybko, a przyswaja powoli. Według stanu na 21 października Chrome naliczył około 30 800 niewygasłych precertyfikatów prowadzących łańcuchem do emSign ECC Root CA – G3. Precertyfikat to kopia certyfikatu przesyłana do logów Certificate Transparency przed jego wystawieniem, więc liczba ta mówi o zalogowanych certyfikatach, a nie o stronach, które wciąż ich używają. Spośród nich 30 791, czyli 99,9%, pochodziło z dwóch certyfikatów pośrednich należących do InCommon, usługi certyfikacyjnej prowadzonej przez Internet2, amerykańską organizację sieciową. Tych dwóch nie było wśród ośmiu złamanych certyfikatów pośrednich; po prostu wisiały pod usuwanym certyfikatem głównym. eMudhra szacowała, że przenieść trzeba około 30 000 certyfikatów, niemal wyłącznie wystawionych za pośrednictwem ACME, protokołu, który pozwala serwerom automatycznie zamawiać i odnawiać certyfikaty. eMudhra przestała wystawiać certyfikaty pod certyfikatem głównym G3 20 października.

Automatyzacja sama tego nie rozwiązuje. Standardowi klienci ACME wymieniają certyfikat dopiero wtedy, gdy nadejdzie termin odnowienia, chyba że obsługują nowsze rozszerzenie, które pozwala CA poprosić o wcześniejsze odnowienie, albo ktoś zainterweniuje ręcznie. Chrome zwrócił 21 października uwagę, że przejście z hierarchii eMudhry opartej na krzywych eliptycznych na jej hierarchię RSA może też wymagać zmiany ustawień klienta.

Certyfikaty InCommon pochodzą od CertiNext, dostawcy, którego spółką matką jest eMudhra. 22 października InCommon poinformował subskrybentów, że wielu z nich spędziło tydzień na reagowaniu na błędy certyfikatów i planowaniu w obliczu zmian, na które nie mają wpływu, po udanej, ale wyczerpującej migracji wiosną i latem. Jego rada z tamtego ranka brzmiała: ponownie wystawić dotknięte certyfikaty jako certyfikaty RSA, dopóki nie zostanie przywrócone wystawianie certyfikatów na krzywych eliptycznych.

eMudhra oświadczyła 20 października, że jedyną alternatywą dla jej klientów G3 są certyfikaty pośrednie prowadzące łańcuchem do jej certyfikatu głównego RSA, emSign Root CA – G1. Mozilla poinformowała tego samego dnia, że na razie nie odbiera zaufania G1. G1 był wśród pozostałych certyfikatów eMudhry, które, jak Chrome podał 20 października, wnikliwie badał; do 24 października Chrome nie ogłosił żadnej decyzji. 21 października Chrome poprosił eMudhrę o potwierdzenie, czy klienci są przenoszeni na G1, do hierarchii innej firmy, czy do obu.

Aktualizacja InCommon z wieczoru 22 października rozwiązała doraźny problem. Certyfikaty na krzywych eliptycznych znów były wystawiane, teraz w łańcuchu do certyfikatu głównego G1, a dotychczasowi klienci mogli je odnawiać bez żadnych zmian w ustawieniach. W tej samej aktualizacji podano, że eMudhra za 30 dni, w terminie, który potwierdzi CertiNext, przestanie wystawiać certyfikaty z jakiegokolwiek certyfikatu pośredniego powiązanego z jej publicznymi certyfikatami głównymi, oraz że InCommon pracuje nad ścieżką zastępczą. Dla subskrybentów, którzy wiosną i latem przeszli jedną wyczerpującą migrację, usunięcie jednego certyfikatu głównego oznaczało początek kolejnej.

Powiązane artykuły

• Jak daleko amerykańska lista sankcyjna sięga w głąb trybunału w Hadze
• Co dalej z bitcoinem?
• Jak naprawdę działa AI: co wiedzą twórcy, a czego nie mówią nagłówki

Dalsza lektura

Jako partner Amazon Eikleaf zarabia na kwalifikujących się zakupach. Poniższe linki do książek są linkami partnerskimi: jeśli dokonasz zakupu za ich pośrednictwem, możemy otrzymać niewielką prowizję, bez dodatkowych kosztów dla Ciebie.

Polecane filmy

Zastrzeżenie dotyczące generatywnej AI

Niektóre treści na tej stronie zostały wygenerowane i/lub zredagowane z pomocą generatywnej sztucznej inteligencji.

Media

HTTPS i kłódka na pasku adresu strony internetowej – Wikimedia Commons (Fot.: Santeri Viinamäki, CC BY-SA 4.0)

Sprzętowy moduł bezpieczeństwa nCipher nShield F3 – Wikimedia Commons (Fot.: Alexander Klink, CC BY 3.0)

Siedziba Googleplex – Wikimedia Commons (Fot.: Asoundd, CC BY-SA 4.0)

Najważniejsze źródła i bibliografia

Mozilla Bugzilla. „Bug 2083449: eMudhra: Private key compromise of Intermediate Certificates.” Opened 18 October 2026, comments to 23 October 2026. https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

Chrome and Android Security Teams. „Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates.” Google, The Keyword, 20 October 2026. https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/

Mozilla dev-security-policy mailing list. „Compromised eMudhra Intermediate Certificates” thread, posts by Dennis Jackson (Mozilla) and the Chrome Root Program, 20 October 2026, and by Wayne and Corey Bonnell, 21 October 2026. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE

Jackson, Dennis. „eMudhra Intermediate CA Compromise.” Incident tracking site, 20 October 2026, updated 22 October 2026. https://emudhra.we-have-a-problem.com/

InCommon (Internet2). „Moving Forward Together: InCommon Certificate Service Update.” Updates of 22 October 2026. https://incommon.org/about/news/incommon-certificate-service-update

InCommon (Internet2). „InCommon Certificate Service FAQ.” Last updated 22 October 2026, 18:30 ET. https://incommon.org/certificates

Stanescu, Luci. „eMudhra CA compromise fixes available.” Ubuntu blog, Canonical, 20 October 2026, updated 22 October 2026. https://ubuntu.com/blog/emudhra-ca-compromise-fixes-available

Canonical. „USN-8944-1: ca-certificates update” and „USN-8944-2: ca-certificates update.” Ubuntu security notices, 20 October 2026. https://ubuntu.com/security/notices/USN-8944-1 and https://ubuntu.com/security/notices/USN-8944-2

Go team. „[security] Go 1.27.3 and Go 1.26.10 are released.” golang-announce, posted 20 October 2026 (releases dated 19 October 2026). https://groups.google.com/g/golang-announce/c/66pojueaQek

Go project. „Release History.” Accessed 24 October 2026. https://go.dev/doc/devel/release

certifi. „Remove emsign (#437),” „Restore unaffected emSign roots (#439) (#440)” and „2026.10.23 (#445).” python-certifi repository, 18, 20 and 23 October 2026. https://github.com/certifi/python-certifi/commit/5cb238caeeb6c30ec1a7309ad3e16a5aa7b10ce8 and https://github.com/certifi/python-certifi/commit/662df63d7906df66f1f07c0751a3dfe9da14d914 and https://github.com/certifi/python-certifi/commit/b60466c9f2882d9cf088943c650b0faac06c080c

Cisco Talos. „Compromised eMudhra intermediate certificates.” Talos Intelligence blog, 21 October 2026. https://blog.talosintelligence.com/compromised-intermediate-certificates/

eMudhra Limited. „eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA.” 21 October 2026. https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca

eMudhra Limited. „eMudhra to exit global SSL/TLS certificate business.” 22 October 2026. https://emudhra.com/en/press-release/emudhra-to-exit-global-ssl-tls-certificate-business

Abrams, Lawrence. „Mozilla, Google, Apple block compromised eMudhra CA certificates.” BleepingComputer, 20 October 2026. https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/

Helme, Scott. „Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds.” 20 October 2026. https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/

Sharwood, Simon. „Indian certification authority eMudhra’s private keys compromised – one of them was the number '4′.” The Register, 20 October 2026. https://www.theregister.com/a/5304312

Mozilla Bugzilla. „Bug 1970728: eMudhra: Invalid CRL signatures.” June 2025. https://bugzilla.mozilla.org/show_bug.cgi?id=1970728

Mozilla. „Firefox for Android 145.0 release notes.” 11 November 2025. https://www.firefox.com/en-US/firefox/android/145.0/releasenotes/

Cooper, D., et al. „RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.” IETF, May 2008. https://www.rfc-editor.org/rfc/rfc5280

Laurie, B., Langley, A., and Kasper, E. „RFC 6962: Certificate Transparency.” IETF, June 2013. https://www.rfc-editor.org/rfc/rfc6962

CA/Browser Forum. „Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.3.1.” 4 October 2026, sections 3.2.2.4.7, 6.1.1.1 and 6.3.2. https://github.com/cabforum/servercert/blob/3574ae809e5f909b58ee4c26b7bac4a3b9e78421/docs/BR.md

CA/Browser Forum. „Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods.” 11 April 2025. https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/

Google. „Chrome Root Program Policy, Version 1.8.” Last updated 5 February 2026. https://googlechrome.github.io/chromerootprogram/crp/policy/

Mozilla. „Mozilla Root Store Policy, Version 3.1.” Effective 1 July 2026. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Aas, Josh. „OCSP Service Has Reached End of Life.” Let’s Encrypt, 6 August 2025. https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life/

Adrian, David, Serena Chen, Joe DeBlasio, Emily Stark and Emanuel von Zezschwitz. „An update on the lock icon.” Chromium Blog, May 2023. https://blog.chromium.org/2023/05/an-update-on-lock-icon.html

von Zezschwitz, Emanuel, Emily Margarete Stark and Serena Chen. „’It builds trust with the customers’ – Exploring User Perceptions of the Padlock Icon in Browser UI.” SecWeb 2022, IEEE. https://research.google/pubs/it-builds-trust-with-the-customers-exploring-user-perceptions-of-the-padlock-icon-in-browser-ui/

Android Developers. „Network security configuration: Certificate transparency.” Accessed 24 October 2026. https://developer.android.com/privacy-and-security/security-config

Langley, Adam. „Maintaining digital certificate security.” Google Online Security Blog, July 2014. https://security.googleblog.com/2014/07/maintaining-digital-certificate-security.html

Adkins, Heather. „An update on attempted man-in-the-middle attacks.” Google Online Security Blog, 29 August 2011, updated 3 September 2011. https://security.googleblog.com/2011/08/update-on-attempted-man-in-middle.html

Fox-IT. „Black Tulip: Report of the investigation into the DigiNotar Certificate Authority breach.” 13 August 2012. https://zoek.officielebekendmakingen.nl/blg-191225.pdf