Kompromitacja kluczy urzędu certyfikacji eMudhra: co firmy powinny sprawdzić i naprawić już teraz

W sobotę 17 października 2026 badacz bezpieczeństwa zgłosił, że osiem pośrednich urzędów certyfikacji prowadzonych przez eMudhra, indyjski urząd certyfikacji, miało klucze prywatne, które każdy mógł wyliczyć z publicznych certyfikatów. Każdy z tych kluczy był liczbą mniejszą niż 256. Jeden z nich był po prostu liczbą 4. Sześć z ośmiu mogło wystawiać certyfikaty TLS, którym ufają Apple, Google, Microsoft i Mozilla; pozostałe dwa mogły podpisywać oprogramowanie dla Windows.

Chrome zablokował sześć kluczy TLS godzinę i czterdzieści minut po zgłoszeniu, a Firefox tego samego wieczoru. Dla osób przeglądających strony WWW zagrożenie minęło jeszcze w sobotę w nocy.

Dla całej reszty nie minęło. Serwery, kontenery, aplikacje Java, skrypty w Pythonie, integracje płatności i urządzenia podłączone do sieci sprawdzają certyfikaty według własnej kopii listy zaufanych urzędów, a większość tych kopii zmienia się dopiero wtedy, gdy ktoś zainstaluje aktualizację. Do tego czasu certyfikat dla dowolnej domeny podpisany jednym z tych kluczy przechodzi jako prawdziwy, a same klucze są publicznie znane od 20 października.

W tym samym tygodniu GoDaddy zaczął unieważniać 404 607 certyfikatów, ponieważ zapisane w nich informacje o polityce certyfikacji nie zgadzały się z jego własnymi opublikowanymi dokumentami. Klienci musieli sami pobrać i zainstalować certyfikaty wystawione w ich miejsce.

Ten poradnik jest dla osób, które muszą odpowiedzieć na pytanie „czy nas to dotyczy?”: kierowników IT i utrzymania, CTO oraz założycieli, których biznes stoi na stronie internetowej, API albo produkcie podłączonym do sieci. Opisuje, co się stało, na podstawie dokumentacji incydentu opublikowanej przez Mozillę, Google, eMudhra, GoDaddy i producentów oprogramowania; co sprawdzić dziś; co zaktualizować w tym tygodniu; i co wdrożyć, żeby następny incydent tego rodzaju był rutyną. Wszystko, co tu piszemy, jest aktualne na 22 października 2026, a incydent nie jest jeszcze zamknięty.

Co się stało

eMudhra utworzyła osiem certyfikatów pośrednich podczas ceremonii generowania kluczy 30 kwietnia 2025. Jej wyjaśnienie, zamieszczone 19 października w zgłoszeniu incydentu w bugtrackerze Mozilli: test kroku opakowania i rozpakowania klucza (key wrap i unwrap), zatwierdzony jako odstępstwo od zwykłej procedury, miał wadę, przez którą w sprzętowym module bezpieczeństwa (HSM) obok zamierzonych kluczy powstał drugi, słaby zestaw kluczy. Etykiety były podobne, słabych kluczy omyłkowo użyto do utworzenia żądań certyfikatów, a eMudhra podpisała je swoim certyfikatem głównym (root). Te same żądania trafiły do Sectigo, które 14 maja 2025 podpisało krzyżowo wszystkie osiem swoim certyfikatem głównym AAA Certificate Services. eMudhra podaje, że „nie potwierdziła jeszcze dokładnej przyczyny źródłowej”.

Mozilla opisała skutek tak: „Klucze prywatne P384 to losowo wybrane liczby całkowite z przedziału od 1 do rzędu grupy. Wszystkie 8 kluczy, których dotyczy problem, to liczby całkowite mniejsze niż 256”. Mozilla otrzymała zgłoszenie o 20:06 UTC i o 21:48 sama odtworzyła klucze, „bez jakiejkolwiek wiedzy o metodzie, której użył pierwotny zgłaszający”. Badacz podaje, że znalazł je otwartoźródłową biblioteką paranoid_crypto od Google, „w standardowej konfiguracji”. Słabe klucze przez prawie 18 miesięcy były częścią publicznie zaufanych łańcuchów.

Osiem certyfikatów:

Każdy klucz występuje w dwóch certyfikatach. Jeden wystawił emSign Root TLS CA - G3 lub emSign Root CS CA - G3 należący do eMudhra, a łańcuch obu prowadzi do emSign ECC Root CA - G3; drugi to certyfikat krzyżowy Sectigo wystawiony z AAA Certificate Services. Ta druga ścieżka ma znaczenie, bo niektóre magazyny zaufanych certyfikatów (trust store), które nigdy nie zawierały certyfikatu głównego eMudhra, nadal ufają temu staremu certyfikatowi głównemu Sectigo.

Czy ktoś został zaatakowany?

Nikt nie zgłosił nadużycia, a w przypadku przeglądarek jest dobry powód, by sądzić, że do niego nie doszło. Chrome, podobnie jak inne aplikacje klienckie egzekwujące Certificate Transparency (CT), akceptuje certyfikat tylko wtedy, gdy został zapisany w publicznych logach CT. Google: przed jego blokadą w logach nie zarejestrowano żadnego certyfikatu TLS prowadzącego do tych sześciu certyfikatów pośrednich, więc „żadne fałszywe certyfikaty wystawione przez te urzędy certyfikacji nie mogły zostać użyte przeciwko aplikacjom klienckim egzekwującym CT”.

Poza przeglądarką obraz jest inny. Strona incydentu prowadzona przez Mozillę: „wiele aplikacji klienckich spoza ekosystemu przeglądarek nie egzekwuje Certificate Transparency. Nie wiemy, czy atakujący wykorzystali wadliwe generowanie kluczy, by zaatakować te aplikacje”. To okno otworzyło się wiosną 2025 i dla każdej aplikacji klienckiej zamyka się dopiero po jej aktualizacji. eMudhra podaje, że nie wie o żadnych dowodach na to, że ktoś odtworzył klucze przed ujawnieniem, a Cloudflare podaje, że jego przegląd nie wykazał aktywnego wykorzystania w jego usługach.

Teraz, gdy klucze są publiczne, sfałszowanie certyfikatu nie wymaga żadnych umiejętności. Strona incydentu Mozilli wymienia serwery testowe, które przedstawiają certyfikaty wystawione przy użyciu skompromitowanych kluczy, tak by każdy mógł sprawdzić na nich swoje aplikacje klienckie (polecenia znajdziesz niżej).

Co umożliwia sfałszowany certyfikat: ktoś, kto może przechwycić ruch między twoim oprogramowaniem a usługą, z którą ono się łączy (w sieci współdzielonej, przez przejęty router albo zatrutą odpowiedź DNS), może podszyć się pod tę usługę, odczytać to, co wysyła twoje oprogramowanie, łącznie z kluczami API i danymi osobowymi, i zmienić to, co ono otrzymuje. Oprogramowanie podpisane jednym z dwóch kluczy do podpisywania kodu przeszłoby weryfikację podpisu w Windows, dopóki blokada Microsoftu nie dotarła do danego komputera.

Kogo to dotyczy

Są trzy odrębne problemy, a jedna firma może mieć wszystkie trzy.

1. Oprogramowanie, które nadal ufa skompromitowanym kluczom

Ten problem ma niemal każda firma: dotyczy każdego programu wykonującego wywołania HTTPS, którego magazyn zaufanych certyfikatów nadal zawiera emSign ECC Root CA - G3 lub AAA Certificate Services i który nie otrzymał blokady ośmiu kluczy. Typowe miejsca:

• Serwery z Linuksem i obrazy kontenerów zbudowane przed 20 lub 21 października. Na przykład niezałatany Debian 12 ufa obu łańcuchom.
• Środowiska uruchomieniowe języków, które mają własną listę: Node.js, certifi w Pythonie, cacerts w Javie, pakiet certyfikatów Composera w PHP, webpki-roots w Ruście.
• Narzędzia wiersza poleceń w macOS. Strona incydentu Mozilli podaje, że wbudowane curl, git, python3, perl, ruby i openssl sprawdzają certyfikaty według /etc/ssl/cert.pem bez sprawdzania unieważnienia i że Apple nie zaktualizował tego pliku.
• Komputery z Windows, które nie otrzymują automatycznych aktualizacji listy niedozwolonych certyfikatów od Microsoftu, zwykle dlatego, że wyłączają je zasady grupy (Group Policy) albo sieć nie ma połączenia z internetem.
• Urządzenia typu appliance, inne urządzenia i oprogramowanie firm trzecich z własnym plikiem CA, na przykład load balancery, bramy VPN, SDK i sterowniki wbudowane.

