Kompromitirani ključi overitelja eMudhra: kaj naj podjetja preverijo in odpravijo zdaj

V soboto, 17. oktobra 2026, je varnostni raziskovalec prijavil, da ima osem vmesnih overiteljev, ki jih upravlja indijski overitelj digitalnih potrdil (CA) eMudhra, zasebne ključe, ki jih lahko vsakdo izračuna iz javnih certifikatov. Vsak od teh ključev je bil število, manjše od 256. Eden od njih je bil število 4. Šest od osmih je lahko izdajalo certifikate TLS, ki jim zaupajo Apple, Google, Microsoft in Mozilla; preostala dva sta lahko podpisovala programsko opremo za Windows.

Chrome je šest ključev TLS blokiral uro in štirideset minut po prijavi, Firefox pa še isti večer. Za ljudi, ki brskajo po spletu, je bila nevarnost do sobote zvečer mimo.

Za vse drugo ni bila. Strežniki, vsebniki, aplikacije v Javi, skripte v Pythonu, plačilne integracije in povezane naprave certifikate preverjajo glede na lastno kopijo seznama zaupanja vrednih overiteljev, večina teh kopij pa se spremeni šele, ko nekdo namesti posodobitev. Do takrat certifikat za katero koli domeno, podpisan z enim od teh ključev, velja za pristnega, ključi pa so javni od 20. oktobra.

Isti teden je GoDaddy začel preklicevati 404.607 certifikatov, ker se podatki o politiki v njih niso ujemali z njegovimi lastnimi objavljenimi dokumenti. Njegove stranke so morale nadomestne certifikate same prenesti in namestiti.

Ta vodnik je za tiste, ki morajo odgovoriti na vprašanje „ali nas to zadeva?“: vodje IT in operativnih ekip, tehnične direktorje in ustanovitelje, katerih posel teče na spletnem mestu, API-ju ali povezanem izdelku. Opisuje, kaj se je zgodilo (po zapisih o incidentu, ki so jih objavili Mozilla, Google, eMudhra, GoDaddy in proizvajalci programske opreme), kaj preveriti danes, kaj posodobiti ta teden in kaj vzpostaviti, da bo naslednji tak incident rutina. Vse navedeno velja na dan 22. oktobra 2026, incident pa je še odprt.

Kaj se je zgodilo

eMudhra je osem vmesnih overiteljev ustvarila na ceremoniji generiranja ključev 30. aprila 2025. Njen opis, ki ga je 19. oktobra objavila v Mozillinem zahtevku o incidentu: preizkus koraka ovijanja in razvijanja ključa (key wrap in unwrap), odobren kot odstopanje od običajnega postopka, je imel napako, zaradi katere je v strojnem varnostnem modulu (HSM) poleg predvidenih ključev nastal še drugi, šibek nabor ključev. Oznake so bile podobne, šibki ključi so bili pomotoma uporabljeni za izdelavo zahtev za certifikat, eMudhra pa jih je podpisala s svojim korenskim certifikatom. Iste zahteve so šle k Sectigu, ki je vseh osem 14. maja 2025 navzkrižno podpisal s svojim korenskim certifikatom AAA Certificate Services. eMudhra pravi, da „natančnega temeljnega vzroka še ni potrdila“.

Mozilla je posledico opisala tako: „Zasebni ključi P384 so naključno izbrana cela števila med 1 in redom grupe. Vseh 8 prizadetih ključev je uporabljalo cela števila, manjša od 256.“ Mozilla je prijavo prejela ob 20:06 UTC, ključe pa je sama pridobila ob 21:48, „brez kakršnega koli poznavanja metode, ki jo je uporabil prvotni prijavitelj“. Raziskovalec pravi, da jih je našel z Googlovo odprtokodno knjižnico paranoid_crypto, „kar takoj, brez prilagoditev“. Šibki ključi so bili del javno zaupanja vrednih verig skoraj 18 mesecev.

Osem certifikatov:

Vsak ključ je v dveh certifikatih. Enega je izdal eMudhrin emSign Root TLS CA - G3 ali emSign Root CS CA - G3, katerih veriga vodi do emSign ECC Root CA - G3; drugi je Sectigov navzkrižni certifikat iz AAA Certificate Services. Druga pot je pomembna, ker nekatere shrambe certifikatov (trust store), ki korenskega certifikata eMudhra niso nikoli vsebovale, še vedno zaupajo temu staremu korenskemu certifikatu Sectigo.

Je bil kdo napaden?

Zlorabe ni prijavil nihče, za brskalnike pa obstaja dober razlog za domnevo, da je ni bilo. Chrome, tako kot drugi odjemalci, ki uveljavljajo Certificate Transparency (CT), sprejme certifikat le, če je bil zabeležen v javnih dnevnikih CT. Google: pred njegovo blokado v dnevnikih ni bil zabeležen noben certifikat TLS, katerega veriga vodi do teh šestih vmesnih overiteljev, zato „nobenega lažnega certifikata, ki bi ga izdali ti overitelji, ni bilo mogoče uporabiti proti odjemalcem, ki uveljavljajo CT“.

Zunaj brskalnika je slika drugačna. Mozillina stran o incidentu: „številni odjemalci zunaj ekosistema brskalnikov ne uveljavljajo Certificate Transparency. Ne vemo, ali so napadalci napako pri generiranju ključev izkoristili za napade na te odjemalce.“ To okno se je odprlo spomladi 2025 in se za posameznega odjemalca zapre šele, ko je ta posodobljen. eMudhra pravi, da ne ve za noben dokaz, da bi bil kdo ključe pridobil pred razkritjem, Cloudflare pa pravi, da njegov pregled ni odkril aktivnega izkoriščanja v njegovih storitvah.

Zdaj, ko so ključi javni, ponarejanje certifikata ne zahteva nobenega znanja. Mozillina stran o incidentu navaja preizkusne strežnike, ki pošiljajo certifikate, izdane s kompromitiranimi ključi, da lahko vsakdo z njimi preveri svoje odjemalce (ukazi so spodaj).

Kaj omogoča ponarejen certifikat: kdor lahko prestreže promet med vašo programsko opremo in storitvijo, ki jo ta kliče (v skupnem omrežju, prek kompromitiranega usmerjevalnika ali zastrupljenega odgovora DNS), se lahko izdaja za to storitev, bere, kar vaša programska oprema pošilja, vključno s ključi API in osebnimi podatki, ter spreminja, kar prejema. Programska oprema, podpisana z enim od obeh ključev za podpisovanje kode, bi prestala preverjanje podpisa v sistemu Windows, dokler Microsoftova blokada ne bi dosegla računalnika.

Koga to zadeva

Gre za tri ločene težave in eno podjetje ima lahko vse tri.

1. Programska oprema, ki še vedno zaupa kompromitiranim ključem

To težavo ima skoraj vsako podjetje: vsak program, ki kliče prek HTTPS, katerega shramba certifikatov še vedno vsebuje emSign ECC Root CA - G3 ali AAA Certificate Services in ki ni prejel blokade za osem ključev. Tipična mesta:

• Strežniki Linux in slike vsebnikov, zgrajene pred 20. ali 21. oktobrom. Nepopravljen Debian 12 na primer zaupa obema verigama.
• Izvajalna okolja programskih jezikov, ki imajo lasten seznam: Node.js, certifi za Python, cacerts v Javi, Composerjev paket certifikatov za PHP, webpki-roots za Rust.
• Orodja ukazne vrstice v macOS. Mozillina stran o incidentu navaja, da vgrajeni curl, git, python3, perl, ruby in openssl certifikate preverjajo glede na /etc/ssl/cert.pem, ne da bi preverjali preklic, in da Apple te datoteke ni posodobil.
• Računalniki z Windows, ki ne prejemajo Microsoftovih samodejnih posodobitev seznama nedovoljenih certifikatov, običajno zato, ker jih pravilnik skupine (Group Policy) izklopi ali ker je omrežje brez povezave.
• Namenske naprave, druge naprave in programska oprema tretjih oseb z lastno datoteko CA, na primer izenačevalniki obremenitve, prehodi VPN, kompleti SDK in vgrajeni krmilniki.

