eMudhra CA atslēgu kompromitēšana: kas uzņēmumiem jāpārbauda un jānovērš tagad

Sestdien, 2026. gada 17. oktobrī, kāds drošības pētnieks ziņoja, ka astoņām starpposma sertifikācijas iestādēm (intermediate CA), kuras pārvalda Indijas sertifikācijas iestāde eMudhra, bija privātās atslēgas, ko ikviens varēja aprēķināt no publiskajiem sertifikātiem. Katra no šīm atslēgām bija skaitlis, kas mazāks par 256. Viena no tām bija skaitlis 4. Sešas no astoņām varēja izdot TLS sertifikātus, kuriem uzticas Apple, Google, Microsoft un Mozilla; pārējās divas varēja parakstīt Windows programmatūru.

Chrome bloķēja sešas TLS atslēgas stundu un četrdesmit minūtes pēc ziņojuma, Firefox tajā pašā vakarā. Tiem, kas pārlūko tīmekli, briesmas sestdienas naktī bija garām.

Visam pārējam tās nebija garām. Serveri, konteineri, Java lietotnes, Python skripti, maksājumu integrācijas un pieslēgtās ierīces pārbauda sertifikātus pret savu uzticamo iestāžu saraksta kopiju, un lielākā daļa šo kopiju mainās tikai tad, kad kāds uzstāda atjauninājumu. Līdz tam jebkura domēna sertifikāts, kas parakstīts ar kādu no šīm atslēgām, tiek pieņemts kā īsts, un atslēgas ir publiskas kopš 20. oktobra.

Tajā pašā nedēļā GoDaddy sāka atsaukt 404 607 sertifikātus, jo tajos ietvertā politikas informācija neatbilda paša uzņēmuma publicētajiem dokumentiem. Klientiem aizstājējsertifikāti bija jālejupielādē un jāuzstāda pašiem.

Šis ceļvedis ir tiem, kam jāatbild uz jautājumu „vai tas skar mūs?“: IT un ekspluatācijas vadītājiem, tehnoloģiju direktoriem (CTO) un dibinātājiem, kuru uzņēmējdarbība balstās uz tīmekļa vietni, API vai pieslēgtu produktu. Tajā aprakstīts, kas notika (pēc Mozilla, Google, eMudhra, GoDaddy un programmatūras piegādātāju publicētajiem incidentu ierakstiem), kas jāpārbauda šodien, kas jāatjaunina šonedēļ un kas jāievieš, lai nākamais šāda veida incidents būtu ikdienišķs darbs. Viss šeit rakstītais atbilst stāvoklim 2026. gada 22. oktobrī, un incidents joprojām nav noslēgts.

Kas notika

eMudhra šos astoņus starpsertifikātus izveidoja atslēgu ceremonijā 2025. gada 30. aprīlī. Uzņēmuma skaidrojums, ko tas 19. oktobrī publicēja Mozilla incidenta kļūdas ierakstā: atslēgu iesaiņošanas un atsaiņošanas (key wrap un unwrap) soļa testā, kas bija apstiprināts kā atkāpe no ierastās procedūras, bija kļūda, kuras dēļ aparatūras drošības modulī (HSM) blakus paredzētajām atslēgām tika izveidots otrs, vājš atslēgu komplekts. Apzīmējumi bija līdzīgi, sertifikātu pieprasījumu izveidei kļūdas pēc tika izmantotas vājās atslēgas, un eMudhra saknes sertifikāts tos parakstīja. Tie paši pieprasījumi nonāca pie Sectigo, kas 2025. gada 14. maijā visus astoņus krusteniski parakstīja ar savu AAA Certificate Services saknes sertifikātu. eMudhra norāda, ka tas „vēl nav apstiprinājis precīzu pamatcēloni“.

