eMudhra CA raktų kompromitavimas: ką įmonės turėtų patikrinti ir ištaisyti dabar

2026 m. spalio 17 d., šeštadienį, saugumo tyrėjas pranešė, kad aštuonių tarpinių sertifikavimo įstaigų (CA), kurias valdo Indijos sertifikavimo įstaiga eMudhra, privačiuosius raktus bet kas galėjo apskaičiuoti iš viešų sertifikatų. Kiekvienas iš šių raktų buvo skaičius, mažesnis nei 256. Vienas jų buvo skaičius 4. Šešios iš aštuonių galėjo išduoti TLS sertifikatus, kuriais pasitiki Apple, Google, Microsoft ir Mozilla; kitos dvi galėjo pasirašyti Windows programinę įrangą.

Chrome užblokavo šešis TLS raktus praėjus valandai ir keturiasdešimčiai minučių po pranešimo, o Firefox tą patį vakarą. Žmonėms, naršantiems internete, pavojus baigėsi jau šeštadienio naktį.

Visam kitam jis nesibaigė. Serveriai, konteineriai, Java programos, Python scenarijai, mokėjimų integracijos ir prijungiamieji įrenginiai sertifikatus tikrina pagal savo patikimų sertifikavimo įstaigų sąrašo kopiją, o dauguma tokių kopijų pasikeičia tik tada, kai kas nors įdiegia atnaujinimą. Iki tol bet kurio domeno sertifikatas, pasirašytas vienu iš šių raktų, praeina kaip tikras, o patys raktai vieši nuo spalio 20 d.

Tą pačią savaitę GoDaddy pradėjo atšaukti 404 607 sertifikatus, nes juose esanti politikos informacija neatitiko jos pačios paskelbtų dokumentų. Pakaitinius sertifikatus klientai turėjo atsisiųsti ir įdiegti patys.

Šis vadovas skirtas tiems, kam tenka atsakyti į klausimą „ar mus tai paveikė?“: IT ir operacijų vadovams, technologijų vadovams (CTO) ir įkūrėjams, kurių verslas priklauso nuo svetainės, API ar prijungiamojo produkto. Jame aprašoma, kas įvyko (remiantis incidentų įrašais, kuriuos paskelbė Mozilla, Google, eMudhra, GoDaddy ir programinės įrangos tiekėjai), ką patikrinti šiandien, ką atnaujinti šią savaitę ir ką įdiegti, kad kitas tokio pobūdžio incidentas būtų įprastas darbas. Visa informacija pateikiama 2026 m. spalio 22 d. būklei, o incidentas dar neužbaigtas.

Kas įvyko

Aštuonias tarpines sertifikavimo įstaigas eMudhra sukūrė 2025 m. balandžio 30 d. per raktų generavimo ceremoniją. Jos paaiškinimas, spalio 19 d. paskelbtas Mozilla incidento įraše: rakto įvyniojimo ir išvyniojimo (key wrap ir unwrap) žingsnio bandymas, patvirtintas kaip nukrypimas nuo įprastos procedūros, turėjo trūkumą, dėl kurio aparatinės įrangos saugumo modulyje (HSM) šalia numatytų raktų atsirado antras, silpnų raktų rinkinys. Žymės buvo panašios, silpni raktai per klaidą buvo panaudoti sertifikatų užklausoms sukurti, ir eMudhra šakninis sertifikatas tas užklausas pasirašė. Tos pačios užklausos nukeliavo ir pas Sectigo, kuri 2025 m. gegužės 14 d. visas aštuonias kryžmiškai pasirašė savo šakniniu sertifikatu AAA Certificate Services. eMudhra teigia, kad „dar nepatvirtino tikslios pagrindinės priežasties“.

