Kompromitovani ključevi sertifikacionog tela eMudhra: šta kompanije treba odmah da provere i poprave

U subotu, 17. oktobra 2026, jedan istraživač bezbednosti prijavio je da osam posredničkih sertifikacionih tela kojima upravlja indijsko sertifikaciono telo eMudhra ima privatne ključeve koje svako može da izračuna iz javnih sertifikata. Svaki od tih ključeva bio je broj manji od 256. Jedan od njih bio je broj 4. Šest od osam moglo je da izdaje TLS sertifikate kojima veruju Apple, Google, Microsoft i Mozilla; preostala dva mogla su da potpisuju softver za Windows.

Chrome je blokirao šest TLS ključeva sat i četrdeset minuta posle prijave, a Firefox iste večeri. Za one koji samo pretražuju veb, opasnost je prošla već u subotu uveče.

Za sve ostalo nije. Serveri, kontejneri, Java aplikacije, Python skripte, integracije za plaćanje i povezani uređaji proveravaju sertifikate prema sopstvenoj kopiji liste pouzdanih sertifikacionih tela, a većina tih kopija menja se tek kada neko instalira ažuriranje. Do tada sertifikat za bilo koji domen potpisan nekim od ovih ključeva prolazi kao pravi, a ključevi su javni od 20. oktobra.

Iste nedelje GoDaddy je počeo da opoziva 404.607 sertifikata jer se podaci o politici u njima nisu slagali sa njegovim sopstvenim objavljenim dokumentima. Njegovi korisnici morali su sami da preuzmu i instaliraju zamenske sertifikate.

Ovaj vodič je namenjen onima koji moraju da odgovore na pitanje „da li smo pogođeni?“: rukovodiocima IT-a i operacija, CTO-ovima i osnivačima čije poslovanje počiva na veb sajtu, API-ju ili povezanom proizvodu. Obrađuje šta se dogodilo, na osnovu zapisa o incidentu koje su objavili Mozilla, Google, eMudhra, GoDaddy i proizvođači softvera; šta proveriti danas; šta ažurirati ove nedelje; i šta uvesti da bi sledeći incident ove vrste bio rutina. Sve u tekstu odgovara stanju na dan 22. oktobra 2026, a incident još nije zatvoren.

Šta se dogodilo

eMudhra je napravila osam posredničkih sertifikata na ceremoniji generisanja ključeva 30. aprila 2025. Njeno objašnjenje, objavljeno 19. oktobra u Mozillinom tiketu o incidentu: test koraka umotavanja i raspakivanja ključa (key wrap i unwrap), odobren kao odstupanje od uobičajene procedure, imao je propust zbog kog je u hardverskom bezbednosnom modulu (HSM), pored predviđenih ključeva, nastao i drugi, slab skup ključeva. Oznake su bile slične, slabi ključevi su greškom upotrebljeni za izradu zahteva za sertifikate, a eMudhrin root sertifikat ih je potpisao. Isti zahtevi otišli su i Sectigu, koji je 14. maja 2025. svojim root sertifikatom AAA Certificate Services unakrsno potpisao svih osam. eMudhra navodi da „još nije potvrdila tačan osnovni uzrok“.

Mozilla je ovako opisala rezultat: „Privatni ključevi P384 su nasumično izabrani celi brojevi između 1 i reda grupe. Svih 8 pogođenih ključeva koristilo je cele brojeve manje od 256.“ Mozilla je prijavu primila u 20:06 UTC i sama došla do ključeva u 21:48, „bez ikakvog znanja o metodi koju je koristio prvobitni prijavilac“. Istraživač kaže da ih je pronašao Googleovom bibliotekom otvorenog koda paranoid_crypto, „bez ikakvog podešavanja“. Slabi ključevi bili su deo javno pouzdanih lanaca skoro 18 meseci.

Osam sertifikata:

Svaki ključ nalazi se u dva sertifikata. Jedan je izdao eMudhrin emSign Root TLS CA - G3 ili emSign Root CS CA - G3, koji vode do emSign ECC Root CA - G3; drugi je Sectigov unakrsni sertifikat izdat iz AAA Certificate Services. Taj drugi put je važan, jer neka skladišta sertifikata (trust store) koja nikada nisu sadržala nijedan eMudhrin root sertifikat i dalje veruju tom starom Sectigovom root sertifikatu.

Da li je iko napadnut?

