eMudhra CA-võtmete kompromiteerimine: mida ettevõtted peaksid nüüd kontrollima ja parandama

Laupäeval, 17. oktoobril 2026 teatas üks turvauurija, et India sertifitseerimiskeskuse (CA) eMudhra hallatava kaheksa vahesertifikaadi (intermediate CA) privaatvõtmeid sai igaüks avalikest sertifikaatidest tuletada. Iga võti oli arv, mis on väiksem kui 256. Üks neist oli arv 4. Kuus neist kaheksast võisid välja anda TLS-sertifikaate, mida usaldavad Apple, Google, Microsoft ja Mozilla; ülejäänud kaks võisid allkirjastada Windowsi tarkvara.

Chrome blokeeris kuus TLS-võtit tund ja nelikümmend minutit pärast teadet, Firefox sama päeva õhtul. Veebi sirvivate inimeste jaoks oli oht laupäeva hilisõhtuks möödas.

Kõige muu jaoks see möödas ei olnud. Serverid, konteinerid, Java-rakendused, Pythoni skriptid, makseliidestused ja ühendatud seadmed kontrollivad sertifikaate usaldatud sertifitseerimiskeskuste loendi põhjal, millest neil on oma koopia, ja enamik neist koopiatest muutub alles siis, kui keegi uuenduse paigaldab. Seni läheb ükskõik millise domeeni sertifikaat, mis on allkirjastatud mõne neist võtmetest, ehtsana läbi ja võtmed on olnud avalikud alates 20. oktoobrist.

Samal nädalal hakkas GoDaddy tühistama 404 607 sertifikaati, sest nendes olevad sertifikaadipoliitika andmed ei vastanud tema enda avaldatud dokumentidele. Kliendid pidid asendussertifikaadid ise alla laadima ja paigaldama.