Mozilla rezultatą apibūdino taip: „P384 privatieji raktai yra atsitiktinai parenkami sveikieji skaičiai nuo 1 iki grupės eilės. Visi 8 paveikti raktai naudojo sveikuosius skaičius, mažesnius nei 256.“ Mozilla pranešimą gavo 20:06 UTC, o 21:48 raktus atkūrė pati, „visiškai nežinodama, kokį metodą naudojo pirminis pranešėjas“. Tyrėjas teigia, kad raktus rado su Google atvirojo kodo biblioteka paranoid_crypto, „be jokių pakeitimų“. Silpni raktai beveik 18 mėnesių buvo viešai patikimų grandinių dalis.

Aštuoni sertifikatai:

Kiekvienas raktas yra dviejuose sertifikatuose. Vieną išdavė eMudhra emSign Root TLS CA - G3 arba emSign Root CS CA - G3, kurių grandinė veda iki emSign ECC Root CA - G3; kitas yra Sectigo kryžminis sertifikatas iš AAA Certificate Services. Antrasis kelias svarbus, nes kai kurios patikimų sertifikatų saugyklos, niekada neturėjusios eMudhra šakninio sertifikato, vis dar pasitiki tuo senu Sectigo šakniniu sertifikatu.

Ar kas nors buvo užpultas?

Apie piktnaudžiavimą niekas nepranešė, o naršyklių atveju yra rimta priežastis manyti, kad jo nebuvo. Chrome, kaip ir kiti klientai, reikalaujantys Certificate Transparency (CT), priima sertifikatą tik tada, kai jis įrašytas į viešuosius CT žurnalus. Google: iki jos blokavimo nebuvo įrašytas nė vienas TLS sertifikatas, kurio grandinė veda iki šių šešių tarpinių sertifikatų, todėl „jokie šių CA išduoti suklastoti sertifikatai negalėjo būti panaudoti prieš CT reikalaujančius klientus“.

Už naršyklės ribų vaizdas kitoks. Mozilla incidento puslapyje rašoma: „daugelis klientų už naršyklių ekosistemos ribų nereikalauja Certificate Transparency. Mes nežinome, ar užpuolikai išnaudojo ydingą raktų generavimą, kad nusitaikytų į šiuos klientus.“ Šis langas atsivėrė 2025 m. pavasarį ir kiekvienam klientui užsiveria tik tada, kai tas klientas atnaujinamas. eMudhra teigia nežinanti jokių įrodymų, kad raktai buvo atkurti iki paskelbimo, o Cloudflare teigia, kad jos peržiūra aktyvaus išnaudojimo jos paslaugose neaptiko.

Dabar, kai raktai vieši, sertifikatui suklastoti nereikia jokių įgūdžių. Mozilla incidento puslapyje išvardyti bandomieji serveriai, pateikiantys kompromituotais raktais išduotus sertifikatus, kad kiekvienas galėtų su jais patikrinti savo klientus (komandos pateiktos toliau).

Ką leidžia suklastotas sertifikatas: tas, kuris gali perimti srautą tarp jūsų programinės įrangos ir paslaugos, į kurią ji kreipiasi (bendrame tinkle, per pažeistą maršrutizatorių ar suklastotą DNS atsakymą), gali apsimesti ta paslauga, skaityti, ką siunčia jūsų programinė įranga, įskaitant API raktus ir asmens duomenis, ir keisti tai, ką ji gauna. Programinė įranga, pasirašyta vienu iš dviejų kodo pasirašymo raktų, būtų praėjusi Windows parašo patikrą, kol kompiuterio nepasiekė Microsoft blokavimas.

Kam tai aktualu

Yra trys atskiros problemos, ir viena įmonė gali turėti jas visas.

1. Programinė įranga, kuri vis dar pasitiki kompromituotais raktais

Šią problemą turi beveik kiekviena įmonė: tai bet kuri HTTPS užklausas daranti programa, kurios patikimų sertifikatų saugykloje vis dar yra emSign ECC Root CA - G3 arba AAA Certificate Services ir kuri nėra gavusi šių aštuonių raktų blokavimo. Įprastos vietos:

• Linux serveriai ir konteinerių atvaizdai, sukurti iki spalio 20 ar 21 d. Pavyzdžiui, neatnaujintas Debian 12 pasitiki abiem grandinėmis.
• Kalbų vykdymo aplinkos, turinčios savo sąrašą: Node.js, Python certifi, Java cacerts, PHP Composer rinkinys, Rust webpki-roots.
• macOS komandinės eilutės įrankiai. Mozilla incidento puslapyje teigiama, kad integruoti curl, git, python3, perl, ruby ir openssl sertifikatus tikrina pagal /etc/ssl/cert.pem, netikrindami atšaukimo, ir kad Apple šio failo neatnaujino.
• Windows kompiuteriai, negaunantys automatinių Microsoft draudžiamų sertifikatų sąrašo atnaujinimų, dažniausiai todėl, kad juos išjungia grupės strategija (Group Policy) arba tinklas neprijungtas prie interneto.
• Specializuoti įrenginiai, prietaisai ir trečiųjų šalių programinė įranga su savo CA failu, pavyzdžiui, apkrovos balansavimo įrenginiai, VPN šliuzai, SDK ir įterptiniai valdikliai.

Kiekvieną vykdymo aplinką reikia patikrinti atskirai. Mūsų spalio 22 d. atliktame bandyme neatnaujintas Debian 12 kompiuteris su Node.js 24.18 priėmė grandinę, kuri baigiasi eMudhra šakniniu sertifikatu, ir atmetė tą, kuri baigiasi Sectigo šakniniu sertifikatu, o Python tame pačiame kompiuteryje priėmė abi.

2. Įmonės, kurių pačių sertifikatų grandinė veda iki pašalinto šakninio sertifikato

Mozilla ir Linux distribucijos jau pašalino emSign ECC Root CA - G3, o spalio 27 d. tą patį padarys Chrome. Galiojantys sertifikatai, kurių grandinė veda iki šio šakninio sertifikato, kiekviename kliente nustoja veikti, kai tas klientas atnaujinamas. Google nurodymas: svetainių operatoriai, turintys tokių sertifikatų, „privalo nedelsdami įsigyti ir įdiegti naują TLS sertifikatą iš kitos PKI hierarchijos, įtrauktos į Chrome Root Store“.

Spalio 21 d. Chrome CT žurnaluose suskaičiavo apie 30 800 sertifikatų po šiuo šakniniu sertifikatu, kurių galiojimas dar nepasibaigė. Iš jų 30 791 kilo iš dviejų InCommon tarpinių sertifikatų. InCommon yra sertifikatų paslauga, kurią Internet2 teikia JAV universitetams ir mokslinių tyrimų institucijoms ir kuri ECC sertifikatus išduoda per eMudhra platformą CERTInext. Iš pačios eMudhra tarpinių sertifikatų kilo 18. eMudhra teigia, kad perkelti reikia apie 30 000 sertifikatų, iš kurių apie 97 proc. išduoti per ACME, ir kad pakaitinius sertifikatus ji išduoda iš kitos hierarchijos.

Jei jūsų svetainė veikia už Cloudflare režimu Full (strict), o pradinis serveris (origin) pateikia sertifikatą po šiuo šakniniu sertifikatu, Cloudflare teigia, kad pasitikėjimo panaikinimas „sukeltų gedimų“, ir prašo klientų „peržiūrėti savo pasirinktinius pradinių serverių sertifikatus ir serverių konfigūracijas“.

RSA sertifikatų iš kito eMudhra šakninio sertifikato, emSign Root CA - G1, tai kol kas neliečia. Mozilla teigia, kad šio šakninio sertifikato „šiuo metu“ nešalina; Chrome „atidžiai tiria tolesnį likusių eMudhra CA sertifikatų įtraukimą“. Jei priklausote nuo bet kokių eMudhra ar CERTInext sertifikatų, jau dabar pasirūpinkite antra sertifikavimo įstaiga.