Niko nije prijavio zloupotrebu, a za pregledače postoji dobar razlog da se veruje da je nije ni bilo. Chrome, kao i drugi klijenti koji sprovode Certificate Transparency (CT), prihvata sertifikat samo ako je upisan u javne CT logove. Google: pre njegove blokade nijedan TLS sertifikat koji vodi do ovih šest posredničkih sertifikata nije bio upisan u logove, pa „nijedan lažni sertifikat koji su izdala ova sertifikaciona tela nije mogao biti upotrebljen protiv klijenata koji sprovode CT“.

Van pregledača slika je drugačija. Mozillina stranica o incidentu: „mnogi klijenti van ekosistema pregledača ne sprovode Certificate Transparency. Ne znamo da li su napadači iskoristili neispravno generisanje ključeva da bi napali te klijente.“ Taj prozor otvorio se u proleće 2025. i za svaki klijent zatvara se tek kada se on ažurira. eMudhra kaže da nema saznanja ni o kakvim dokazima da je iko izračunao ključeve pre javne objave, a Cloudflare navodi da njegova provera nije pokazala aktivno iskorišćavanje na njegovim uslugama.

Sada kada su ključevi javni, za lažiranje sertifikata nije potrebna nikakva veština. Mozillina stranica o incidentu navodi test servere koji šalju sertifikate izdate kompromitovanim ključevima, kako bi svako mogao da na njima proveri svoje klijente (komande su u nastavku).

Šta lažni sertifikat omogućava: neko ko može da presretne saobraćaj između vašeg softvera i usluge koju on poziva (na deljenoj mreži, preko kompromitovanog rutera ili zatrovanog DNS odgovora) može da se predstavi kao ta usluga, da čita ono što vaš softver šalje, uključujući API ključeve i lične podatke, i da menja ono što softver prima. Softver potpisan nekim od dva ključa za potpisivanje koda prošao bi Windows proveru potpisa sve dok Microsoftova blokada ne stigne do računara.

Ko je pogođen

Postoje tri odvojena problema, a jedna kompanija može imati sva tri.

1. Softver koji i dalje veruje kompromitovanim ključevima

Ovaj problem ima skoro svaka kompanija: svaki program koji upućuje HTTPS pozive, čije skladište sertifikata i dalje sadrži emSign ECC Root CA - G3 ili AAA Certificate Services i koji nije dobio blokadu za osam ključeva. Tipična mesta:

• Linux serveri i slike kontejnera napravljene pre 20. ili 21. oktobra. Nezakrpljen Debian 12, na primer, veruje obema lancima.
• Runtime okruženja programskih jezika koja donose sopstvenu listu: Node.js, Pythonov certifi, Javin cacerts, Composerov CA paket za PHP, Rustov webpki-roots.
• Alati komandne linije na macOS-u. Mozillina stranica o incidentu navodi da ugrađeni curl, git, python3, perl, ruby i openssl proveravaju sertifikate prema /etc/ssl/cert.pem bez provere opoziva i da Apple nije ažurirao taj fajl.
• Windows računari koji ne primaju Microsoftova automatska ažuriranja liste zabranjenih sertifikata, obično zato što ih Group Policy isključuje ili mreža nema vezu sa internetom.
• Mrežni uređaji (appliances), ostali uređaji i softver trećih strana koji nose sopstveni CA fajl, kao što su load balanseri, VPN gateway uređaji, SDK-ovi i ugrađeni kontroleri.

Svako runtime okruženje mora se proveriti zasebno. U testu koji smo sproveli 22. oktobra, nezakrpljen Debian 12 sa Node.js 24.18 prihvatio je lanac koji se završava eMudhrinim root sertifikatom i odbio onaj koji se završava Sectigovim, dok je Python na istom računaru prihvatio oba.

2. Kompanije čiji sopstveni sertifikati vode do uklonjenog root sertifikata

Mozilla i Linux distribucije uklonile su emSign ECC Root CA - G3, a Chrome to čini 27. oktobra. Važeći sertifikati ispod tog root sertifikata prestaju da rade u svakom klijentu čim se on ažurira. Googleovo uputstvo: operateri veb sajtova sa takvim sertifikatima „moraju odmah da nabave i instaliraju novi TLS sertifikat iz druge PKI hijerarhije koja je uključena u Chrome Root Store“.