Mozilla rezultātu aprakstīja tā: „P384 privātās atslēgas ir nejauši izvēlēti veseli skaitļi starp 1 un grupas kārtu. Visas 8 skartās atslēgas izmantoja veselus skaitļus, kas mazāki par 256.“ Mozilla ziņojumu saņēma plkst. 20:06 UTC un pati atguva atslēgas plkst. 21:48, „nezinot, kādu metodi izmantoja sākotnējais ziņotājs“. Pētnieks saka, ka atrada tās ar Google atvērtā pirmkoda bibliotēku paranoid_crypto „bez jebkādiem pielāgojumiem“. Vājās atslēgas bija publiski uzticamu ķēžu daļa gandrīz 18 mēnešus.

Astoņi sertifikāti:

Katra atslēga ir divos sertifikātos. Vienu izdeva eMudhra emSign Root TLS CA - G3 vai emSign Root CS CA - G3, kuru ķēde ved līdz emSign ECC Root CA - G3; otrs ir Sectigo krusteniskais sertifikāts no AAA Certificate Services. Otrais ceļš ir svarīgs, jo dažas uzticamo sertifikātu krātuves (trust store), kurās nekad nav bijis neviena eMudhra saknes sertifikāta, joprojām uzticas šim vecajam Sectigo saknes sertifikātam.

Vai kādam ir uzbrukts?

Neviens nav ziņojis par ļaunprātīgu izmantošanu, un attiecībā uz pārlūkprogrammām ir labs pamats domāt, ka tādas nebija. Chrome, tāpat kā citi klienti, kas pieprasa Certificate Transparency (CT, publiski žurnāli, kuros reģistrē izdotos sertifikātus), pieņem sertifikātu tikai tad, ja tas ir ierakstīts publiskajos CT žurnālos. Google: līdz bloķēšanai CT žurnālos nebija ierakstīts neviens TLS sertifikāts, kura ķēde ved līdz šiem sešiem starpsertifikātiem, tāpēc „neviens šo CA izdots viltots sertifikāts nevarēja tikt izmantots pret klientiem, kas pieprasa CT“.

Ārpus pārlūkprogrammām aina ir cita. Mozilla incidenta lapa: „daudzi klienti ārpus pārlūkprogrammu ekosistēmas nepieprasa Certificate Transparency. Mēs nezinām, vai uzbrucēji izmantoja kļūdaino atslēgu ģenerēšanu, lai uzbruktu šiem klientiem.“ Šis logs atvērās 2025. gada pavasarī un katram klientam aizveras tikai tad, kad tas tiek atjaunināts. eMudhra norāda, ka tam nav zināmi nekādi pierādījumi, ka atslēgas būtu atgūtas pirms atklāšanas, un Cloudflare saka, ka tā pārbaudē aktīva izmantošana tā pakalpojumos netika konstatēta.

Tagad, kad atslēgas ir publiskas, sertifikāta viltošanai nav vajadzīgas nekādas prasmes. Mozilla incidenta lapā uzskaitīti testa serveri, kas uzrāda ar kompromitētajām atslēgām izdotus sertifikātus, lai ikviens varētu ar tiem pārbaudīt savus klientus (komandas ir tālāk).

Ko ļauj viltots sertifikāts: tas, kurš var pārtvert datplūsmu starp jūsu programmatūru un pakalpojumu, ko tā izsauc (koplietojamā tīklā, caur kompromitētu maršrutētāju vai ar saindētu DNS atbildi), var uzdoties par šo pakalpojumu, lasīt to, ko jūsu programmatūra sūta, ieskaitot API atslēgas un personas datus, un mainīt to, ko tā saņem. Programmatūra, kas parakstīta ar vienu no abām koda parakstīšanas atslēgām, būtu izgājusi Windows paraksta pārbaudi, līdz Microsoft bloķēšana sasniegtu attiecīgo datoru.

Kurus tas skar

Ir trīs atsevišķas problēmas, un vienam uzņēmumam var būt visas trīs.

1. Programmatūra, kas joprojām uzticas kompromitētajām atslēgām