Każde środowisko uruchomieniowe trzeba sprawdzić osobno. W teście, który przeprowadziliśmy 22 października, niezałatany Debian 12 z Node.js 24.18 zaakceptował łańcuch kończący się na certyfikacie głównym eMudhra i odrzucił ten kończący się na certyfikacie głównym Sectigo, a Python na tej samej maszynie zaakceptował oba.

2. Firmy, których własne certyfikaty prowadzą do usuniętego certyfikatu głównego

Mozilla i dystrybucje Linuksa usunęły emSign ECC Root CA - G3, a Chrome zrobi to 27 października. Ważne certyfikaty pod tym certyfikatem głównym przestają działać w każdej aplikacji klienckiej, gdy tylko ta się zaktualizuje. Polecenie Google: operatorzy stron, którzy mają takie certyfikaty, „muszą natychmiast uzyskać i zainstalować nowy certyfikat TLS z innej hierarchii PKI uwzględnionej w Chrome Root Store”.

Chrome naliczył 21 października w CT około 30 800 niewygasłych certyfikatów pod tym certyfikatem głównym. 30 791 z nich pochodziło z dwóch certyfikatów pośrednich InCommon, usługi certyfikacyjnej, którą Internet2 prowadzi dla amerykańskich uczelni i instytucji badawczych i która wystawia certyfikaty ECC przez CERTInext, platformę eMudhra. 18 pochodziło z własnych certyfikatów pośrednich eMudhra. eMudhra podaje, że migracji wymaga około 30 000 certyfikatów, z czego około 97% wystawiono przez ACME, i że wystawia certyfikaty zastępcze z innej hierarchii.

Jeśli twoja strona działa za Cloudflare w trybie Full (strict), a serwer źródłowy (origin) przedstawia certyfikat pod tym certyfikatem głównym, Cloudflare podaje, że wycofanie zaufania „spowodowałoby awarie”, i prosi klientów, by „sprawdzili swoje niestandardowe certyfikaty serwerów źródłowych i konfiguracje serwerów”.

Certyfikaty RSA spod drugiego certyfikatu głównego eMudhra, emSign Root CA - G1, jak dotąd nie są objęte problemem. Mozilla podaje, że nie usuwa tego certyfikatu głównego „w tej chwili”; Chrome „uważnie analizuje dalsze uwzględnianie pozostałych certyfikatów CA firmy eMudhra”. Jeśli korzystasz z jakichkolwiek certyfikatów eMudhra lub CERTInext, już teraz zapewnij sobie drugi urząd certyfikacji.

3. Klienci GoDaddy

Sprawa GoDaddy nie ma nic wspólnego z eMudhra, ale wybuchła w tym samym tygodniu i dotknęła znacznie więcej stron. 15 października GoDaddy zgłosił Mozilli, że certyfikaty z jego hierarchii GoDaddy i Starfield zawierały informacje o polityce certyfikacji (identyfikatory OID polityk i odnośniki do CPS), które nie zgadzały się z profilami w jego własnym CP/CPS, czyli dokumencie, w którym urząd certyfikacji określa, co wystawia. To nie jest luka bezpieczeństwa w samych certyfikatach. Według Baseline Requirements, zasad, których przestrzega każdy publiczny urząd certyfikacji, to i tak powód, by unieważnić je w ciągu pięciu dni.

Problem objął 404 607 certyfikatów, z czego 396 055 z walidacją domeny. GoDaddy unieważnił 170 566 do terminu, czyli 18 października, 23:45 UTC, i 227 422 do następnego ranka; jego komunikat dla klientów podaje, że pozostałe unieważniono 21 października. GoDaddy wystawia certyfikaty ponownie, ale ich instalacja należy do klienta: „odwiedzający twoją stronę mogą widzieć ostrzeżenia bezpieczeństwa, a strona może być niedostępna, dopóki nie zostanie zainstalowany nowy certyfikat”.

Co sprawdzić dziś

1. Co wysyłają twoje własne serwery? Dla każdej publicznej nazwy hosta wypisz wystawców w łańcuchu, który ten host przedstawia:

h=www.example.com
openssl s_client -connect "$h:443" -servername "$h" -showcerts </dev/null 2>/dev/null | grep -E '^ +i:'

Wiersz, w którym pojawia się eMudhra, emSign, jeden z urzędów EM ... G3B lub G3C albo InCommon Intermediate CA - DVG3C, OVG3C lub EVG3C, oznacza, że certyfikat trzeba wymienić przed 27 października. Samo AAA Certificate Services jest normalne, bo wiele zwykłych łańcuchów Sectigo nadal je zawiera. Dla usług pocztowych i katalogowych dodaj -starttls smtp (lub imap, ldap) i właściwy port. Uwzględnij hosty wewnętrzne, load balancery i serwery źródłowe za CDN.

2. Co wystawiono dla twoich domen? CT zawiera każdy certyfikat, który publiczny urząd certyfikacji wystawił dla twoich nazw, także te, których zamówienia nikt w firmie nie pamięta:

curl -s 'https://crt.sh/?q=%25.example.com&output=json&exclude=expired' | jq -r '.[].issuer_name' | sort | uniq -c

Wynik pokazuje też, z których urzędów certyfikacji twoja firma faktycznie korzysta, a to początek inwentaryzacji opisanej niżej.

3. Czy twoje aplikacje klienckie ufają skompromitowanym kluczom? Serwery testowe Mozilli przedstawiają certyfikaty wystawione przy użyciu skompromitowanych kluczy, więc błąd certyfikatu to dobry wynik. Przetestuj oba warianty: pierwszy host prowadzi do certyfikatu głównego eMudhra, drugi do certyfikatu głównego Sectigo, a magazyn zaufanych certyfikatów może odrzucić jeden i przepuścić drugi.

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"

Wynik z curl mówi tylko o curl. Wykonaj to samo żądanie przez własny stos TLS każdej aplikacji, w środowisku, w którym ta aplikacja działa:

node -e "require('https').get('https://dv-g3b-emudhra.we-have-a-problem.com/', () => console.log('TRUSTED')).on('error', e => console.log('rejected:', e.code))"
python3 -c "import urllib.request; urllib.request.urlopen('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"
python3 -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"

Dwa wiersze Pythona nie są zbędne: urllib korzysta z magazynu systemu operacyjnego, requests z certifi. Powtórz każdy wiersz z hostem dv-g3b-aaa-emudhra. W przypadku Javy wykonaj dowolne wywołanie HTTPS do serwerów testowych z tej JVM, o którą chodzi, i sprawdź, czy jej magazyn zawiera któryś z tych certyfikatów głównych (Java 9 lub nowsza; w Javie 8 użyj -keystore $JAVA_HOME/jre/lib/security/cacerts):

keytool -list -v -cacerts -storepass changeit | grep -E 'Owner: .*(emSign ECC Root CA - G3|AAA Certificate Services)'

Certyfikat główny w magazynie sam w sobie nie dowodzi jeszcze narażenia, bo Go, Node.js, Deno i rustls-webpki z Rusta blokują teraz osiem kluczy niezależnie od zawartości magazynu. Rozstrzygają to serwery testowe.

4. Park komputerów z Windows. Microsoft nie opublikował nic na temat incydentu, ale lista niedozwolonych certyfikatów, którą Windows pobiera automatycznie, blokuje wszystkie osiem kluczy od 20 października. Wyjątki to komputery, na których zasady grupy wyłączają automatyczną aktualizację certyfikatów głównych, oraz sieci bez dostępu do Windows Update; tam listę trzeba dostarczyć w inny sposób. certutil -verifyCTL Disallowed pokazuje kopię zapisaną w pamięci podręcznej komputera. Strona incydentu Mozilli udostępnia skrypt dla pojedynczych komputerów i podaje, że „nie jest zalecany dla urządzeń zarządzanych centralnie przez firmę”.

5. Certyfikaty GoDaddy. Sprawdź, który certyfikat faktycznie przedstawia każdy serwer:

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer -serial -startdate

Jeśli wystawcą jest GoDaddy lub Starfield, porównaj numer seryjny z certyfikatami na swoim koncie GoDaddy. Tam, gdzie GoDaddy pokazuje „Install your new certificate” (zainstaluj nowy certyfikat), serwer nadal ma unieważniony certyfikat.