Chrome je 21. oktobra u CT logovima izbrojao oko 30.800 neisteklih sertifikata ispod tog root sertifikata. Od njih 30.791 potiče od dva posrednička sertifikata InCommona, sertifikacione usluge koju Internet2 vodi za američke univerzitete i istraživačke ustanove i koja ECC sertifikate izdaje preko CERTInexta, platforme kompanije eMudhra. Njih 18 potiče od eMudhrinih sopstvenih posredničkih sertifikata. eMudhra navodi da oko 30.000 sertifikata treba migrirati, od kojih je oko 97% izdato preko ACME protokola, i da izdaje zamenske sertifikate iz druge hijerarhije.

Ako vaš sajt koristi Cloudflare u režimu Full (strict), a izvorni server (origin) šalje sertifikat ispod ovog root sertifikata, Cloudflare kaže da bi ukidanje poverenja „dovelo do prekida u radu“ i traži od korisnika da „provere svoje prilagođene sertifikate izvornih servera i konfiguracije servera“.

RSA sertifikati iz drugog eMudhrinog root sertifikata, emSign Root CA - G1, za sada nisu pogođeni. Mozilla kaže da taj root sertifikat „u ovom trenutku“ ne uklanja; Chrome „pažljivo ispituje dalje zadržavanje preostalih CA sertifikata kompanije eMudhra“. Ako zavisite od bilo kakvih sertifikata kompanije eMudhra ili platforme CERTInext, već sada obezbedite drugo sertifikaciono telo.

3. Korisnici GoDaddyja

Slučaj GoDaddyja nema nikakve veze sa kompanijom eMudhra, ali se dogodio iste nedelje i pogodio mnogo više sajtova. GoDaddy je 15. oktobra prijavio Mozilli da sertifikati iz njegovih hijerarhija GoDaddy i Starfield sadrže podatke o politici sertifikata (OID-ove politika i CPS linkove) koji se ne slažu sa profilima u njegovom sopstvenom CP/CPS-u, dokumentu u kome sertifikaciono telo navodi šta izdaje. To nije bezbednosni propust u sertifikatima. Prema Baseline Requirements, pravilima koja poštuje svako javno sertifikaciono telo, to je ipak razlog da se sertifikati opozovu u roku od pet dana.

Pogođeno je 404.607 sertifikata, od toga 396.055 sa validacijom domena. GoDaddy je do roka, 18. oktobra u 23:45 UTC, opozvao 170.566, a do sledećeg jutra 227.422; njegovo obaveštenje za korisnike navodi da su ostali opozvani 21. oktobra. GoDaddy ponovo izdaje sertifikate, ali njihova instalacija je na korisniku: „posetioci vašeg veb sajta mogu videti bezbednosna upozorenja, a vaš sajt može postati nedostupan dok se ne instalira novi sertifikat.“

Šta proveriti danas

1. Šta šalju vaši sopstveni serveri? Za svako javno ime hosta izlistajte izdavaoce u lancu koji on šalje:

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

Red u kome se pominje eMudhra, emSign, neko od sertifikacionih tela EM ... G3B ili G3C, ili InCommon Intermediate CA - DVG3C, OVG3C ili EVG3C znači da sertifikat mora biti zamenjen pre 27. oktobra. Sam AAA Certificate Services je normalan, jer ga mnogi obični Sectigo lanci i dalje sadrže. Za mejl i direktorijumske servise dodajte -starttls smtp (ili imap, ldap) i odgovarajući port. Uključite i interne hostove, load balansere i izvorne servere iza CDN-a.

2. Šta je izdato za vaše domene? CT beleži svaki sertifikat koji je neko javno sertifikaciono telo izdalo za vaša imena, uključujući i one za koje se niko u kompaniji ne seća da ih je naručio:

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

Izlaz pokazuje i koja sertifikaciona tela vaša kompanija zaista koristi, a to je početak popisa opisanog u nastavku.

3. Da li vaši klijenti veruju kompromitovanim ključevima? Mozillini test serveri šalju sertifikate izdate kompromitovanim ključevima, pa je greška sertifikata dobar ishod. Testirajte obe porodice: prvi host vodi do eMudhrinog root sertifikata, drugi do Sectigovog, a skladište sertifikata može da padne na jednom testu i prođe na drugom.

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"

curl daje odgovor samo za curl. Isti zahtev pokrenite kroz sopstveni TLS stek svake aplikacije, u okruženju u kome aplikacija radi:

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')"

Dva Python reda nisu suvišna: urllib koristi skladište sertifikata operativnog sistema, requests koristi certifi. Ponovite svaki red sa hostom dv-g3b-aaa-emudhra. Za Javu uputite bilo koji HTTPS poziv test serverima iz JVM-a o kome je reč i proverite da li njegovo skladište sertifikata sadrži neki od ta dva root sertifikata (Java 9 ili novija; na Javi 8 koristite -keystore $JAVA_HOME/jre/lib/security/cacerts):

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