Šī problēma ir gandrīz katram uzņēmumam: jebkura programma, kas veic HTTPS izsaukumus, kuras uzticamo sertifikātu krātuvē joprojām ir emSign ECC Root CA - G3 vai AAA Certificate Services un kura nav saņēmusi bloķēšanu astoņām atslēgām. Tipiskas vietas:

• Linux serveri un konteineru attēli, kas būvēti pirms 20. vai 21. oktobra. Piemēram, neatjaunināts Debian 12 uzticas abām ķēdēm.
• Programmēšanas valodu izpildes vides, kurām ir savs saraksts: Node.js, Python certifi, Java cacerts, PHP Composer komplekts, Rust webpki-roots.
• macOS komandrindas rīki. Mozilla incidenta lapā teikts, ka iebūvētie curl, git, python3, perl, ruby un openssl pārbauda sertifikātus pret /etc/ssl/cert.pem, nepārbaudot atsaukšanu, un ka Apple šo failu nav atjauninājis.
• Windows datori, kas nesaņem Microsoft automātiskos neatļauto sertifikātu saraksta atjauninājumus, parasti tāpēc, ka tos izslēdz grupas politika (Group Policy) vai tīkls ir bezsaistē.
• Specializētās iekārtas, ierīces un trešo pušu programmatūra ar savu iebūvētu CA failu, piemēram, slodzes balansētāji, VPN vārtejas, SDK un iegultie kontrolleri.

Katra izpildes vide jāpārbauda atsevišķi. Mūsu 22. oktobrī veiktajā testā neatjaunināta Debian 12 mašīna ar Node.js 24.18 pieņēma ķēdi, kas beidzas ar eMudhra saknes sertifikātu, un noraidīja to, kas beidzas ar Sectigo saknes sertifikātu, bet Python tajā pašā mašīnā pieņēma abas.

2. Uzņēmumi, kuru pašu sertifikātu ķēde ved līdz izņemtajam saknes sertifikātam

Mozilla un Linux distribūcijas ir izņēmušas emSign ECC Root CA - G3, un Chrome sekos 27. oktobrī. Derīgi sertifikāti zem šī saknes sertifikāta pārstāj darboties katrā klientā, tiklīdz tas tiek atjaunināts. Google norādījums: tīmekļa vietņu uzturētājiem ar šādiem sertifikātiem „nekavējoties jāiegūst un jāuzstāda jauns TLS sertifikāts no citas PKI hierarhijas, kas iekļauta Chrome Root Store“.

Chrome 21. oktobrī CT žurnālos saskaitīja aptuveni 30 800 sertifikātus zem šī saknes sertifikāta, kuru derīguma termiņš vēl nav beidzies. No tiem 30 791 nāca no diviem InCommon starpsertifikātiem; InCommon ir sertifikātu pakalpojums, ko Internet2 uztur ASV universitātēm un pētniecības iestādēm, un tas ECC sertifikātus izdod caur eMudhra platformu CERTInext. Vēl 18 nāca no paša eMudhra starpsertifikātiem. eMudhra norāda, ka jāpārceļ aptuveni 30 000 sertifikātu, no kuriem aptuveni 97 % izdoti ar ACME, un ka tas izdod aizstājējsertifikātus no citas hierarhijas.

Ja jūsu vietne darbojas aiz Cloudflare režīmā Full (strict) un izcelsmes serveris (origin) uzrāda sertifikātu zem šī saknes sertifikāta, Cloudflare norāda, ka uzticības atņemšana „radītu darbības traucējumus“, un aicina klientus: „Pārskatiet savus pielāgotos izcelsmes serveru sertifikātus un serveru konfigurācijas“.

Šis incidents līdz šim neskar RSA sertifikātus no otra eMudhra saknes sertifikāta, emSign Root CA - G1. Mozilla norāda, ka šo saknes sertifikātu „pašlaik“ neizņem; Chrome „rūpīgi izvērtē eMudhra atlikušo CA sertifikātu turpmāko iekļaušanu“. Ja esat atkarīgi no jebkāda veida eMudhra vai CERTInext sertifikātiem, jau tagad sagatavojiet otru sertifikācijas iestādi.