Jedna zasada przez cały czas: nie usuwaj błędu przez wyłączenie weryfikacji certyfikatów. Cloudflare ujmuje to tak: „Ważne, by nie rozwiązywać tych błędów przez wyłączanie weryfikacji”. Aplikacja kliencka, która nie weryfikuje certyfikatów, ufa każdemu sfałszowanemu certyfikatowi, nie tylko tym.

Co zaktualizować w tym tygodniu

Są dwa rodzaje poprawek. Usunięcie dwóch certyfikatów głównych zamyka każdą ścieżkę dla aplikacji klienckiej korzystającej z danego magazynu, ale psuje też ważne certyfikaty pod nimi. Zablokowanie ośmiu kluczy po skrócie klucza publicznego, tak jak robią to Go, Node.js, Deno, Electron, rustls-webpki, Composer i Windows, zamyka lukę i nie psuje niczego innego. Jeśli twoja platforma oferuje to drugie, wybierz je.

„Jeszcze brak” oznacza, że do 22 października nic nie opublikowano. Sprawdź ponownie, zanim oprzesz na tym swoje plany.

Cztery pułapki, na które wpadają zespoły:

• Obrazy kontenerów zachowują starą listę. Obraz zbudowany przed 20 lub 21 października ufa kluczom, dopóki nie zostanie przebudowany na zaktualizowanym obrazie bazowym, a pobranie tego samego tagu pomaga dopiero wtedy, gdy przebudowano sam obraz bazowy. Przebuduj, wdróż ponownie i zapytaj dostawców, których obrazy uruchamiasz.
• Procesy zachowują to, co wczytały. Program wczytuje magazyn zaufanych certyfikatów przy starcie, więc po aktualizacji zrestartuj długo działające usługi. Node.js dodaje, że sesje TLS wznowione z okresu sprzed aktualizacji nie są ponownie sprawdzane.
• Aplikacje mają własne pliki CA. SDK i aplikacje często dostarczają własny cacert.pem lub ca-bundle.crt. Przeszukaj pod ich kątem repozytoria i obrazy, na przykład poleceniem find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, i spodziewaj się więcej niż jednego: pip na przykład ma własną kopię certifi.
• Urządzenia czekają na producenta. Zapytaj każdego producenta na piśmie, z jakiego magazynu zaufanych certyfikatów korzysta produkt i kiedy pojawi się aktualizacja. Do tego czasu urządzenie ufa sfałszowanym certyfikatom dla każdej usługi, z którą się łączy, więc ogranicz, do czego ma dostęp.

Jeśli usuwasz AAA Certificate Services ręcznie, tak jak robią to Debian, Ubuntu ESM, Fedora i obejście Red Hat, przetestuj potem połączenia z usługami, które mają certyfikaty Sectigo: niektóre starsze serwery nadal wysyłają łańcuch kończący się na tym certyfikacie głównym.

Co wdrożyć przed następnym incydentem

Urząd certyfikacji, który zostawia tak słabe klucze, to rzadkość. Masowe unieważnienia rzadkością nie są. Oto duże przypadki z 2026 roku odnotowane w bugtrackerze Mozilli:

Żaden z tych pięciu przypadków nie był błędem bezpieczeństwa. W każdym certyfikat był niezgodny z własnym dokumentem urzędu, a Baseline Requirements (sekcja 4.9.1.1) i tak wymagają unieważnienia w ciągu pięciu dni. Gdy klucz zostanie skompromitowany albo nie można polegać na walidacji domeny, termin wynosi 24 godziny. Nikt nie może go za ciebie przedłużyć. Przy unieważnieniu 83 267 certyfikatów przez DigiCert w 2024 roku Chrome Root Program napisał, że „nie ma uprawnień do przyznawania wyjątków”; jeden z klientów uzyskał nakaz sądowy wstrzymujący unieważnienie jego certyfikatów, a nakaz uchylono cztery dni później.

Wiele mówi to, jak przebiegała wymiana. W lipcu HARICA użyła ACME Renewal Information (ARI), by polecić klientom ACME, z których korzystają jej klienci, wcześniejsze odnowienie, a inne certyfikaty wystawiła ponownie sama; w większym z jej dwóch unieważnień 87% nazw objętych problemem miało już nowe certyfikaty, gdy upłynął termin. GoDaddy, którego klienci sami pobierają i instalują każdy nowy certyfikat, do swojego terminu unieważnił 42% certyfikatów objętych problemem.