Vsako izvajalno okolje je treba preveriti posebej. V preizkusu, ki smo ga izvedli 22. oktobra, je nepopravljen računalnik z Debianom 12 in Node.js 24.18 sprejel verigo, ki se konča pri korenskem certifikatu eMudhra, in zavrnil tisto, ki se konča pri Sectigovem, Python na istem računalniku pa je sprejel obe.

2. Podjetja, katerih lastni certifikati vodijo do odstranjenega korenskega certifikata

Mozilla in distribucije Linuxa so emSign ECC Root CA - G3 odstranile, Chrome jim sledi 27. oktobra. Veljavni certifikati pod tem korenskim certifikatom prenehajo delovati v vsakem odjemalcu, ko se ta posodobi. Googlovo navodilo: upravljavci spletnih mest s takimi certifikati „morajo takoj pridobiti in namestiti nov certifikat TLS iz druge hierarhije PKI, vključene v Chrome Root Store“.

Chrome je 21. oktobra v CT naštel približno 30.800 še ne poteklih certifikatov pod tem korenskim certifikatom. Od tega jih je 30.791 prišlo od dveh vmesnih overiteljev InCommon, storitve za certifikate, ki jo Internet2 upravlja za ameriške univerze in raziskovalne ustanove in ki certifikate ECC izdaja prek CERTInext, platforme eMudhra. 18 jih je prišlo od lastnih vmesnih overiteljev eMudhra. eMudhra pravi, da je treba preseliti približno 30.000 certifikatov, od tega jih je bilo približno 97 % izdanih prek ACME, in da nadomestne certifikate izdaja iz druge hierarhije.

Če je vaše spletno mesto za Cloudflarom v načinu Full (strict) in izvorni strežnik pošilja certifikat pod tem korenskim certifikatom, Cloudflare pravi, da bi odvzem zaupanja „povzročil okvare“, in stranke prosi: „Preglejte svoje izvorne certifikate po meri in konfiguracije strežnikov“.

Certifikati RSA iz drugega korenskega certifikata eMudhra, emSign Root CA - G1, zaenkrat niso prizadeti. Mozilla pravi, da tega korenskega certifikata „v tem trenutku“ ne odstranjuje; Chrome „natančno preiskuje nadaljnjo vključenost preostalih certifikatov CA družbe eMudhra“. Če ste odvisni od kakršnih koli certifikatov eMudhra ali CERTInext, si že zdaj zagotovite drugega overitelja.

3. Stranke GoDaddyja

Primer GoDaddyja z eMudhro nima nobene zveze, a se je zgodil isti teden in prizadel veliko več spletnih mest. GoDaddy je 15. oktobra Mozilli prijavil, da so certifikati iz njegovih hierarhij GoDaddy in Starfield vsebovali podatke o politiki certifikatov (OID-je politik in povezave na CPS), ki se niso ujemali s profili v njegovem lastnem CP/CPS, dokumentu, v katerem overitelj navaja, kaj izdaja. To ni varnostna napaka v certifikatih. Po Baseline Requirements, pravilih, ki jih upošteva vsak javni overitelj, je to vseeno razlog, da jih prekliče v petih dneh.

Prizadetih je bilo 404.607 certifikatov, od tega 396.055 z overjeno domeno (DV). GoDaddy je do roka 18. oktobra ob 23:45 UTC preklical 170.566 certifikatov, do naslednjega jutra pa 227.422; njegovo obvestilo strankam navaja, da so bili preostali preklicani 21. oktobra. GoDaddy certifikate izda znova, namestitev pa je stvar stranke: „obiskovalci vašega spletnega mesta bodo morda videli varnostna opozorila in vaše spletno mesto bo morda nedostopno, dokler ne namestite novega certifikata.“

Kaj preveriti danes