3. GoDaddy klientai

GoDaddy atvejis su eMudhra nesusijęs, bet jis įvyko tą pačią savaitę ir palietė gerokai daugiau svetainių. Spalio 15 d. GoDaddy pranešė Mozilla, kad jos GoDaddy ir Starfield hierarchijų sertifikatuose buvo sertifikato politikos informacija (politikos OID ir CPS nuorodos), neatitinkanti jos pačios CP/CPS, t. y. dokumento, kuriame sertifikavimo įstaiga nurodo, ką ji išduoda, profilių. Tai nėra saugumo spraga pačiuose sertifikatuose. Tačiau pagal Baseline Requirements, taisykles, kurių laikosi kiekviena viešoji sertifikavimo įstaiga, tai vis tiek yra priežastis juos atšaukti per penkias dienas.

Paveikti buvo 404 607 sertifikatai, iš jų 396 055 su domeno patvirtinimu (DV). Iki termino, spalio 18 d. 23:45 UTC, GoDaddy atšaukė 170 566, o iki kito ryto 227 422; jos pranešime klientams teigiama, kad likusieji atšaukti spalio 21 d. GoDaddy sertifikatus išduoda iš naujo, bet juos įdiegti turi pats klientas: „jūsų svetainės lankytojai gali matyti saugumo įspėjimus, o jūsų svetainė gali tapti nepasiekiama, kol nebus įdiegtas naujas sertifikatas.“

Ką patikrinti šiandien

1. Ką siunčia jūsų pačių serveriai? Kiekvienam viešam serverio vardui (hostname) išvardykite jo pateikiamos grandinės išdavėjus:

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

Eilutė, kurioje minima eMudhra, emSign, viena iš EM ... G3B ar G3C sertifikavimo įstaigų arba InCommon Intermediate CA - DVG3C, OVG3C ar EVG3C, reiškia, kad sertifikatą reikia pakeisti iki spalio 27 d. Vien AAA Certificate Services yra normalu, nes daugelyje įprastų Sectigo grandinių jis vis dar yra. Pašto ir katalogų tarnyboms pridėkite -starttls smtp (arba imap, ldap) ir tinkamą prievadą. Įtraukite vidinius serverius, apkrovos balansavimo įrenginius ir pradinius serverius už CDN.

2. Kas buvo išduota jūsų domenams? CT žurnaluose matyti kiekvienas sertifikatas, kurį viešoji sertifikavimo įstaiga išdavė jūsų domenų vardams, įskaitant tuos, kurių užsakymo niekas įmonėje neprisimena:

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

Išvestis taip pat parodo, kokiomis sertifikavimo įstaigomis jūsų įmonė iš tikrųjų naudojasi, o tai yra toliau aprašytos inventorizacijos pradžia.

3. Ar jūsų klientai pasitiki kompromituotais raktais? Mozilla bandomieji serveriai pateikia kompromituotais raktais išduotus sertifikatus, todėl sertifikato klaida yra geras rezultatas. Išbandykite abi šeimas: pirmojo serverio grandinė veda iki eMudhra šakninio sertifikato, antrojo iki Sectigo, o patikimų sertifikatų saugykla gali vieną patikrą išlaikyti, o kitos neišlaikyti.

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 rezultatas galioja tik pačiam curl. Tą pačią užklausą paleiskite per kiekvienos programos TLS steką, toje aplinkoje, kurioje programa veikia:

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

Dvi Python eilutės nėra perteklinės: urllib naudoja operacinės sistemos saugyklą, requests naudoja certifi. Kiekvieną eilutę pakartokite su serveriu dv-g3b-aaa-emudhra. Java atveju iš atitinkamos JVM atlikite bet kokią HTTPS užklausą į bandomuosius serverius ir patikrinkite, ar jos saugykloje yra kuris nors iš šių šakninių sertifikatų (Java 9 ar naujesnė; su Java 8 naudokite -keystore $JAVA_HOME/jre/lib/security/cacerts):

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