See juhend on neile, kes peavad vastama küsimusele „kas see puudutab meid?“: IT- ja käitusjuhtidele, tehnoloogiajuhtidele (CTO) ja asutajatele, kelle äri toetub veebisaidile, API-le või ühendatud tootele. See kirjeldab, mis juhtus (Mozilla, Google'i, eMudhra, GoDaddy ja tarkvaratarnijate avaldatud intsidendikirjete põhjal), mida täna kontrollida, mida sel nädalal uuendada ja mida paika panna, et järgmine sama laadi intsident oleks rutiinne töö. Kõik siin kirjeldatu on 22. oktoobri 2026 seisuga ja intsident on endiselt avatud.

Mis juhtus

eMudhra lõi need kaheksa vahesertifikaati võtmetseremoonial 30. aprillil 2025. Ettevõtte enda selgitus, mille ta 19. oktoobril Mozilla intsidendi veakirjesse postitas: võtme krüpteeritud kujul pakkimise ja lahtipakkimise sammu (key wrap ja unwrap) testis, mis oli heaks kiidetud kõrvalekaldena tavapärasest protseduurist, oli viga, mille tõttu tekkis riistvaralisse turvamoodulisse (HSM) kavandatud võtmete kõrvale teine, nõrkade võtmete komplekt. Sildid olid sarnased, sertifikaaditaotlused loodi ekslikult nõrkade võtmetega ja eMudhra juursertifikaat allkirjastas need. Samad taotlused läksid Sectigole, kes ristallkirjastas 14. mail 2025 kõik kaheksa oma juursertifikaadiga AAA Certificate Services. eMudhra ütleb, et ta ei ole „veel kinnitanud täpset algpõhjust“.

Mozilla kirjeldas tulemust nii: „P384 privaatvõtmed on juhuslikult valitud täisarvud vahemikus 1 kuni rühma järk. Kõik 8 mõjutatud võtit kasutasid täisarve, mis on väiksemad kui 256.“ Mozilla sai teate kell 20:06 UTC ja arvutas võtmed kell 21:48 ise välja, „teadmata midagi meetodist, mida algne teataja kasutas“. Uurija sõnul leidis ta need Google'i avatud lähtekoodiga teegiga paranoid_crypto, „kohe karbist võttes“. Nõrgad võtmed olid olnud avalikult usaldatud sertifikaadiahelate osa ligi 18 kuud.

Kaheksa sertifikaati:

Iga võti sisaldub kahes sertifikaadis. Ühe andis välja eMudhra emSign Root TLS CA - G3 või emSign Root CS CA - G3, mille ahel viib edasi juursertifikaadini emSign ECC Root CA - G3; teine on Sectigo ristsertifikaat juursertifikaadilt AAA Certificate Services. Teine tee on oluline, sest mõni usaldushoidla (trust store), kus eMudhra juursertifikaati kunagi ei olnud, usaldab seda vana Sectigo juursertifikaati endiselt.

Kas kedagi rünnati?

Keegi ei ole kuritarvitamisest teatanud ja brauserite puhul on hea põhjus arvata, et seda ei olnudki. Chrome, nagu teisedki kliendid, mis jõustavad Certificate Transparency (CT, sertifikaatide avalik logimine) nõudeid, aktsepteerib sertifikaati ainult siis, kui see on kantud avalikesse CT logidesse. Google: enne tema blokeeringut ei olnud logidesse kantud ühtegi TLS-sertifikaati, mille ahel viib nende kuue vahesertifikaadini, seega „ei saanud ühtegi nende CA-de välja antud võltssertifikaati kasutada CT-d jõustavate klientide vastu“.

Väljaspool brauserit on pilt teine. Mozilla intsidendileht: „paljud kliendid väljaspool brauserite ökosüsteemi ei jõusta Certificate Transparency nõudeid. Me ei tea, kas ründajad kasutasid vigast võtmete genereerimist nende klientide sihtimiseks.“ See ajaaken avanes 2025. aasta kevadel ja sulgub iga kliendi jaoks alles siis, kui seda uuendatakse. eMudhra ütleb, et tal ei ole teada ühtegi tõendit selle kohta, et võtmed oleks enne avalikustamist välja arvutatud, ja Cloudflare ütleb, et tema ülevaatus ei leidnud tema teenustes aktiivset ärakasutamist.

Nüüd, kui võtmed on avalikud, ei nõua sertifikaadi võltsimine mingit oskust. Mozilla intsidendileht loetleb testservereid, mis esitavad kompromiteeritud võtmetega välja antud sertifikaate, et igaüks saaks oma kliente nende vastu kontrollida (käsud on allpool).

Mida võltsitud sertifikaat võimaldab: keegi, kes suudab teie tarkvara ja selle poolt kasutatava teenuse vahelise liikluse kinni püüda (jagatud võrgus, kompromiteeritud ruuteri või mürgitatud DNS-vastuse kaudu), saab esineda selle teenusena, lugeda, mida teie tarkvara saadab, kaasa arvatud API-võtmed ja isikuandmed, ning muuta seda, mida see vastu võtab. Tarkvara, mis oli allkirjastatud ühega kahest koodi allkirjastamise võtmest, oleks läbinud Windowsi allkirjakontrolli seni, kuni Microsofti blokeering masinani jõudis.

Keda see puudutab

Probleeme on kolm ja need on üksteisest eraldi, kuid ühel ettevõttel võivad olla kõik kolm.

1. Tarkvara, mis usaldab endiselt kompromiteeritud võtmeid

See probleem on peaaegu igal ettevõttel: iga programm, mis teeb HTTPS-päringuid, mille usaldushoidlas on endiselt emSign ECC Root CA - G3 või AAA Certificate Services ja mis ei ole saanud kaheksa võtme blokeeringut. Tüüpilised kohad:

• Linuxi serverid ja konteinerikujutised, mis on ehitatud enne 20. või 21. oktoobrit. Näiteks paikamata Debian 12 usaldab mõlemat ahelat.
• Programmeerimiskeelte käituskeskkonnad, millel on kaasas oma loend: Node.js, Pythoni certifi, Java cacerts, PHP Composeri sertifikaadikomplekt, Rusti webpki-roots.
• macOS-i käsurea tööriistad. Mozilla intsidendilehe sõnul kontrollivad sisseehitatud curl, git, python3, perl, ruby ja openssl sertifikaate faili /etc/ssl/cert.pem järgi tühistamist kontrollimata ning Apple ei ole seda faili uuendanud.
• Windowsi masinad, mis ei saa Microsofti automaatseid uuendusi keelatud sertifikaatide loendile (disallowed certificate list), tavaliselt seetõttu, et rühmapoliitika (Group Policy) on need välja lülitanud või võrk on internetist eraldatud.
• Riistvaralahendused, seadmed ja kolmandate osapoolte tarkvara, millel on kaasas oma CA-fail, näiteks koormusejaoturid, VPN-lüüsid, SDK-d ja sardkontrollerid.

Iga käituskeskkonda tuleb kontrollida eraldi. Meie 22. oktoobril tehtud testis aktsepteeris paikamata Debian 12 masin, millel oli Node.js 24.18, ahelat, mis lõpeb eMudhra juursertifikaadiga, ja lükkas tagasi ahela, mis lõpeb Sectigo juursertifikaadiga, samal ajal kui Python samas masinas aktsepteeris mõlemat.

2. Ettevõtted, kelle enda sertifikaatide ahel viib eemaldatud juursertifikaadini

Mozilla ja Linuxi distributsioonid on juursertifikaadi emSign ECC Root CA - G3 eemaldanud ja Chrome teeb sama 27. oktoobril. Selle juursertifikaadi all olevad kehtivad sertifikaadid lakkavad töötamast igas kliendis, niipea kui seda uuendatakse. Google'i juhis: selliste sertifikaatidega veebisaitide haldajad „peavad viivitamata hankima ja paigaldama uue TLS-sertifikaadi mõnest teisest PKI hierarhiast, mis on Chrome Root Store'is“.

Chrome loendas 21. oktoobril CT logides selle juursertifikaadi all umbes 30 800 aegumata sertifikaati. Neist 30 791 pärines kahest vahesertifikaadist, mis kuuluvad InCommonile, sertifikaaditeenusele, mida Internet2 käitab USA ülikoolide ja teadusasutuste jaoks ning mis annab ECC-sertifikaate välja eMudhra platvormi CERTInext kaudu. eMudhra enda vahesertifikaatidest pärines 18 sertifikaati. eMudhra ütleb, et üle viia tuleb umbes 30 000 sertifikaati, millest umbes 97% on välja antud ACME kaudu, ja et ta annab asendussertifikaate välja teisest hierarhiast.

Kui teie sait on Cloudflare'i taga režiimis Full (strict) ja lähteserver (origin) esitab selle juursertifikaadi all oleva sertifikaadi, ütleb Cloudflare, et usalduse äravõtmine „põhjustaks tõrkeid“, ja palub klientidel „üle vaadata oma kohandatud lähteserveri sertifikaadid ja serverikonfiguratsioonid“.

eMudhra teise juursertifikaadi emSign Root CA - G1 RSA-sertifikaate see seni ei puuduta. Mozilla ütleb, et ta seda juursertifikaati „praegu“ ei eemalda; Chrome „uurib põhjalikult eMudhra ülejäänud CA-sertifikaatide edasist kaasamist“. Kui sõltute mis tahes liiki eMudhra või CERTInexti sertifikaatidest, seadke kohe valmis teine sertifitseerimiskeskus.

3. GoDaddy kliendid

GoDaddy juhtumil ei ole eMudhraga mingit pistmist, kuid see tabas samal nädalal ja palju rohkem saite. 15. oktoobril teatas GoDaddy Mozillale, et tema GoDaddy ja Starfieldi hierarhia sertifikaatides olid sertifikaadipoliitika andmed (poliitika OID-id ja CPS-i lingid), mis ei vastanud profiilidele tema enda CP/CPS-is, dokumendis, milles sertifitseerimiskeskus kirjeldab, mida ta välja annab. See ei ole sertifikaatide turvaviga. Baseline Requirementsi järgi (need on reeglid, mida iga avalik sertifitseerimiskeskus järgib) on see siiski põhjus sertifikaadid viie päeva jooksul tühistada.

Mõjutatud oli 404 607 sertifikaati, neist 396 055 domeeni valideerimisega (DV). GoDaddy tühistas 170 566 tähtajaks, milleks oli 18. oktoober kell 23:45 UTC, ja järgmiseks hommikuks 227 422; tema klienditeade ütleb, et ülejäänud tühistati 21. oktoobril. GoDaddy annab sertifikaadid uuesti välja, kuid nende paigaldamine on kliendi ülesanne: „teie veebisaidi külastajad võivad näha turvahoiatusi ja teie sait võib muutuda kättesaamatuks, kuni uus sertifikaat on paigaldatud.“

Mida täna kontrollida

1. Mida teie enda serverid saadavad? Loetlege iga avaliku hostinime kohta väljaandjad ahelas, mille see esitab:

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

Kui mõnel real on nimetatud eMudhra, emSign, mõni EM ... G3B või G3C sertifitseerimiskeskus või InCommon Intermediate CA - DVG3C, OVG3C või EVG3C, tuleb sertifikaat enne 27. oktoobrit välja vahetada. AAA Certificate Services üksi on normaalne, sest paljud tavalised Sectigo ahelad sisaldavad seda endiselt. E-posti- ja kataloogiteenuste puhul lisage -starttls smtp (või imap, ldap) ja õige port. Kaasake ka sisevõrgu hostid, koormusejaoturid ja CDN-i taga olevad lähteserverid.

2. Mida on teie domeenidele välja antud? CT logides on kirjas iga sertifikaat, mille mõni avalik sertifitseerimiskeskus on teie nimedele välja andnud, ka need, mille tellimist keegi ettevõttes ei mäleta:

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

Väljund näitab ka, milliseid sertifitseerimiskeskusi teie ettevõte tegelikult kasutab, ja sellest algab allpool kirjeldatud inventuur.

3. Kas teie kliendid usaldavad kompromiteeritud võtmeid? Mozilla testserverid esitavad kompromiteeritud võtmetega välja antud sertifikaate, nii et sertifikaadiviga on hea tulemus. Testige mõlemat perekonda: esimese hosti ahel viib eMudhra juursertifikaadini, teise hosti ahel Sectigo juursertifikaadini, ja usaldushoidla võib ühe testi läbida ja teise mitte.

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 vastab ainult curli eest. Tehke sama päring iga rakenduse enda TLS-teegi kaudu, keskkonnas, kus rakendus töötab:

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

Kaks Pythoni rida ei korda teineteist: urllib kasutab operatsioonisüsteemi usaldushoidlat, requests kasutab paketti certifi. Korrake iga rida hostiga dv-g3b-aaa-emudhra. Java puhul tehke asjaomasest JVM-ist testserveritele ükskõik milline HTTPS-päring ja kontrollige, kas selle usaldushoidlas leidub üks neist kahest juursertifikaadist (Java 9 või uuem; Java 8 puhul kasutage -keystore $JAVA_HOME/jre/lib/security/cacerts):

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

Juursertifikaat usaldushoidlas ei tõenda üksi, et süsteem on ohus, sest Go, Node.js, Deno ja Rusti rustls-webpki blokeerivad nüüd kaheksa võtit sõltumata sellest, mis usaldushoidlas on. Selguse toovad testserverid.

4. Windowsi arvutipargid. Microsoft ei ole intsidendi kohta midagi avaldanud, kuid keelatud sertifikaatide loend, mille Windows automaatselt alla laadib, on alates 20. oktoobrist blokeerinud kõik kaheksa võtit. Erandid on masinad, kus rühmapoliitika on juursertifikaatide automaatsed uuendused välja lülitanud, ja võrgud, kust ei pääse Windows Update'i juurde; neisse tuleb loend toimetada muul viisil. certutil -verifyCTL Disallowed näitab koopiat, mille masin on vahemällu salvestanud. Mozilla intsidendileht pakub skripti üksikute masinate jaoks ja ütleb, et seda „ei soovitata ettevõtte hallatavate seadmete puhul“.

5. GoDaddy sertifikaadid. Kontrollige, millise sertifikaadi iga server tegelikult esitab:

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

Kui väljaandja on GoDaddy või Starfield, võrrelge seerianumbrit oma GoDaddy konto sertifikaatidega. Kui GoDaddy näitab teksti „Install your new certificate“ (paigaldage oma uus sertifikaat), on serveris endiselt tühistatud sertifikaat.

Üks reegel kehtib kogu aeg: ärge kõrvaldage viga sertifikaadi kontrollimise väljalülitamisega. Cloudflare'i sõnadega: „On oluline mitte lahendada neid vigu kontrollimise väljalülitamisega.“ Klient, mis sertifikaate ei kontrolli, usaldab iga võltsitud sertifikaati, mitte ainult neid.

Mida sel nädalal uuendada

Parandusi on kahte liiki. Kahe juursertifikaadi eemaldamine sulgeb kõik teed kliendi jaoks, mis seda usaldushoidlat kasutab, kuid muudab kasutuskõlbmatuks ka nende all olevad kehtivad sertifikaadid. Kaheksa võtme blokeerimine nende avaliku võtme räsi järgi, nagu teevad Go, Node.js, Deno, Electron, rustls-webpki, Composer ja Windows, sulgeb augu ega riku midagi muud. Kui teie platvorm pakub teist võimalust, eelistage seda.

„Veel ei ole“ tähendab, et 22. oktoobriks ei olnud midagi avaldatud. Kontrollige uuesti, enne kui sellele oma plaane rajate.

Neli kohta, kus meeskonnad komistavad:

• Konteinerikujutised säilitavad vana loendi. Enne 20. või 21. oktoobrit ehitatud kujutis usaldab võtmeid seni, kuni see ehitatakse uuesti uuendatud baaskujutise peale, ja sama sildi (tag) uuesti tõmbamine aitab alles siis, kui baaskujutis on uuesti ehitatud. Ehitage uuesti, juurutage uuesti ja küsige tarnijatelt, kelle kujutisi te kasutate.
• Protsessid jätavad alles selle, mille nad laadisid. Programm loeb oma usaldushoidla käivitumisel, seega taaskäivitage pärast uuendamist kaua töötavad teenused. Node.js lisab, et enne uuendust alanud ja hiljem jätkatud TLS-seansse uuesti ei kontrollita.
• Rakendustel on kaasas oma CA-failid. SDK-de ja rakendustega tuleb sageli kaasa nende oma cacert.pem või ca-bundle.crt. Otsige neid koodihoidlatest ja kujutistest, näiteks käsuga find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, ja arvestage, et neid on rohkem kui üks: näiteks pip sisaldab oma koopiat paketist certifi.
• Seadmed ootavad oma tarnijat. Küsige igalt tarnijalt kirjalikult, millist usaldushoidlat toode kasutab ja millal uuendus tuleb. Kuni seda ei ole, usaldab seade võltsitud sertifikaate iga teenuse puhul, mille poole see pöördub, seega piirake, millele see ligi pääseb.

Kui eemaldate AAA Certificate Services käsitsi, nagu teevad Debian, Ubuntu ESM, Fedora ja Red Hati ajutine lahendus, testige pärast seda ühendusi teenustega, millel on Sectigo sertifikaadid: mõni vanem server saadab endiselt ahela, mis lõpeb selle juursertifikaadiga.

Mida enne järgmist korda paika panna

Harva juhtub, et sertifitseerimiskeskus jätab võtmed nii nõrgaks. Massilised tühistamised ei ole harvad. Need on 2026. aasta suured juhtumid, mis on kirjas Mozilla veahaldussüsteemis:

Ükski neist viiest ei olnud turvarike. Igal juhul oli sertifikaat vastuolus sertifitseerimiskeskuse enda dokumendiga ja Baseline Requirements (jaotis 4.9.1.1) nõuab ikkagi tühistamist viie päeva jooksul. Kui võti on kompromiteeritud või domeeni valideerimisele ei saa tugineda, on tähtaeg 24 tundi. Keegi ei saa seda teie jaoks pikendada. DigiCerti 2024. aasta tühistamise puhul, mis puudutas 83 267 sertifikaati, kirjutas Chrome Root Program, et tal „ei ole volitusi erandeid teha“; üks klient sai kohtumääruse, mis peatas tema sertifikaatide tühistamise, ja määrus tunnistati neli päeva hiljem kehtetuks.

See, kuidas asendamine läks, ütleb palju. Juulis kasutas HARICA mehhanismi ACME Renewal Information (ARI), et anda oma klientide ACME-klientidele märku sertifikaate varem uuendada, ja andis muud sertifikaadid ise uuesti välja; kahest tühistamisest suuremas oli tähtaja saabudes 87% mõjutatud nimedest asendatud. GoDaddy, kelle kliendid laadivad iga asendussertifikaadi ise alla ja paigaldavad selle, oli oma tähtajaks tühistanud 42% mõjutatud sertifikaatidest.

Uuendustsükkel lüheneb niikuinii:

• CA/Browser Forumi hääletuse (ballot) SC-081 järgi on avalike TLS-sertifikaatide kehtivus alates 15. märtsist 2026 piiratud 200 päevaga. 15. märtsil 2027 langeb piir 100 päevale ja 15. märtsil 2029 juba 47 päevale; siis saab domeeni valideerimist uuesti kasutada ainult 10 päeva.
• Let's Encrypt läheb 10. veebruaril 2027 vaikimisi üle 64-päevastele sertifikaatidele ja aasta hiljem 45-päevastele.
• Avalikud TLS-sertifikaadid kaotavad kliendi autentimise. Let's Encrypt lõpetas selle väljaandmise 8. juulil 2026 ja Chrome Root Program nõuab, et alates 15. märtsist 2027 välja antud sertifikaadid oleksid ainult serveri autentimiseks. Kui kasutate avalikke sertifikaate kliendisertifikaatidena vastastikuse TLS-autentimise (mutual TLS) jaoks, mis on B2B API-liidestustes tavaline, vajavad need ühendused privaatset sertifitseerimiskeskust.

Kui kehtivus on 100 ja hiljem 47 päeva, ei ole sertifikaatide käsitsi paigaldamine enam realistlik. Ettevõte, kes automatiseerib selle ajakava jaoks, on valmis ka järgmiseks massiliseks tühistamiseks. Mida see nõuab:

1. Teadke, mis teil on, mõlemas suunas. Üks loend kõigist sertifikaatidest, mida te esitate, koos hostinime, väljaandja, aegumise, uuendamisviisi ja vastutajaga. Teine loend kõigist usaldushoidlatest, millele teie tarkvara tugineb: operatsioonisüsteemi pakett, iga programmeerimiskeele sertifikaadikomplekt, iga CA-fail rakenduse või seadme sees. Ülaltoodud CT otsing annab esimesele loendile alguse; tarkvara koostisosade loetelu (SBOM) või sõltuvuste inventuur annab alguse teisele.
2. Automatiseerige väljaandmine ja paigaldamine. ACME kõikjal, kus see töötada saab, koos ARI-ga (RFC 9773), et sertifitseerimiskeskus saaks teie klientidele märku anda varem uuendada. Kus seade ACME-d käitada ei saa, kasutage tarnija automatiseerimist või lõpetage TLS-ühendus seadme ees millelgi, mis seda suudab.
3. Hoidke teine sertifitseerimiskeskus valmis. Toimiv ja testitud ACME-konto teise sertifitseerimiskeskuse juures ning DNS-is CAA-kirjed, mis lubavad mõlemat. Kui ühelt sertifitseerimiskeskuselt usaldus ära võetakse või see tühistab sertifikaate hulgi, on ümberlülitamine vaid konfiguratsioonimuudatus.
4. Jälgige CT logides oma domeene. Seadistage hoiatus iga uue sertifikaadi kohta, mis teie nimedele välja antakse. Nii saate ootamatust väljaandmisest teada samal päeval.
5. Käsitlege usaldushoidlaid sõltuvustena. Uuendage neid tavapärase paikamise käigus ja ehitage kujutisi uuesti graafiku alusel, mitte ainult siis, kui kood muutub.
6. Kirjutage tegevusjuhend (runbook) kahe tähtaja järgi. 24 tundi ja viis päeva: kes otsustab, kellel on juurdepääs igale süsteemile, millised süsteemid vajavad käsitsi samme, kuidas iga tarnijaga ühendust saada. Harjutage seda kord aastas, vahetades sertifikaati teenuses, mis talub viga. Avalikud sertifitseerimiskeskused on alates 2025. aastast pidanud hoidma ja testima oma massilise tühistamise plaani; nende klientidel on vaja teist poolt.

Kui teete tooteid, mida käitavad teised

Kui teie tootes on usaldushoidla (seade, paigaldatav rakendus, SDK), on teie kliendid kaitstud alles siis, kui teie uuendus nendeni jõuab. Andke see välja ja öelge klientidele, millised versioonid on parandatud. Mozilla nõuanne usaldushoidlate haldajatele: blokeerige need kaheksa vahesertifikaati, kui teie tarkvara seda võimaldab, vastasel juhul „kaaluge, kas nende vahesertifikaatide allkirjastanud juursertifikaatide usaldamise lõpetamine on sobiv“.

Küberkerksuse määrus puudutab seda juhtumit kahel viisil. Selle teatamiskohustus, mis kehtib alates 11. septembrist 2026, hõlmab aktiivselt ärakasutatud haavatavusi ja selle juhtumi puhul ei ole ärakasutamisest teatatud. Selle olulised nõuded, mida kohaldatakse alates 11. detsembrist 2027, hõlmavad nõuet, et haavatavusi saaks kõrvaldada turvauuendustega; toode, mille usaldushoidlat ei saa uuendada, neile ei vastaks. NIS2 kohaldamisalasse kuuluvad kliendid küsivad oma tarnijatelt, kui kiiresti nad sellega toime tulid, ja vastus tasub kirja panna.

Mis on veel lahendamata

• eMudhra ülejäänud juursertifikaat. Chrome esitas 21. oktoobril eMudhrale kaksteist küsimust ega ole juursertifikaadi emSign Root CA - G1 kohta otsust teatanud. Mozilla ei eemalda seda „praegu“.
• eMudhra üleminekutee. Ettevõte ütles Mozillale, et viib kliendid üle oma G1 (RSA) hierarhiale; tema olekuleht räägib „alternatiivsest, sõltumatult käitatavast, avalikult usaldatud CA hierarhiast“. Chrome on küsinud, millisest.
• Microsoft ja Apple. Kumbki ei ole teinud avaldust ega eemaldanud kumbagi juursertifikaati oma usaldushoidlast.
• Ootel parandused. Red Hat, Amazon Linux, Temurin ja Corretto ei olnud 22. oktoobriks midagi välja andnud; Buni parandus oli liidetud, kuid välja andmata.
• Algpõhjus. eMudhra ei ole seda kinnitanud ja on öelnud, et kontrollib uuesti üle kõik oma seni läbi viidud võtmetseremooniad.
• Sectigo. Eraldi juhtumis, mis on avatud alates 5. septembrist, on Sectigo keeldunud tühistamast sertifikaate, mille laiendatud võtmekasutus (extended key usage) ei vastanud ühele lausele tema CPS-is, väites, et lause oli mitmetähenduslik. 18. oktoobril loendas ta neid endiselt kehtivana umbes 72 miljonit. Mõned avaliku arutelu osalised on nõudnud usalduse äravõtmist; ükski juursertifikaatide programm (root program) ei ole otsust teatanud. Sectigo sertifikaatidega ettevõtted peaksid juhtumit jälgima.

Kust abi saada

Sertifikaadiprobleem annab end harva teada sertifikaadiprobleemina. See avaldub e-poe kassana, mis enam ei laadi, liidestusena, mis lakkab andmeid sünkroonimast, või seadmena, mis lõpetab andmete saatmise, tavaliselt nädalavahetusel. Aitame ettevõtetel selliseid nädalaid nagu see katkestuseta üle elada ja seame asjad nii, et järgmine kord oleks rutiin:

• Avatuse kontroll. Leiame, kus teie süsteemid TLS-ühendusi loovad või vastu võtavad, millist usaldushoidlat igaüks neist kasutab ja milliseid sertifikaate te esitate, sealhulgas konteinerites, Java-teenustes, pankade, makse- ja logistikateenuse pakkujatega liidestustes ning seadmetes.
• Parandused. Uuendused, uuesti ehitatud kujutised, blokeeritud võtmed või vahetatud sertifikaadid, tehtud teie muudatusprotsessi kaudu ja kontrollitud Mozilla testserverite vastu.
• Automatiseerimine 2027. aastaks. ACME koos ARI-ga serverites, koormusejaoturites ja riistvaralahendustes, teine sertifitseerimiskeskus, CAA-kirjed, CT seire ja tegevusjuhend, valmis 100-päevasteks sertifikaatideks alates 15. märtsist 2027.
• Süsteemid, mida keegi puutuda ei taha. Vanad Java-rakendused, riistvaralahendused ja sardkliendid, millel on oma usaldushoidlad: just nende jaoks on meie pärandsüsteemide hooldusteenus.

Kui te pole kindel, kas see teid puudutab, kirjutage aadressil office@c9group.dev, milliseid domeene ja platvorme te kasutate, või broneerige kõne. Ütleme teile, mida esmalt kontrollida.