3. GoDaddy klienti

GoDaddy gadījumam nav nekāda sakara ar eMudhra, taču tas notika tajā pašā nedēļā un skāra daudz vairāk vietņu. 15. oktobrī GoDaddy ziņoja Mozilla, ka sertifikātos no tā GoDaddy un Starfield hierarhijām bija sertifikātu politikas informācija (politikas OID un CPS saites), kas neatbilda profiliem tā paša CP/CPS, dokumentā, kurā sertifikācijas iestāde nosaka, ko tā izdod. Tā nav drošības nepilnība pašos sertifikātos. Saskaņā ar Baseline Requirements, noteikumiem, ko ievēro katra publiskā sertifikācijas iestāde, tas tomēr ir iemesls tos atsaukt piecu dienu laikā.

Skarti bija 404 607 sertifikāti, no tiem 396 055 ar domēna validāciju. Līdz termiņam, 18. oktobrim plkst. 23:45 UTC, GoDaddy atsauca 170 566, bet līdz nākamajam rītam 227 422; tā paziņojumā klientiem teikts, ka pārējie atsaukti 21. oktobrī. GoDaddy sertifikātus izdod no jauna, bet uzstādīt tos ir klienta ziņā: „jūsu tīmekļa vietnes apmeklētāji var redzēt drošības brīdinājumus, un jūsu vietne var kļūt nepieejama, līdz tiek uzstādīts jauns sertifikāts.“

Kas jāpārbauda šodien

1. Ko sūta jūsu pašu serveri? Katram publiskajam resursdatora nosaukumam uzskaitiet izdevējus ķēdē, ko tas uzrāda:

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

Ja kādā rindā minēts eMudhra, emSign, kāda no EM ... G3B vai G3C iestādēm vai InCommon Intermediate CA - DVG3C, OVG3C vai EVG3C, sertifikāts jānomaina pirms 27. oktobra. AAA Certificate Services viens pats ir normāla parādība, jo daudzās parastās Sectigo ķēdēs tas joprojām ir iekļauts. Pasta un direktoriju pakalpojumiem pievienojiet -starttls smtp (vai imap, ldap) un pareizo portu. Iekļaujiet arī iekšējos resursdatorus, slodzes balansētājus un izcelsmes serverus aiz CDN.

2. Kas izdots jūsu domēniem? CT žurnālos ir katrs sertifikāts, ko publiska sertifikācijas iestāde izdevusi jūsu nosaukumiem, arī tie, kurus neviens uzņēmumā neatceras pasūtījis:

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

Rezultāts parāda arī, kuras sertifikācijas iestādes jūsu uzņēmums patiesībā izmanto, un tas ir sākums uzskaitei, kas aprakstīta tālāk.

3. Vai jūsu klienti uzticas kompromitētajām atslēgām? Mozilla testa serveri uzrāda ar kompromitētajām atslēgām izdotus sertifikātus, tāpēc sertifikāta kļūda ir labais rezultāts. Pārbaudiet abas saimes: pirmā resursdatora ķēde ved līdz eMudhra saknes sertifikātam, otrā līdz Sectigo saknes sertifikātam, un krātuve vienā pārbaudē var izgāzties, bet otrā izturēt.

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 atbild tikai par curl. Izpildiet to pašu pieprasījumu caur katras lietotnes pašas TLS steku tajā vidē, kurā lietotne darbojas:

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

Abas Python rindas nav lieks atkārtojums: urllib izmanto operētājsistēmas krātuvi, requests izmanto certifi. Atkārtojiet katru rindu ar resursdatoru dv-g3b-aaa-emudhra. Java gadījumā no attiecīgās JVM veiciet jebkuru HTTPS izsaukumu uz testa serveriem un pārbaudiet, vai tās krātuvē ir kāds no abiem saknes sertifikātiem (Java 9 vai jaunāka; Java 8 izmantojiet -keystore $JAVA_HOME/jre/lib/security/cacerts):

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