1. Kaj pošiljajo vaši strežniki? Za vsako javno ime gostitelja izpišite izdajatelje v verigi, ki jo gostitelj pošilja:

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

Vrstica, ki omenja eMudhro, emSign, enega od overiteljev EM ... G3B ali G3C ali pa InCommon Intermediate CA - DVG3C, OVG3C ali EVG3C, pomeni, da je treba certifikat zamenjati pred 27. oktobrom. AAA Certificate Services sam po sebi je običajen, saj ga številne navadne verige Sectigo še vedno vsebujejo. Za poštne in imeniške storitve dodajte -starttls smtp (ali imap, ldap) in ustrezna vrata. Vključite notranje gostitelje, izenačevalnike obremenitve in izvorne strežnike za omrežjem CDN.

2. Kaj je bilo izdano za vaše domene? CT navaja vsak certifikat, ki ga je javni overitelj izdal za vaša imena, tudi tiste, za katere se nihče v podjetju ne spomni, da bi jih naročil:

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

Izpis pokaže tudi, katere overitelje vaše podjetje dejansko uporablja, in to je začetek popisa, opisanega v nadaljevanju.

3. Ali vaši odjemalci zaupajo kompromitiranim ključem? Mozillini preizkusni strežniki pošiljajo certifikate, izdane pod kompromitiranimi ključi, zato je napaka certifikata dober rezultat. Preizkusite obe družini: prvi gostitelj vodi do korenskega certifikata eMudhra, drugi do Sectigovega, shramba certifikatov pa lahko pri enem preizkusu pade, drugega pa prestane.

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 odgovarja samo za curl. Isto zahtevo izvedite prek lastnega sklada TLS vsake aplikacije, v okolju, v katerem aplikacija teče:

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

Vrstici za Python nista odveč: urllib uporablja shrambo certifikatov operacijskega sistema, requests pa certifi. Vsako vrstico ponovite z gostiteljem dv-g3b-aaa-emudhra. Pri Javi iz zadevnega JVM izvedite kakršen koli klic HTTPS do preizkusnih strežnikov in preverite, ali njegova shramba vsebuje katerega od obeh korenskih certifikatov (Java 9 ali novejša; pri Javi 8 uporabite -keystore $JAVA_HOME/jre/lib/security/cacerts):

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

Korenski certifikat v shrambi sam po sebi še ne dokazuje izpostavljenosti, ker Go, Node.js, Deno in rustls-webpki za Rust zdaj blokirajo osem ključev ne glede na to, kaj je v shrambi. Odločijo preizkusni strežniki.

4. Računalniki z Windows. Microsoft o incidentu ni objavil ničesar, seznam nedovoljenih certifikatov, ki ga Windows prenaša samodejno, pa od 20. oktobra blokira vseh osem ključev. Izjeme so računalniki, na katerih pravilnik skupine izklopi samodejne posodobitve korenskih certifikatov, in omrežja brez poti do storitve Windows Update; tem je treba seznam dostaviti drugače. certutil -verifyCTL Disallowed pokaže kopijo, ki jo ima računalnik v predpomnilniku. Mozillina stran o incidentu ponuja skript za posamezne računalnike in navaja, da „ni priporočljiv za naprave, ki jih upravlja podjetje“.

5. Certifikati GoDaddy. Preverite, kateri certifikat posamezen strežnik dejansko pošilja:

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

Če je izdajatelj GoDaddy ali Starfield, primerjajte serijsko številko s certifikati v svojem računu GoDaddy. Kjer GoDaddy prikazuje „Install your new certificate“ (namestite novi certifikat), je na strežniku še vedno preklicani certifikat.

Eno pravilo velja ves čas: napake ne odpravite tako, da izklopite preverjanje certifikatov. Kot pravi Cloudflare: „Pomembno je, da teh napak ne odpravite z onemogočanjem preverjanja.“ Odjemalec, ki ne preverja, zaupa vsakemu ponarejenemu certifikatu, ne le tem.

Kaj posodobiti ta teden