Šakninis sertifikatas saugykloje savaime neįrodo, kad esate pažeidžiami, nes Go, Node.js, Deno ir Rust rustls-webpki dabar blokuoja šiuos aštuonis raktus nepriklausomai nuo saugyklos turinio. Klausimą išsprendžia bandomieji serveriai.

4. Windows kompiuterių parkai. Microsoft apie incidentą nieko nepaskelbė, tačiau draudžiamų sertifikatų sąrašas, kurį Windows atsisiunčia automatiškai, nuo spalio 20 d. blokuoja visus aštuonis raktus. Išimtys yra kompiuteriai, kuriuose grupės strategija išjungia automatinį šakninių sertifikatų atnaujinimą, ir tinklai, iš kurių nėra prieigos prie Windows Update; jiems sąrašą reikia pristatyti kitu būdu. certutil -verifyCTL Disallowed parodo kompiuterio podėlyje laikomą kopiją. Mozilla incidento puslapyje siūlomas scenarijus pavieniams kompiuteriams ir nurodoma, kad jis „nerekomenduojamas įmonės valdomiems įrenginiams“.

5. GoDaddy sertifikatai. Patikrinkite, kokį sertifikatą kiekvienas serveris iš tikrųjų pateikia:

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

Jei išdavėjas yra GoDaddy ar Starfield, palyginkite serijos numerį su sertifikatais savo GoDaddy paskyroje. Kur GoDaddy rodo „Install your new certificate“ (įdiekite naują sertifikatą), serveryje vis dar yra atšauktasis.

Viena taisyklė galioja visur: nepašalinkite klaidos išjungdami sertifikatų tikrinimą. Cloudflare žodžiais: „Svarbu šių klaidų nespręsti išjungiant tikrinimą.“ Klientas, kuris netikrina, pasitiki kiekvienu suklastotu sertifikatu, ne tik šiais.

Ką atnaujinti šią savaitę

Yra dviejų rūšių pataisos. Pašalinus abu šakninius sertifikatus, klientui, kuris naudoja tą saugyklą, uždaromi visi keliai, bet kartu nustoja veikti ir galiojantys sertifikatai, kurių grandinė veda iki jų. Aštuonių raktų blokavimas pagal jų viešojo rakto maišos reikšmę (hash), kaip tai daro Go, Node.js, Deno, Electron, rustls-webpki, Composer ir Windows, uždaro spragą ir nieko kito nesugadina. Kur jūsų platforma siūlo antrąjį būdą, rinkitės jį.

„Dar nėra“ reiškia, kad iki spalio 22 d. nieko nebuvo paskelbta. Prieš ką nors planuodami, patikrinkite dar kartą.

Komandas dažniausiai užklumpa keturi dalykai:

• Konteinerių atvaizduose lieka senas sąrašas. Atvaizdas, sukurtas iki spalio 20 ar 21 d., pasitiki šiais raktais, kol nebus iš naujo surinktas iš atnaujinto bazinio atvaizdo, o tos pačios žymos (tag) atsisiuntimas padeda tik tada, kai bazinis atvaizdas jau surinktas iš naujo. Surinkite iš naujo, vėl įdiekite ir paklauskite tiekėjų, kurių atvaizdus naudojate.
• Procesai laiko tai, ką įkėlė. Programa savo patikimų sertifikatų saugyklą nuskaito paleidžiama, todėl po atnaujinimo iš naujo paleiskite ilgai veikiančias paslaugas. Node.js priduria, kad TLS seansai, tęsiami iš prieš atnaujinimą užmegztų seansų, iš naujo netikrinami.
• Programos turi savo CA failus. SDK ir programos dažnai pateikiamos su savo cacert.pem ar ca-bundle.crt. Ieškokite jų repozitorijose ir atvaizduose, pavyzdžiui, komanda find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, ir tikėkitės rasti ne vieną: antai pip turi savo certifi kopiją.
• Įrenginiai laukia savo tiekėjo. Paprašykite kiekvieno tiekėjo raštu nurodyti, kokią patikimų sertifikatų saugyklą naudoja produktas ir kada bus išleistas atnaujinimas. Kol jis neišleistas, įrenginys pasitiki suklastotais sertifikatais visoms paslaugoms, į kurias kreipiasi, todėl apribokite, ką jis gali pasiekti.