Saknes sertifikāts krātuvē pats par sevi vēl nepierāda apdraudējumu, jo Go, Node.js, Deno un Rust rustls-webpki tagad bloķē astoņas atslēgas neatkarīgi no krātuves satura. Galīgo atbildi dod testa serveri.

4. Windows datoru parks. Microsoft par incidentu nav publicējis neko, taču neatļauto sertifikātu saraksts, ko Windows lejupielādē automātiski, kopš 20. oktobra bloķē visas astoņas atslēgas. Izņēmumi ir datori, kuros grupas politika izslēdz automātiskos saknes sertifikātu atjauninājumus, un tīkli bez savienojuma ar Windows Update; tiem saraksts jānogādā citādi. certutil -verifyCTL Disallowed parāda kopiju, ko dators saglabājis kešatmiņā. Mozilla incidenta lapā piedāvāts skripts atsevišķiem datoriem un norādīts, ka tas „nav ieteicams uzņēmuma pārvaldītām ierīcēm“.

5. GoDaddy sertifikāti. Pārbaudiet, kuru sertifikātu katrs serveris patiesībā uzrāda:

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

Ja izdevējs ir GoDaddy vai Starfield, salīdziniet sērijas numuru ar sertifikātiem savā GoDaddy kontā. Ja GoDaddy rāda „Install your new certificate“ (uzstādiet savu jauno sertifikātu), serverī joprojām ir atsauktais sertifikāts.

Viens noteikums visā procesā: nenovērsiet kļūdu, izslēdzot sertifikātu pārbaudi. Cloudflare vārdiem: „Ir svarīgi nenovērst šīs kļūdas, atslēdzot pārbaudi.“ Klients, kas neveic pārbaudi, uzticas katram viltotam sertifikātam, ne tikai šiem.

Kas jāatjaunina šonedēļ

Labojumi ir divu veidu. Abu saknes sertifikātu izņemšana aizver visus ceļus klientam, kas izmanto attiecīgo krātuvi, bet tā arī salauž derīgos sertifikātus zem tiem. Astoņu atslēgu bloķēšana pēc to publiskās atslēgas jaucējvērtības (hash), kā to dara Go, Node.js, Deno, Electron, rustls-webpki, Composer un Windows, aizver caurumu un neko citu nesalauž. Ja jūsu platforma piedāvā otro veidu, dodiet tam priekšroku.

„Vēl nav“ nozīmē, ka līdz 22. oktobrim nekas nebija publicēts. Pirms uz to balstāt plānus, pārbaudiet vēlreiz.

Komandas bieži paklūp uz četrām lietām:

• Konteineru attēli patur veco sarakstu. Attēls, kas būvēts pirms 20. vai 21. oktobra, uzticas atslēgām, līdz tas tiek pārbūvēts uz atjaunināta bāzes attēla, un tā paša taga atkārtota lejupielāde palīdz tikai tad, kad bāzes attēls ir pārbūvēts. Pārbūvējiet, izvietojiet no jauna un pajautājiet piegādātājiem, kuru attēlus izmantojat.
• Procesi patur to, ko ielādējuši. Programma nolasa uzticamo sertifikātu krātuvi startējot, tāpēc pēc atjaunināšanas restartējiet ilgstoši strādājošos pakalpojumus. Node.js piebilst, ka TLS sesijas, kas atsāktas no laika pirms atjaunināšanas, netiek pārbaudītas vēlreiz.
• Lietotnēm ir savi CA faili. SDK un lietotnes bieži piegādā savu cacert.pem vai ca-bundle.crt. Meklējiet tos repozitorijos un attēlos, piemēram, ar find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, un rēķinieties, ka atradīsiet vairāk nekā vienu: pip, piemēram, satur savu certifi kopiju.
• Ierīces gaida savu piegādātāju. Rakstiski pajautājiet katram piegādātājam, kuru uzticamo sertifikātu krātuvi produkts izmanto un kad tiks izlaists atjauninājums. Kamēr tas nav noticis, ierīce uzticas viltotiem sertifikātiem visiem pakalpojumiem, ko tā izsauc, tāpēc ierobežojiet, kam tā var piekļūt.