Popravki so dveh vrst. Odstranitev obeh korenskih certifikatov zapre vse poti za odjemalca, ki uporablja to shrambo, a pokvari tudi veljavne certifikate pod njima. Blokiranje osmih ključev po zgoščeni vrednosti javnega ključa, kot to počnejo Go, Node.js, Deno, Electron, rustls-webpki, Composer in Windows, luknjo zapre in ničesar drugega ne pokvari. Kjer vaša platforma ponuja drugo možnost, ji dajte prednost.

„Še ni“ pomeni, da do 22. oktobra ni bilo objavljeno nič. Preden na tem gradite načrt, preverite znova.

Ekipe se pogosto ujamejo pri štirih stvareh:

• Slike vsebnikov obdržijo stari seznam. Slika, zgrajena pred 20. ali 21. oktobrom, ključem zaupa, dokler je ne zgradite znova na posodobljeni osnovni sliki, prenos iste oznake pa pomaga šele, ko je osnovna slika ponovno zgrajena. Zgradite znova, ponovno uvedite in vprašajte proizvajalce, katerih slike uporabljate.
• Procesi obdržijo, kar so naložili. Program prebere shrambo certifikatov ob zagonu, zato po posodobitvi znova zaženite dolgo delujoče storitve. Node.js dodaja, da seje TLS, nadaljevane iz časa pred nadgradnjo, niso ponovno preverjene.
• Aplikacije imajo lastne datoteke CA. Kompleti SDK in aplikacije pogosto vsebujejo lasten cacert.pem ali ca-bundle.crt. Poiščite jih v repozitorijih in slikah, na primer z find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, in pričakujte več kot enega: pip ima na primer lastno kopijo certifi.
• Naprave čakajo na proizvajalca. Vsakega proizvajalca pisno vprašajte, katero shrambo certifikatov izdelek uporablja in kdaj bo posodobitev izšla. Dokler ne izide, naprava zaupa ponarejenim certifikatom za vsako storitev, ki jo kliče, zato omejite, kaj lahko doseže.

Če AAA Certificate Services odstranite ročno, kot to storijo Debian, Ubuntu ESM, Fedora in začasna rešitev Red Hata, nato preizkusite povezave do storitev s certifikati Sectigo: nekateri starejši strežniki še vedno pošiljajo verigo, ki se konča pri tem korenskem certifikatu.

Kaj vzpostaviti pred naslednjim incidentom

Overitelj s tako šibkimi ključi je redkost. Množični preklici niso. To so veliki preklici iz leta 2026, zabeleženi v Mozillinem sistemu za sledenje napakam:

Nobeden od teh petih primerov ni bil varnostni spodrsljaj. V vsakem se je certifikat razhajal z lastnim dokumentom overitelja, Baseline Requirements (razdelek 4.9.1.1) pa kljub temu zahtevajo preklic v petih dneh. Ko je ključ kompromitiran ali se na overitev domene ni mogoče zanesti, je rok 24 ur. Nihče vam ga ne more podaljšati. Ob DigiCertovem preklicu 83.267 certifikatov leta 2024 je Chrome Root Program zapisal, da „nima pooblastila za odobritev izjem“; ena od strank je dosegla sodno odredbo, ki je preklic njenih certifikatov ustavila, odredba pa je bila štiri dni pozneje razveljavljena.

Potek zamenjav veliko pove. HARICA je julija prek ACME Renewal Information (ARI) odjemalcem ACME svojih strank sporočila, naj certifikate obnovijo predčasno, druge certifikate pa je znova izdala sama; pri večjem od njenih dveh preklicev je bilo ob izteku roka zamenjanih 87 % prizadetih imen. GoDaddy, katerega stranke vsak nadomestni certifikat prenesejo in namestijo same, je do svojega roka preklical 42 % prizadetih certifikatov.

Cikel obnavljanja se tako ali tako krajša:

• V skladu z glasovanjem CA/Browser Forum SC-081 je veljavnost javnih certifikatov TLS od 15. marca 2026 omejena na 200 dni. Omejitev se 15. marca 2027 zniža na 100 dni, 15. marca 2029 pa na 47 dni, ko bo overitev domene mogoče ponovno uporabiti le 10 dni.
• Let's Encrypt 10. februarja 2027 privzeto preide na certifikate s 64-dnevno veljavnostjo, leto pozneje pa na 45 dni.
• Javni certifikati TLS izgubljajo overjanje odjemalca. Let's Encrypt ga je 8. julija 2026 prenehal vključevati v certifikate, Chrome Root Program pa zahteva, da so certifikati, izdani od 15. marca 2027, namenjeni samo overjanju strežnika. Če javne certifikate uporabljate kot odjemalske certifikate za vzajemni TLS (mutual TLS), kar je pogosto pri integracijah API med podjetji, te povezave potrebujejo zasebnega overitelja.

Pri 100 dneh, nato pa pri 47, ročno nameščanje certifikatov ni več realna možnost. Podjetje, ki avtomatizira za ta urnik, je pripravljeno tudi na naslednji množični preklic. Kaj je za to potrebno:

1. Vedite, kaj imate, v obe smeri. En seznam vseh certifikatov, ki jih strežete, z imenom gostitelja, izdajateljem, potekom veljavnosti, načinom obnavljanja in lastnikom. Drugi seznam vseh shramb certifikatov, na katere se zanaša vaša programska oprema: paket operacijskega sistema, vsak paket certifikatov programskega jezika, vsaka datoteka CA v aplikaciji ali napravi. Iskanje po CT zgoraj je začetek prvega seznama; seznam programskih sestavin (SBOM) ali popis odvisnosti je začetek drugega.
2. Avtomatizirajte izdajo in namestitev. ACME povsod, kjer lahko teče, z ARI (RFC 9773), da lahko overitelj vašim odjemalcem sporoči, naj certifikate obnovijo predčasno. Kjer naprava ACME ne more poganjati, uporabite avtomatizacijo proizvajalca ali pa TLS zaključite pred njo, na nečem, kar to zmore.
3. Imejte pripravljenega drugega overitelja. Delujoč in preizkušen račun ACME pri drugem overitelju ter zapise CAA v DNS, ki dovoljujejo oba. Ko enemu overitelju odvzamejo zaupanje ali ta množično prekliče certifikate, je zamenjava le še sprememba konfiguracije.
4. Spremljajte CT za svoje domene. Prejmite opozorilo za vsak nov certifikat za vaša imena. O nepričakovani izdaji izveste isti dan, ko se zgodi.
5. Shrambe certifikatov obravnavajte kot odvisnosti. Posodabljajte jih z običajnim nameščanjem popravkov, slike pa gradite znova po urniku, ne le ob spremembah kode.
6. Priročnik za ukrepanje (runbook) napišite za oba roka. 24 ur in pet dni: kdo odloča, kdo ima dostop do posameznega sistema, kateri sistemi zahtevajo ročne korake, kako doseči posameznega proizvajalca. Enkrat na leto ga vadite tako, da zamenjate certifikat na storitvi, ki si lahko privošči napako. Javni overitelji morajo od leta 2025 imeti in preizkušati lasten načrt za množični preklic; njihove stranke potrebujejo drugo polovico.

Če izdelujete izdelke, ki jih uporabljajo drugi

Če vaš izdelek vsebuje shrambo certifikatov (naprava, nameščena aplikacija, SDK), so vaše stranke zaščitene šele, ko jih doseže vaša posodobitev. Izdajte jo in strankam povejte, katere različice so popravljene. Mozillin nasvet upravljavcem shramb certifikatov: blokirajte osem vmesnih overiteljev, če vaša programska oprema to zmore, sicer „razmislite, ali je primerno odvzeti zaupanje korenskim certifikatom, ki so podpisali te vmesne overitelje“.