Jei AAA Certificate Services šalinate rankiniu būdu, kaip tai daro Debian, Ubuntu ESM, Fedora ir Red Hat apėjimo būdas, po to išbandykite ryšius su paslaugomis, naudojančiomis Sectigo sertifikatus: kai kurie senesni serveriai vis dar siunčia grandinę, kuri baigiasi šiuo šakniniu sertifikatu.

Ką įdiegti prieš kitą kartą

Kad sertifikavimo įstaiga paliktų tokius silpnus raktus, nutinka retai. Masiniai atšaukimai nėra reti. Štai didieji 2026 m. atvejai, užregistruoti Mozilla klaidų sekimo sistemoje:

Nė vienas iš šių penkių atvejų nebuvo saugumo nesėkmė. Kiekvienu atveju sertifikatas nesutapo su pačios sertifikavimo įstaigos dokumentu, o Baseline Requirements (4.9.1.1 skirsnis) vis tiek reikalauja atšaukti per penkias dienas. Kai raktas kompromituotas arba domeno patvirtinimu negalima pasikliauti, terminas yra 24 valandos. Niekas negali jo jums pratęsti. 2024 m., kai DigiCert atšaukė 83 267 sertifikatus, Chrome Root Program rašė, kad ji „neturi įgaliojimų suteikti išimčių“; vienas klientas gavo teismo nutartį, stabdančią jo sertifikatų atšaukimą, o po keturių dienų ši nutartis buvo panaikinta.

Tai, kaip vyko pakeitimai, daug ką pasako. Liepą HARICA pasinaudojo ACME Renewal Information (ARI), kad jos klientų ACME klientai sertifikatus atnaujintų anksčiau, o kitus sertifikatus išdavė iš naujo pati; didesniame iš dviejų jos atšaukimų iki termino jau buvo pakeista 87 proc. paveiktų domenų vardų. GoDaddy, kurios klientai kiekvieną pakaitinį sertifikatą atsisiunčia ir įdiegia patys, iki termino buvo atšaukusi 42 proc. paveiktų sertifikatų.

Atnaujinimo ciklas bet kuriuo atveju trumpėja:

• Pagal CA/Browser Forum nutarimą SC-081 viešųjų TLS sertifikatų galiojimas nuo 2026 m. kovo 15 d. apribotas iki 200 dienų. Riba sumažės iki 100 dienų 2027 m. kovo 15 d. ir iki 47 dienų 2029 m. kovo 15 d., kai domeno patvirtinimą bus galima pakartotinai naudoti tik 10 dienų.
• Let's Encrypt 2027 m. vasario 10 d. pagal numatytuosius nustatymus pradės išduoti 64 dienų sertifikatus, o po metų 45 dienų.
• Viešieji TLS sertifikatai netenka kliento autentifikavimo. Let's Encrypt jo nebeišduoda nuo 2026 m. liepos 8 d., o Chrome Root Program reikalauja, kad nuo 2027 m. kovo 15 d. išduoti sertifikatai būtų skirti tik serverio autentifikavimui. Jei viešuosius sertifikatus naudojate kaip klientų sertifikatus abipusiam TLS (mutual TLS), kas įprasta B2B API integracijose, tiems ryšiams reikės privačios sertifikavimo įstaigos.

Kai galiojimas bus 100, o vėliau 47 dienos, rankinis sertifikatų diegimas nebebus realus pasirinkimas. Įmonė, automatizavusi procesus pagal tokį grafiką, kartu yra pasirengusi ir kitam masiniam atšaukimui. Ko tam reikia:

1. Žinokite, ką turite, abiem kryptimis. Vienas sąrašas su kiekvienu jūsų serverių pateikiamu sertifikatu: serverio vardas, išdavėjas, galiojimo pabaiga, atnaujinimo būdas ir atsakingas asmuo. Antras sąrašas su kiekviena patikimų sertifikatų saugykla, kuria remiasi jūsų programinė įranga: operacinės sistemos paketas, kiekvienos kalbos rinkinys, kiekvienas CA failas programos ar įrenginio viduje. Aukščiau aprašyta CT paieška pradeda pirmąjį sąrašą; programinės įrangos komponentų sąrašas (SBOM) arba priklausomybių inventorius pradeda antrąjį.
2. Automatizuokite išdavimą ir diegimą. ACME visur, kur jis gali veikti, su ARI (RFC 9773), kad sertifikavimo įstaiga galėtų nurodyti jūsų klientams atnaujinti sertifikatus anksčiau. Kur įrenginyje ACME paleisti negalima, naudokite tiekėjo automatizavimo priemones arba TLS ryšį nutraukite prieš jį, kitame įrenginyje, kuris tai gali.
3. Turėkite parengtą antrą sertifikavimo įstaigą. Veikianti, išbandyta ACME paskyra antroje sertifikavimo įstaigoje ir DNS CAA įrašai, leidžiantys abi. Kai vienai sertifikavimo įstaigai panaikinamas pasitikėjimas arba ji masiškai atšaukia sertifikatus, perėjimas tampa konfigūracijos pakeitimu.
4. Stebėkite CT žurnalus savo domenams. Gaukite įspėjimą apie kiekvieną naują sertifikatą jūsų domenų vardams. Apie netikėtą išdavimą sužinosite tą pačią dieną.
5. Patikimų sertifikatų saugyklas laikykite priklausomybėmis. Atnaujinkite jas įprastu pataisų diegimo procesu, o atvaizdus surinkite iš naujo pagal grafiką, ne tik tada, kai keičiasi kodas.
6. Parašykite veiksmų planą (runbook) pagal du laikrodžius. 24 valandos ir penkios dienos: kas sprendžia, kas turi prieigą prie kiekvienos sistemos, kurioms sistemoms reikia rankinių veiksmų, kaip susisiekti su kiekvienu tiekėju. Kartą per metus jį repetuokite, pakeisdami sertifikatą paslaugoje, kuri gali sau leisti klaidą. Viešosios sertifikavimo įstaigos nuo 2025 m. privalo turėti ir testuoti savo masinio atšaukimo planą; jų klientams reikia antrosios pusės.

Jei kuriate produktus, kuriuos naudoja kiti

Jei jūsų produkte yra patikimų sertifikatų saugykla (įrenginys, įdiegiama programa, SDK), jūsų klientai apsaugoti tik tada, kai juos pasiekia jūsų atnaujinimas. Išleiskite jį ir praneškite klientams, kurios versijos pataisytos. Mozilla patarimas patikimų sertifikatų saugyklų operatoriams: užblokuoti aštuonis tarpinius sertifikatus, jei jūsų programinė įranga tai leidžia, o jei ne, „apsvarstyti, ar tinkama panaikinti pasitikėjimą šakniniais sertifikatais, kurie pasirašė šiuos tarpinius sertifikatus“.

Kibernetinio atsparumo aktas čia taikomas dviem būdais. Jo pranešimų prievolė, galiojanti nuo 2026 m. rugsėjo 11 d., apima aktyviai išnaudojamus pažeidžiamumus, o šiuo atveju apie išnaudojimą nepranešta. Jo esminiai reikalavimai, taikomi nuo 2027 m. gruodžio 11 d., apima tai, kad pažeidžiamumus būtų galima pašalinti saugumo atnaujinimais; produktas, kurio patikimų sertifikatų sąrašo negalima atnaujinti, jų neatitiktų. Klientai, kuriems taikoma NIS2, klaus savo tiekėjų, kaip greitai jie tai sutvarkė, todėl naudinga turėti atsakymą raštu.