Sam root sertifikat u skladištu ne dokazuje izloženost, jer Go, Node.js, Deno i Rustov rustls-webpki sada blokiraju osam ključeva bez obzira na sadržaj skladišta. Konačan odgovor daju test serveri.

4. Windows računari u organizaciji. Microsoft nije objavio ništa o incidentu, ali lista zabranjenih sertifikata koju Windows automatski preuzima blokira svih osam ključeva od 20. oktobra. Izuzeci su računari na kojima Group Policy isključuje automatsko ažuriranje root sertifikata i mreže koje nemaju pristup servisu Windows Update; njima listu treba isporučiti na drugi način. certutil -verifyCTL Disallowed prikazuje kopiju koju računar ima u kešu. Mozillina stranica o incidentu nudi skriptu za pojedinačne računare i navodi da se ona „ne preporučuje za uređaje kojima upravlja preduzeće“.

5. GoDaddy sertifikati. Proverite koji sertifikat svaki server zaista šalje:

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

Ako je izdavalac GoDaddy ili Starfield, uporedite serijski broj sa sertifikatima na svom GoDaddy nalogu. Tamo gde GoDaddy prikazuje „Install your new certificate“ (instalirajte novi sertifikat), server i dalje ima opozvani sertifikat.

Jedno pravilo važi za sve korake: ne uklanjajte grešku isključivanjem provere sertifikata. Cloudflare kaže: „Važno je da ove greške ne rešavate isključivanjem provere.“ Klijent koji ne proverava sertifikate veruje svakom lažnom sertifikatu, ne samo ovim.

Šta ažurirati ove nedelje

Postoje dve vrste ispravki. Uklanjanje dva root sertifikata zatvara svaki put za klijent koji koristi to skladište, ali kvari i važeće sertifikate ispod njih. Blokiranje osam ključeva po hešu javnog ključa, kao što to rade Go, Node.js, Deno, Electron, rustls-webpki, Composer i Windows, zatvara rupu i ne kvari ništa drugo. Gde vaša platforma nudi drugu opciju, izaberite nju.

„Još nema“ i „još nije“ znače da do 22. oktobra ništa nije bilo objavljeno. Proverite ponovo pre nego što na tome zasnujete plan.

Četiri stvari često iznenade timove:

• Slike kontejnera zadržavaju staru listu. Slika napravljena pre 20. ili 21. oktobra veruje ključevima dok se ponovo ne izgradi na ažuriranoj osnovnoj slici, a ponovno preuzimanje istog taga pomaže tek kada je osnovna slika ponovo izgrađena. Ponovo izgradite slike, ponovo ih postavite i pitajte proizvođače čije slike koristite.
• Procesi zadržavaju ono što su učitali. Program čita svoje skladište sertifikata pri pokretanju, pa posle ažuriranja ponovo pokrenite servise koji dugo rade. Node.js dodaje da se TLS sesije nastavljene iz vremena pre nadogradnje ne proveravaju ponovo.
• Aplikacije nose sopstvene CA fajlove. SDK-ovi i aplikacije često isporučuju sopstveni cacert.pem ili ca-bundle.crt. Potražite ih u repozitorijumima i slikama, na primer komandom find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, i očekujte da ih ima više: pip, na primer, nosi sopstvenu kopiju certifija.
• Uređaji čekaju svog proizvođača. Pitajte svakog proizvođača pismeno koje skladište sertifikata proizvod koristi i kada stiže ažuriranje. Dok ono ne stigne, uređaj veruje lažnim sertifikatima za svaku uslugu koju poziva, zato ograničite ono do čega može da dopre.

Ako AAA Certificate Services uklonite ručno, kao što to rade Debian, Ubuntu ESM, Fedora i zaobilazno rešenje Red Hata, posle toga testirajte veze sa uslugama koje imaju Sectigo sertifikate: neki stariji serveri i dalje šalju lanac koji se završava tim root sertifikatom.

Šta uvesti pre sledećeg incidenta

Retko se dešava da sertifikaciono telo ostavi ovako slabe ključeve. Masovni opozivi, međutim, nisu retki. Ovo su veliki opozivi iz 2026. zabeleženi u Mozillinom sistemu za praćenje grešaka:

Nijedan od ovih pet slučajeva nije bio bezbednosni propust. U svakom se sertifikat razlikovao od sopstvenog dokumenta sertifikacionog tela, a Baseline Requirements (odeljak 4.9.1.1) ipak zahtevaju opoziv u roku od pet dana. Kada je ključ kompromitovan ili se na validaciju domena ne može osloniti, rok je 24 sata. Niko vam ga ne može produžiti. Kada je DigiCert 2024. opozivao 83.267 sertifikata, Chrome Root Program je napisao da „nema ovlašćenje da odobrava izuzetke“; jedan korisnik je dobio sudski nalog kojim se zaustavlja opoziv njegovih sertifikata, a nalog je ukinut četiri dana kasnije.

Način na koji su zamene tekle dosta govori. HARICA je u julu koristila ACME Renewal Information (ARI) da ACME klijentima svojih korisnika javi da ranije obnove sertifikate, a ostale sertifikate je sama ponovo izdala; u većem od njena dva opoziva, kada je rok istekao, bilo je zamenjeno 87% pogođenih imena. GoDaddy, čiji korisnici svaku zamenu sami preuzimaju i instaliraju, do svog roka je opozvao 42% pogođenih sertifikata.

Ciklus obnove se u svakom slučaju skraćuje:

• Prema odluci CA/Browser Foruma SC-081, javni TLS sertifikati od 15. marta 2026. ograničeni su na 200 dana. Ograničenje pada na 100 dana 15. marta 2027. i na 47 dana 15. marta 2029, kada će se validacija domena moći ponovo koristiti samo 10 dana.
• Let's Encrypt 10. februara 2027. podrazumevano prelazi na sertifikate od 64 dana, a godinu dana kasnije na 45 dana.
• Javni TLS sertifikati gube namenu za autentifikaciju klijenta. Let's Encrypt je prestao da je izdaje 8. jula 2026, a Chrome Root Program zahteva da sertifikati izdati od 15. marta 2027. služe samo za autentifikaciju servera. Ako javne sertifikate koristite kao klijentske sertifikate za mutual TLS, što je često u B2B API integracijama, tim vezama je potrebno privatno sertifikaciono telo.

Pri 100 dana, a zatim pri 47, ručna instalacija sertifikata prestaje da bude realna opcija. Kompanija koja se automatizuje za taj ritam spremna je i za sledeći masovni opoziv. Šta je za to potrebno:

1. Znajte šta imate, u oba smera. Jedna lista svakog sertifikata koji vaši serveri šalju, sa imenom hosta, izdavaocem, datumom isteka, načinom obnove i vlasnikom. Druga lista svakog skladišta sertifikata na koje se vaš softver oslanja: paket operativnog sistema, svaki paket programskog jezika, svaki CA fajl unutar aplikacije ili uređaja. CT pretraga iznad započinje prvu listu; spisak softverskih komponenti (SBOM) ili popis zavisnosti započinje drugu.
2. Automatizujte izdavanje i instalaciju. ACME svuda gde može da radi, sa ARI (RFC 9773), kako bi sertifikaciono telo moglo da javi vašim klijentima da ranije obnove sertifikate. Gde uređaj ne može da pokrene ACME, koristite automatizaciju proizvođača ili terminišite TLS ispred njega, na nečemu što to može.
3. Držite spremno drugo sertifikaciono telo. Funkcionalan, testiran ACME nalog kod drugog sertifikacionog tela i CAA zapisi u DNS-u koji dozvoljavaju oba. Kada se jednom telu uskrati poverenje ili ono masovno opoziva sertifikate, prelazak postaje promena konfiguracije.
4. Pratite CT za svoje domene. Dobijajte upozorenje za svaki novi sertifikat izdat za vaša imena. O neočekivanom izdavanju saznajete istog dana kada se dogodi.
5. Tretirajte skladišta sertifikata kao zavisnosti. Ažurirajte ih kroz redovno zakrpljivanje i ponovo gradite slike po rasporedu, a ne samo kada se kod promeni.
6. Napišite operativni priručnik (runbook) za oba roka. 24 sata i pet dana: ko odlučuje, ko ima pristup kom sistemu, kojim sistemima trebaju ručni koraci, kako doći do svakog proizvođača. Uvežbajte ga jednom godišnje zamenom sertifikata na usluzi koja može da podnese grešku. Javna sertifikaciona tela od 2025. moraju da imaju i testiraju sopstveni plan za masovni opoziv; njihovim korisnicima treba druga polovina.

Ako pravite proizvode koje drugi koriste