Ja AAA Certificate Services izņemat manuāli, kā to dara Debian, Ubuntu ESM, Fedora un Red Hat pagaidu risinājums, pēc tam pārbaudiet savienojumus ar pakalpojumiem, kuriem ir Sectigo sertifikāti: daži vecāki serveri joprojām sūta ķēdi, kas beidzas ar šo saknes sertifikātu.

Kas jāievieš pirms nākamā incidenta

Sertifikācijas iestāde ar tik vājām atslēgām ir retums. Masveida atsaukšana nav. Šīs ir 2026. gada lielākās, kas reģistrētas Mozilla kļūdu izsekošanas sistēmā:

Neviens no šiem pieciem gadījumiem nebija drošības kļūme. Katrā no tiem sertifikāts neatbilda pašas iestādes dokumentam, un Baseline Requirements (4.9.1.1. sadaļa) tomēr prasa atsaukšanu piecu dienu laikā. Ja atslēga ir kompromitēta vai domēna validācijai nevar uzticēties, termiņš ir 24 stundas. Neviens to jums nevar pagarināt. Kad DigiCert 2024. gadā atsauca 83 267 sertifikātus, Chrome Root Program rakstīja, ka tai „nav pilnvaru piešķirt izņēmumus“; viens klients panāca tiesas rīkojumu, kas apturēja tā sertifikātu atsaukšanu, un rīkojums četras dienas vēlāk tika atcelts.

Daudz pasaka tas, kā noritēja nomaiņa. Jūlijā HARICA izmantoja ACME Renewal Information (ARI), lai liktu savu klientu ACME klientiem atjaunot sertifikātus priekšlaicīgi, un citus sertifikātus izdeva no jauna pati; lielākajā no abām atsaukšanām 87 % skarto nosaukumu bija nomainīti, kad pienāca termiņš. GoDaddy, kura klienti katru aizstājējsertifikātu lejupielādē un uzstāda paši, līdz savam termiņam bija atsaucis 42 % skarto sertifikātu.

Atjaunošanas cikls jebkurā gadījumā kļūst īsāks:

• Saskaņā ar CA/Browser Forum balsojumu SC-081 publisko TLS sertifikātu derīgums kopš 2026. gada 15. marta ir ierobežots līdz 200 dienām. 2027. gada 15. martā ierobežojums samazinās līdz 100 dienām un 2029. gada 15. martā līdz 47 dienām, un tad domēna validāciju varēs atkārtoti izmantot tikai 10 dienas.
• Let's Encrypt 2027. gada 10. februārī pēc noklusējuma pāriet uz 64 dienu sertifikātiem un gadu vēlāk uz 45 dienām.
• Publiskie TLS sertifikāti zaudē klienta autentifikāciju. Let's Encrypt to pārstāja nodrošināt 2026. gada 8. jūlijā, un Chrome Root Program prasa, lai sertifikāti, kas izdoti no 2027. gada 15. marta, būtu paredzēti tikai servera autentifikācijai. Ja publiskos sertifikātus izmantojat kā klientu sertifikātus savstarpējai TLS autentifikācijai (mutual TLS), kas ir izplatīti B2B API integrācijās, šiem savienojumiem vajadzīga privāta sertifikācijas iestāde.

Pie 100 dienām un vēlāk pie 47 sertifikātu manuāla uzstādīšana vairs nav reāla iespēja. Uzņēmums, kas automatizē atbilstoši šim grafikam, ir gatavs arī nākamajai masveida atsaukšanai. Kas tam vajadzīgs:

1. Ziniet, kas jums ir, abos virzienos. Viens saraksts ar katru sertifikātu, ko uzrāda jūsu serveri, ar resursdatora nosaukumu, izdevēju, derīguma termiņu, atjaunošanas veidu un atbildīgo. Otrs saraksts ar katru uzticamo sertifikātu krātuvi, uz kuru paļaujas jūsu programmatūra: operētājsistēmas pakotne, katras valodas komplekts, katrs CA fails lietotnē vai ierīcē. Iepriekš aprakstītā CT meklēšana iesāk pirmo sarakstu; programmatūras materiālu saraksts (SBOM) vai atkarību uzskaite iesāk otro.
2. Automatizējiet izdošanu un uzstādīšanu. ACME visur, kur to var darbināt, ar ARI (RFC 9773), lai sertifikācijas iestāde varētu likt jūsu klientiem atjaunot sertifikātus priekšlaicīgi. Ja ierīcē ACME nevar darbināt, izmantojiet piegādātāja automatizāciju vai terminējiet TLS tās priekšā uz sistēmas, kas to spēj.
3. Turiet gatavībā otru sertifikācijas iestādi. Strādājošs, pārbaudīts ACME konts pie otras iestādes un CAA ieraksti DNS, kas atļauj abas. Kad vienai iestādei atņem uzticību vai tā masveidā atsauc sertifikātus, pāreja kļūst par konfigurācijas izmaiņu.
4. Uzraugiet CT saviem domēniem. Saņemiet brīdinājumu par katru jaunu sertifikātu jūsu nosaukumiem. Par negaidītu izdošanu jūs uzzināt tajā pašā dienā.
5. Uztveriet uzticamo sertifikātu krātuves kā atkarības. Atjauniniet tās ar parasto labojumu uzstādīšanu un pārbūvējiet attēlus pēc grafika, nevis tikai tad, kad mainās kods.
6. Uzrakstiet rīcības rokasgrāmatu (runbook), rēķinoties ar abiem termiņiem. 24 stundas un piecas dienas: kas pieņem lēmumu, kam ir piekļuve katrai sistēmai, kurām sistēmām vajadzīgas manuālas darbības, kā sazināties ar katru piegādātāju. Reizi gadā izmēģiniet to, nomainot sertifikātu pakalpojumā, kurā kļūda nav liktenīga. Publiskajām sertifikācijas iestādēm kopš 2025. gada ir jāuztur un jātestē savs masveida atsaukšanas plāns; to klientiem vajadzīga otra puse.

Ja ražojat produktus, ko darbina citi

Ja jūsu produktā ir uzticamo sertifikātu krātuve (ierīce, instalēta lietotne, SDK), jūsu klienti ir aizsargāti tikai tad, kad jūsu atjauninājums viņus sasniedz. Izlaidiet to un pastāstiet klientiem, kurās versijās problēma novērsta. Mozilla padoms uzticamo sertifikātu krātuvju uzturētājiem: bloķējiet astoņus starpsertifikātus, ja jūsu programmatūra to spēj, pretējā gadījumā „apsveriet, vai ir piemēroti atņemt uzticību saknes sertifikātiem, kas parakstīja šos starpsertifikātus“.

Kibernoturības akts šeit attiecas divējādi. Tā ziņošanas pienākums, kas ir spēkā kopš 2026. gada 11. septembra, aptver aktīvi izmantotas ievainojamības, un šajā gadījumā par izmantošanu nav ziņots. Tā būtiskās prasības, ko piemēros no 2027. gada 11. decembra, ietver to, ka ievainojamības var novērst ar drošības atjauninājumiem; produkts, kura uzticamo sertifikātu sarakstu nevar atjaunināt, tām neatbilstu. Klienti, uz kuriem attiecas NIS2, jautās saviem piegādātājiem, cik ātri viņi to atrisināja, un ir noderīgi, ja atbilde ir pierakstīta.