Akt o kibernetski odpornosti je tu pomemben na dva načina. Njegova obveznost prijave, ki velja od 11. septembra 2026, zajema aktivno izkoriščane ranljivosti, v tem primeru pa izkoriščanje ni bilo prijavljeno. Njegove bistvene zahteve, ki se uporabljajo od 11. decembra 2027, vključujejo, da je ranljivosti mogoče odpraviti z varnostnimi posodobitvami; izdelek, katerega seznama zaupanja vrednih overiteljev ni mogoče posodobiti, jih ne bi izpolnjeval. Stranke, za katere velja direktiva NIS2, bodo dobavitelje spraševale, kako hitro so to obravnavali, in pomaga, če je odgovor zapisan.

Kaj je še odprto

• Preostali korenski certifikat eMudhra. Chrome je eMudhri 21. oktobra zastavil dvanajst vprašanj in o emSign Root CA - G1 ni objavil nobene odločitve. Mozilla ga „v tem trenutku“ ne odstranjuje.
• Pot selitve pri eMudhri. Mozilli je sporočila, da bo stranke preselila v svojo hierarhijo G1 (RSA); njena stran s stanjem storitev govori o „drugi, neodvisno upravljani, javno zaupanja vredni hierarhiji CA“. Chrome je vprašal, katera je to.
• Microsoft in Apple. Nobeden ni objavil izjave ali iz svoje shrambe odstranil katerega od obeh korenskih certifikatov.
• Popravki v pripravi. Red Hat, Amazon Linux, Temurin in Corretto do 22. oktobra niso izdali ničesar; Bunov popravek je bil združen, ni pa še izdan.
• Temeljni vzrok. eMudhra ga ni potrdila in je sporočila, da bo znova preverila vse ceremonije generiranja ključev, ki jih je kdaj izvedla.
• Sectigo. V ločenem primeru, odprtem od 5. septembra, je Sectigo zavrnil preklic certifikatov, katerih razširjena uporaba ključa (extended key usage) se ni ujemala z enim od stavkov v njegovem CPS, z utemeljitvijo, da je bil stavek dvoumen. Po njegovem štetju jih je bilo 18. oktobra še približno 72 milijonov aktivnih. Nekateri udeleženci javne razprave so pozvali k odvzemu zaupanja; noben program korenskih certifikatov ni objavil odločitve. Podjetja s certifikati Sectigo naj primer spremljajo.

Kje dobiti pomoč

Težava s certifikatom se redko pokaže kot taka. Pokaže se kot blagajna spletne trgovine, ki se neha nalagati, integracija, ki se neha sinhronizirati, ali naprava, ki neha poročati, običajno med vikendom. Podjetjem pomagamo prebroditi tedne, kot je ta, brez izpada in stvari nastaviti tako, da bo naslednji tak teden rutina:

• Preverjanje izpostavljenosti. Ugotovimo, kje vaši sistemi vzpostavljajo ali sprejemajo povezave TLS, katero shrambo certifikatov uporablja posamezen sistem in katere certifikate strežete, vključno z vsebniki, storitvami v Javi, integracijami z bankami, ponudniki plačil in logistike ter napravami.
• Popravki. Posodobitve, ponovno zgrajene slike, blokirani ključi ali zamenjani certifikati, izvedeni prek vašega postopka upravljanja sprememb in preverjeni z Mozillinimi preizkusnimi strežniki.
• Avtomatizacija za leto 2027. ACME z ARI na strežnikih, izenačevalnikih obremenitve in namenskih napravah, drugi overitelj, zapisi CAA, spremljanje CT in priročnik za ukrepanje, vse pripravljeno za certifikate s 100-dnevno veljavnostjo od 15. marca 2027.
• Sistemi, ki se jih nihče noče dotakniti. Stare aplikacije v Javi, namenske naprave in vgrajeni odjemalci z lastnimi shrambami certifikatov so tisto, za kar je namenjena naša storitev vzdrževanja podedovanih sistemov in kode.

Če niste prepričani, ali vas to zadeva, pišite na office@c9group.dev in navedite domene in platforme, ki jih uporabljate, ali pa rezervirajte pogovor. Povedali vam bomo, kaj preveriti najprej.