Cykl odnawiania i tak się skraca:

• Zgodnie z głosowaniem SC-081 CA/Browser Forum publiczne certyfikaty TLS są od 15 marca 2026 ograniczone do 200 dni. Limit spada do 100 dni 15 marca 2027 i do 47 dni 15 marca 2029, kiedy walidację domeny będzie można ponownie wykorzystać tylko przez 10 dni.
• Let's Encrypt 10 lutego 2027 zmienia domyślny okres ważności na 64 dni, a rok później na 45 dni.
• Publiczne certyfikaty TLS tracą uwierzytelnianie klienta. Let's Encrypt przestał wystawiać certyfikaty z tym przeznaczeniem 8 lipca 2026, a Chrome Root Program wymaga, by certyfikaty wystawione od 15 marca 2027 służyły wyłącznie do uwierzytelniania serwera. Jeśli używasz publicznych certyfikatów jako certyfikatów klienckich do mutual TLS, co jest częste w integracjach API B2B, te połączenia będą potrzebowały prywatnego urzędu certyfikacji.

Przy 100 dniach, a potem przy 47, ręczna instalacja certyfikatów przestaje być realną opcją. Firma, która zautomatyzuje się pod ten harmonogram, jest też gotowa na następne masowe unieważnienie. Czego to wymaga:

1. Wiedz, co masz, w obu kierunkach. Jedna lista każdego certyfikatu, który serwujesz, z nazwą hosta, wystawcą, datą wygaśnięcia, metodą odnawiania i właścicielem. Druga lista każdego magazynu zaufanych certyfikatów, na którym polega twoje oprogramowanie: pakiet systemu operacyjnego, każdy pakiet języka, każdy plik CA wewnątrz aplikacji lub urządzenia. Opisane wyżej wyszukiwanie w CT zaczyna pierwszą listę; wykaz składników oprogramowania (SBOM) lub inwentarz zależności zaczyna drugą.
2. Zautomatyzuj wystawianie i instalację. ACME wszędzie, gdzie może działać, z ARI (RFC 9773), aby urząd certyfikacji mógł polecić twoim klientom ACME wcześniejsze odnowienie. Tam, gdzie urządzenie nie obsłuży ACME, użyj automatyzacji producenta albo terminuj TLS przed nim na czymś, co to potrafi.
3. Miej w gotowości drugi urząd certyfikacji. Działające, przetestowane konto ACME u drugiego urzędu i rekordy CAA w DNS, które dopuszczają oba. Gdy jeden urząd straci zaufanie albo zacznie masowo unieważniać certyfikaty, przejście na drugi staje się zmianą konfiguracji.
4. Monitoruj CT dla swoich domen. Ustaw alert dla każdego nowego certyfikatu wystawionego dla twoich nazw. O nieoczekiwanym wystawieniu dowiesz się tego samego dnia.
5. Traktuj magazyny zaufanych certyfikatów jak zależności. Aktualizuj je w ramach zwykłego łatania i przebudowuj obrazy według harmonogramu, a nie tylko przy zmianach kodu.
6. Spisz runbook (procedurę krok po kroku) pod oba zegary. 24 godziny i pięć dni: kto decyduje, kto ma dostęp do każdego systemu, które systemy wymagają ręcznych kroków, jak skontaktować się z każdym dostawcą. Przećwicz go raz w roku, wymieniając certyfikat w usłudze, która zniesie pomyłkę. Publiczne urzędy certyfikacji od 2025 roku muszą mieć i testować własny plan na wypadek masowego unieważnienia; ich klienci potrzebują drugiej połowy tego planu.

Jeśli tworzysz produkty, które uruchamiają inni

Jeśli twój produkt zawiera magazyn zaufanych certyfikatów (urządzenie, instalowana aplikacja, SDK), twoi klienci są chronieni dopiero wtedy, gdy dotrze do nich twoja aktualizacja. Wydaj ją i poinformuj klientów, które wersje są poprawione. Rada Mozilli dla operatorów magazynów zaufanych certyfikatów: zablokuj osiem certyfikatów pośrednich, jeśli twoje oprogramowanie to umożliwia, a w przeciwnym razie „rozważ, czy odpowiednie jest wycofanie zaufania do certyfikatów głównych, które podpisały te certyfikaty pośrednie”.