Kas dar neišspręsta

• Likęs eMudhra šakninis sertifikatas. Spalio 21 d. Chrome pateikė eMudhra dvylika klausimų ir sprendimo dėl emSign Root CA - G1 nepaskelbė. Mozilla jo „šiuo metu“ nešalina.
• eMudhra perėjimo kelias. Ji pranešė Mozilla, kad klientus perkels į savo G1 (RSA) hierarchiją; jos būsenos puslapyje kalbama apie „alternatyvią, nepriklausomai valdomą, viešai patikimą CA hierarchiją“. Chrome paklausė, kurią.
• Microsoft ir Apple. Nė viena iš jų nepaskelbė pareiškimo ir nepašalino nė vieno iš šių šakninių sertifikatų iš savo saugyklos.
• Laukiamos pataisos. Red Hat, Amazon Linux, Temurin ir Corretto iki spalio 22 d. nieko nebuvo išleidę; Bun pataisa sujungta, bet neišleista.
• Pagrindinė priežastis. eMudhra jos nepatvirtino ir pareiškė, kad iš naujo patikrins kiekvieną savo atliktą raktų generavimo ceremoniją.
• Sectigo. Atskiru atveju, nagrinėjamu nuo rugsėjo 5 d., Sectigo atsisakė atšaukti sertifikatus, kurių išplėstinė rakto paskirtis (extended key usage) neatitiko vieno jos CPS sakinio, teigdama, kad tas sakinys buvo dviprasmiškas. Spalio 18 d. ji suskaičiavo apie 72 milijonus tokių vis dar galiojančių sertifikatų. Kai kurie viešos diskusijos dalyviai ragino panaikinti pasitikėjimą; nė viena šakninių sertifikatų programa sprendimo nepaskelbė. Įmonėms, turinčioms Sectigo sertifikatų, vertėtų sekti šį atvejį.

Kur gauti pagalbos

Sertifikatų problema retai atrodo kaip sertifikatų problema. Ji pasireiškia kaip nebeįsikeliantis atsiskaitymo puslapis, nebesisinchronizuojanti integracija ar duomenų nebesiunčiantis įrenginys, dažniausiai savaitgalį. Padedame įmonėms tokias savaites kaip ši praeiti be sutrikimų ir viską sutvarkome taip, kad kitas kartas būtų įprastas darbas:

• Poveikio patikra. Surandame, kur jūsų sistemos užmezga ar priima TLS ryšius, kokią patikimų sertifikatų saugyklą naudoja kiekviena iš jų ir kokius sertifikatus pateikiate, įskaitant konteinerius, Java paslaugas, integracijas su bankais, mokėjimų ir logistikos paslaugų teikėjais bei įrenginius.
• Pataisos. Atnaujinimai, iš naujo surinkti atvaizdai, užblokuoti raktai ar pakeisti sertifikatai, atliekami per jūsų pakeitimų valdymo procesą ir patikrinami su Mozilla bandomaisiais serveriais.
• Automatizavimas 2027 metams. ACME su ARI serveriuose, apkrovos balansavimo ir specializuotuose įrenginiuose, antra sertifikavimo įstaiga, CAA įrašai, CT stebėsena ir veiksmų planas, paruošti 100 dienų sertifikatams nuo 2027 m. kovo 15 d.
• Sistemos, kurių niekas nenori liesti. Senos Java programos, specializuoti įrenginiai ir įterptiniai klientai su savo patikimų sertifikatų saugyklomis: būtent tam skirta mūsų senųjų sistemų ir kodo priežiūros paslauga.

Jei nesate tikri, ar jus tai paveikė, parašykite adresu office@c9group.dev, nurodydami savo domenus ir naudojamas platformas, arba užsisakykite pokalbį. Pasakysime, ką patikrinti pirmiausia.