Ako vaš proizvod sadrži skladište sertifikata (uređaj, instalirana aplikacija, SDK), vaši korisnici su zaštićeni tek kada do njih stigne vaše ažuriranje. Isporučite ga i recite korisnicima koje su verzije ispravljene. Mozillin savet operaterima skladišta sertifikata: blokirajte osam posredničkih sertifikata ako vaš softver to može, a u suprotnom „razmotrite da li je prikladno ukinuti poverenje u root sertifikate koji su potpisali ove posredničke sertifikate“.

Cyber Resilience Act se ovde primenjuje na dva načina. Njegova obaveza prijavljivanja, koja važi od 11. septembra 2026, obuhvata aktivno iskorišćene ranjivosti, a u ovom slučaju iskorišćavanje nije prijavljeno. Njegovi suštinski zahtevi, koji se primenjuju od 11. decembra 2027, uključuju i to da se ranjivosti mogu otklanjati bezbednosnim ažuriranjima; proizvod čija se lista pouzdanih sertifikata ne može ažurirati ne bi ih ispunio. Korisnici obuhvaćeni direktivom NIS2 pitaće svoje dobavljače koliko su brzo ovo rešili, pa je korisno imati odgovor zapisan.

Šta je još otvoreno

• Preostali eMudhrin root sertifikat. Chrome je 21. oktobra postavio kompaniji eMudhra dvanaest pitanja i nije objavio nikakvu odluku o emSign Root CA - G1. Mozilla ga „u ovom trenutku“ ne uklanja.
• eMudhrin plan migracije. Mozilli je rekla da će korisnike prebaciti na svoju G1 (RSA) hijerarhiju; njena statusna stranica govori o „alternativnoj, nezavisno vođenoj, javno pouzdanoj CA hijerarhiji“. Chrome je pitao o kojoj je hijerarhiji reč.
• Microsoft i Apple. Nijedan od njih nije objavio saopštenje niti uklonio ijedan od dva root sertifikata iz svog skladišta.
• Ispravke koje se čekaju. Red Hat, Amazon Linux, Temurin i Corretto do 22. oktobra nisu isporučili ništa; Bunova ispravka je spojena, ali nije objavljena.
• Osnovni uzrok. eMudhra ga nije potvrdila i navela je da će ponovo proveriti svaku ceremoniju generisanja ključeva koju je sprovela.
• Sectigo. U zasebnom slučaju, otvorenom od 5. septembra, Sectigo je odbio da opozove sertifikate čija se proširena namena ključa (extended key usage) nije slagala sa jednom rečenicom u njegovom CPS-u, uz obrazloženje da je ta rečenica dvosmislena. Sectigo je 18. oktobra izbrojao oko 72 miliona takvih sertifikata koji su još aktivni. Neki učesnici javne diskusije zatražili su ukidanje poverenja; nijedan root program nije objavio odluku. Kompanije sa Sectigo sertifikatima trebalo bi da prate ovaj slučaj.

Gde potražiti pomoć

Problem sa sertifikatom retko se predstavi kao problem sa sertifikatom. Pojavi se kao naplata u prodavnici koja prestane da se učitava, integracija koja prestane da se sinhronizuje ili uređaj koji prestane da šalje podatke, obično za vikend. Pomažemo kompanijama da ovakve nedelje prođu bez prekida rada i postavljamo sve tako da sledeća bude rutina:

• Provera izloženosti. Pronalazimo gde vaši sistemi uspostavljaju ili prihvataju TLS veze, koje skladište sertifikata svaki od njih koristi i koje sertifikate vaši serveri šalju, uključujući kontejnere, Java servise, integracije sa bankama, pružaocima usluga plaćanja i logistike, kao i uređaje.
• Ispravke. Ažuriranja, ponovo izgrađene slike, blokirani ključevi ili zamenjeni sertifikati, sprovedeni kroz vaš proces upravljanja promenama i potvrđeni na Mozillinim test serverima.
• Automatizacija za 2027. ACME sa ARI na serverima, load balanserima i mrežnim uređajima, drugo sertifikaciono telo, CAA zapisi, praćenje CT-a i operativni priručnik, spremni za sertifikate od 100 dana od 15. marta 2027.
• Sistemi koje niko ne želi da dira. Stare Java aplikacije, mrežni uređaji i ugrađeni klijenti sa sopstvenim skladištima sertifikata upravo su ono za šta postoji naša usluga održavanja nasleđenih sistema i koda.

Ako niste sigurni da li ste pogođeni, pišite na office@c9group.dev i navedite domene i platforme koje koristite, ili zakažite razgovor. Reći ćemo vam šta prvo da proverite.