Akt o cyberodporności (Cyber Resilience Act) ma tu zastosowanie na dwa sposoby. Jego obowiązek zgłaszania, obowiązujący od 11 września 2026, obejmuje aktywnie wykorzystywane podatności, a w tej sprawie nie zgłoszono żadnego wykorzystania. Jego zasadnicze wymogi, stosowane od 11 grudnia 2027, obejmują to, że podatności można usuwać za pomocą aktualizacji bezpieczeństwa; produkt, którego listy zaufanych certyfikatów nie da się zaktualizować, nie spełniałby ich. Klienci objęci dyrektywą NIS2 zapytają swoich dostawców, jak szybko się z tym uporali, i warto mieć odpowiedź na piśmie.

Co pozostaje otwarte

• Pozostały certyfikat główny eMudhra. Chrome zadał eMudhra 21 października dwanaście pytań i nie ogłosił decyzji w sprawie emSign Root CA - G1. Mozilla nie usuwa go „w tej chwili”.
• Ścieżka migracji eMudhra. Firma poinformowała Mozillę, że przeniesie klientów do swojej hierarchii G1 (RSA); jej strona statusu mówi o „alternatywnej, niezależnie prowadzonej, publicznie zaufanej hierarchii CA”. Chrome zapytał, o którą chodzi.
• Microsoft i Apple. Żadna z tych firm nie opublikowała oświadczenia ani nie usunęła żadnego z tych certyfikatów głównych ze swojego magazynu.
• Oczekujące poprawki. Red Hat, Amazon Linux, Temurin i Corretto do 22 października nie wydały niczego; poprawkę w Bun scalono, ale jej nie wydano.
• Przyczyna źródłowa. eMudhra jej nie potwierdziła i oświadczyła, że ponownie zweryfikuje każdą przeprowadzoną przez siebie ceremonię generowania kluczy.
• Sectigo. W odrębnej sprawie, otwartej od 5 września, Sectigo odmówiło unieważnienia certyfikatów, których rozszerzone użycie klucza (extended key usage) nie zgadzało się ze zdaniem w jego CPS, argumentując, że to zdanie było niejednoznaczne. Według jego wyliczenia z 18 października nadal aktywnych było około 72 milionów takich certyfikatów. Niektórzy uczestnicy publicznej dyskusji wezwali do wycofania zaufania; żaden program certyfikatów głównych nie ogłosił decyzji. Firmy z certyfikatami Sectigo powinny śledzić sprawę.

Gdzie szukać pomocy

Problem z certyfikatem rzadko od razu wygląda na problem z certyfikatem. Objawia się jako koszyk, który przestaje się ładować, integracja, która przestaje synchronizować dane, albo urządzenie, które przestaje raportować, zwykle w weekend. Pomagamy firmom przejść przez takie tygodnie jak ten bez przestojów i przygotować wszystko tak, by następny był rutyną:

• Sprawdzenie narażenia. Ustalamy, gdzie twoje systemy nawiązują lub przyjmują połączenia TLS, z jakiego magazynu zaufanych certyfikatów korzysta każdy z nich i jakie certyfikaty serwujesz, łącznie z kontenerami, usługami Java, integracjami z bankami, operatorami płatności i firmami logistycznymi oraz urządzeniami.
• Poprawki. Aktualizacje, przebudowane obrazy, zablokowane klucze lub wymienione certyfikaty, wprowadzone w ramach twojego procesu zarządzania zmianami i potwierdzone na serwerach testowych Mozilli.
• Automatyzacja na 2027. ACME z ARI na serwerach, load balancerach i urządzeniach typu appliance, drugi urząd certyfikacji, rekordy CAA, monitoring CT i runbook, gotowe na certyfikaty 100-dniowe od 15 marca 2027.
• Systemy, których nikt nie chce ruszać. Do starych aplikacji Java, urządzeń typu appliance i wbudowanych aplikacji klienckich z własnymi magazynami zaufanych certyfikatów służy nasza usługa utrzymania systemów odziedziczonych i ich kodu.

Jeśli nie masz pewności, czy cię to dotyczy, napisz na office@c9group.dev i podaj domeny i platformy, z których korzystasz, albo umów rozmowę. Powiemy ci, co sprawdzić najpierw.