Kas vēl nav atrisināts

• eMudhra atlikušais saknes sertifikāts. Chrome 21. oktobrī uzdeva eMudhra divpadsmit jautājumus un nav paziņojis lēmumu par emSign Root CA - G1. Mozilla to „pašlaik“ neizņem.
• eMudhra pārejas ceļš. Tas informēja Mozilla, ka pārcels klientus uz savu G1 (RSA) hierarhiju; tā statusa lapā runāts par „alternatīvu, neatkarīgi pārvaldītu, publiski uzticamu CA hierarhiju“. Chrome ir jautājis, kuru.
• Microsoft un Apple. Neviens no tiem nav publicējis paziņojumu vai izņēmis kādu no abiem saknes sertifikātiem no savas krātuves.
• Gaidāmie labojumi. Red Hat, Amazon Linux, Temurin un Corretto līdz 22. oktobrim nebija izlaiduši neko; Bun labojums bija iekļauts pirmkodā, bet vēl nebija izlaists.
• Pamatcēlonis. eMudhra to nav apstiprinājis un ir paziņojis, ka atkārtoti pārbaudīs katru savu veikto atslēgu ceremoniju.
• Sectigo. Atsevišķā lietā, kas atvērta kopš 5. septembra, Sectigo ir atteicies atsaukt sertifikātus, kuru paplašinātais atslēgas lietojums (extended key usage) neatbilda kādam teikumam tā CPS, apgalvojot, ka teikums bija divdomīgs. 18. oktobrī tas saskaitīja aptuveni 72 miljonus šādu sertifikātu, kas joprojām ir aktīvi. Daži publiskās diskusijas dalībnieki ir aicinājuši atņemt tam uzticību; neviena saknes sertifikātu programma nav paziņojusi lēmumu. Uzņēmumiem ar Sectigo sertifikātiem vajadzētu sekot lietai.

Kur saņemt palīdzību

Sertifikātu problēma reti piesaka sevi kā sertifikātu problēmu. Tā izpaužas kā pirkuma noformēšanas lapa, kas vairs neielādējas, integrācija, kas pārstāj sinhronizēties, vai ierīce, kas pārstāj sūtīt datus, parasti nedēļas nogalē. Mēs palīdzam uzņēmumiem pārdzīvot šādas nedēļas bez darbības pārtraukuma un sakārtot lietas tā, lai nākamā būtu ikdienišķs darbs:

• Apdraudējuma pārbaude. Mēs atrodam, kur jūsu sistēmas veido vai pieņem TLS savienojumus, kuru uzticamo sertifikātu krātuvi katra no tām izmanto un kurus sertifikātus jūs uzrādāt, ieskaitot konteinerus, Java pakalpojumus, integrācijas ar bankām, maksājumu un loģistikas pakalpojumu sniedzējiem un ierīces.
• Labojumi. Atjauninājumi, pārbūvēti attēli, bloķētas atslēgas vai nomainīti sertifikāti, veikti caur jūsu izmaiņu pārvaldības procesu un pārbaudīti pret Mozilla testa serveriem.
• Automatizācija 2027. gadam. ACME ar ARI serveros, slodzes balansētājos un specializētajās iekārtās, otra sertifikācijas iestāde, CAA ieraksti, CT uzraudzība un rīcības rokasgrāmata, gatavi 100 dienu sertifikātiem no 2027. gada 15. marta.
• Sistēmas, kurām neviens negrib pieskarties. Vecas Java lietotnes, specializētās iekārtas un iegultie klienti ar savām uzticamo sertifikātu krātuvēm ir tieši tas, kam paredzēts mūsu mantoto sistēmu un koda uzturēšanas pakalpojums.

Ja neesat pārliecināti, vai tas skar jūs, uzrakstiet uz office@c9group.dev, norādot savus domēnus un izmantotās platformas, vai piesakiet sarunu. Mēs pateiksim, ko pārbaudīt vispirms.