Az eMudhra CA-kulcsainak kompromittálódása: mit ellenőrizzenek és javítsanak ki most a cégek

2026. október 17-én, szombaton egy biztonsági kutató jelezte, hogy az eMudhra indiai hitelesítésszolgáltató által üzemeltetett nyolc köztes CA (intermediate CA) privát kulcsát bárki kiszámíthatta a nyilvános tanúsítványokból. Mindegyik kulcs 256-nál kisebb szám volt. Az egyik maga a 4-es szám. A nyolcból hat olyan TLS-tanúsítványokat adhatott ki, amelyekben az Apple, a Google, a Microsoft és a Mozilla megbízik; a másik kettő Windows-szoftvereket írhatott alá.

A Chrome egy óra negyven perccel a bejelentés után letiltotta a hat TLS-kulcsot, a Firefox pedig még aznap este. A webet böngészők számára szombat éjjelre véget ért a veszély.

Minden más esetében viszont nem. A szerverek, a konténerek, a Java-alkalmazások, a Python-szkriptek, a fizetési integrációk és a csatlakoztatott eszközök a megbízható hitelesítésszolgáltatók listájának saját példányával vetik össze a tanúsítványokat, és ezek a példányok többnyire csak akkor változnak, amikor valaki telepít egy frissítést. Addig bármely domainre kiállított, e kulcsok egyikével aláírt tanúsítvány valódinak számít, a kulcsok pedig október 20. óta nyilvánosak.

Ugyanazon a héten a GoDaddy 404 607 tanúsítvány visszavonásába kezdett, mert a bennük szereplő tanúsítványszabályzati adatok nem egyeztek a saját közzétett dokumentumaival. Az ügyfeleinek maguknak kellett letölteniük és telepíteniük a cseretanúsítványokat.

Ez az útmutató azoknak szól, akiknek választ kell adniuk arra a kérdésre, hogy „érint-e minket?”: informatikai és üzemeltetési vezetőknek, CTO-knak és olyan alapítóknak, akiknek az üzlete egy webhelyen, egy API-n vagy egy csatlakoztatott terméken múlik. Leírja, mi történt (a Mozilla, a Google, az eMudhra, a GoDaddy és a szoftverszállítók által közzétett incidensdokumentáció alapján), mit kell ma ellenőrizni, mit kell ezen a héten frissíteni, és mit érdemes bevezetni ahhoz, hogy a következő hasonló incidens rutinfeladat legyen. Minden itt leírt információ a 2026. október 22-i állapotot tükrözi, és az incidens még nem zárult le.

Mi történt

Az eMudhra a nyolc köztes CA-t egy 2025. április 30-i kulcsgenerálási ceremónián hozta létre. A Mozilla incidensről nyitott hibajegyében október 19-én közzétett beszámolója szerint egy kulcsbecsomagolási és -kibontási lépés tesztje, amelyet a szokásos eljárástól való eltérésként hagytak jóvá, olyan hibát tartalmazott, amely a hardveres biztonsági modulban (HSM) a szándékolt kulcsok mellett egy második, gyenge kulcskészletet is létrehozott. A címkék hasonlók voltak, a tanúsítványkérelmeket tévedésből a gyenge kulcsokkal készítették el, és az eMudhra gyökértanúsítványa ezeket írta alá. Ugyanezek a kérelmek a Sectigóhoz is eljutottak, amely 2025. május 14-én az AAA Certificate Services gyökértanúsítványáról mind a nyolcat keresztaláírta. Az eMudhra közlése szerint „még nem erősítette meg a pontos kiváltó okot”.

A Mozilla így írta le az eredményt: „A P384 privát kulcsok véletlenszerűen választott egész számok 1 és a csoport rendje között. Mind a 8 érintett kulcs 256-nál kisebb egész számot használt.” A Mozilla 20:06 UTC-kor kapta meg a bejelentést, és 21:48-ra maga is kiszámította a kulcsokat, „anélkül, hogy bármit tudott volna az eredeti bejelentő által használt módszerről”. A kutató szerint a Google nyílt forráskódú paranoid_crypto könyvtárával találta meg őket, „mindenféle beállítás nélkül”. A gyenge kulcsok csaknem 18 hónapig voltak részei nyilvánosan megbízható tanúsítványláncoknak.

A nyolc tanúsítvány:

Mindegyik kulcs két tanúsítványban szerepel. Az egyiket az eMudhra emSign Root TLS CA - G3 vagy emSign Root CS CA - G3 CA-ja adta ki, amelyek az emSign ECC Root CA - G3 gyökértanúsítványig vezetnek; a másik a Sectigo kereszttanúsítványa az AAA Certificate Services gyökértanúsítványról. A második útvonal azért fontos, mert egyes tanúsítványtárak (trust store-ok), amelyekben soha nem volt eMudhra-gyökértanúsítvány, ma is megbíznak ebben a régi Sectigo-gyökértanúsítványban.

Volt-e támadás?

Visszaélést senki nem jelentett, és a böngészők esetében jó okkal feltételezhető, hogy nem is volt. A Chrome, a Certificate Transparency (CT, a kiadott tanúsítványok nyilvános naplózása) szabályait érvényesítő többi klienshez hasonlóan, csak olyan tanúsítványt fogad el, amely szerepel a nyilvános CT-naplókban. A Google szerint a tiltás előtt egyetlen, e hat köztes CA-hoz vezető TLS-tanúsítvány sem került be a naplókba, így „ezek a CA-k nem adhattak ki olyan hamis tanúsítványt, amelyet a CT-t érvényesítő kliensek ellen fel lehetett volna használni”.

A böngészőn kívül más a kép. A Mozilla incidensoldala szerint „a böngészők ökoszisztémáján kívül sok kliens nem érvényesíti a Certificate Transparency szabályait. Nem tudjuk, hogy a támadók kihasználták-e a hibás kulcsgenerálást e kliensek ellen.” Ez az időablak 2025 tavaszán nyílt meg, és minden kliens esetében csak akkor zárul be, amikor az adott kliens frissítést kap. Az eMudhra közlése szerint nincs tudomása olyan bizonyítékról, hogy a kulcsokat a nyilvánosságra hozatal előtt bárki kiszámította volna, a Cloudflare pedig azt írja, hogy a vizsgálata nem talált aktív kihasználást a szolgáltatásain.

Most, hogy a kulcsok nyilvánosak, egy tanúsítvány hamisításához semmilyen szakértelem nem kell. A Mozilla incidensoldala tesztszervereket sorol fel, amelyek a kompromittálódott kulcsokkal kiadott tanúsítványokat küldenek, így bárki ellenőrizheti velük a saját klienseit (a parancsokat lent találja).

Mire jó egy hamis tanúsítvány: aki el tudja fogni a forgalmat az Ön szoftvere és egy általa hívott szolgáltatás között (közös hálózaton, egy feltört routeren vagy egy megmérgezett DNS-válaszon keresztül), az ki tudja adni magát az adott szolgáltatásnak, el tudja olvasni, amit az Ön szoftvere küld, az API-kulcsokat és a személyes adatokat is beleértve, és meg tudja változtatni, amit a szoftver kap. A két kódaláíró kulcs egyikével aláírt szoftver mindaddig átment volna a Windows aláírás-ellenőrzésén, amíg a Microsoft tiltása el nem érte az adott gépet.

Kiket érint

Három különálló problémáról van szó, és egy cégnél akár mindhárom előfordulhat.

1. Szoftverek, amelyek még megbíznak a kompromittálódott kulcsokban

Ez szinte minden céget érint: minden olyan program, amely HTTPS-hívásokat indít, a tanúsítványtárában még szerepel az emSign ECC Root CA - G3 vagy az AAA Certificate Services, és még nem kapta meg a nyolc kulcs tiltását. Tipikus helyek:

• Linux-szerverek és konténer-image-ek, amelyek október 20. vagy 21. előtt készültek. Egy javítatlan Debian 12 például mindkét láncban megbízik.
• Saját listát szállító nyelvi futtatókörnyezetek: a Node.js, a Python certifi csomagja, a Java cacerts tára, a PHP-s Composer saját csomagja, a Rust-os webpki-roots.
• A macOS parancssori eszközei. A Mozilla incidensoldala szerint a beépített curl, git, python3, perl, ruby és openssl a /etc/ssl/cert.pem fájllal veti össze a tanúsítványokat, a visszavonás ellenőrzése nélkül, és az Apple ezt a fájlt nem frissítette.
• Windows-gépek, amelyek nem kapják meg a Microsoft nem engedélyezett tanúsítványok listájának automatikus frissítéseit, általában azért, mert a csoportházirend kikapcsolja őket, vagy mert a hálózat el van zárva az internettől.
• Appliance-ek, eszközök és harmadik féltől származó szoftverek, amelyek saját CA-fájlt tartalmaznak, például terheléselosztók, VPN-átjárók, SDK-k és beágyazott vezérlők.

Minden futtatókörnyezetet külön kell ellenőrizni. Egy október 22-én általunk végzett teszten egy javítatlan Debian 12-es gépen a Node.js 24.18 elfogadta az eMudhra gyökértanúsítványáig vezető láncot, és elutasította a Sectigo gyökértanúsítványáig vezetőt, míg ugyanazon a gépen a Python mindkettőt elfogadta.

2. Cégek, amelyeknek saját tanúsítványai az eltávolított gyökértanúsítványhoz vezetnek

A Mozilla és a Linux-disztribúciók eltávolították az emSign ECC Root CA - G3 tanúsítványt, a Chrome pedig október 27-én követi őket. Az e gyökértanúsítvány alá tartozó érvényes tanúsítványok minden kliensben akkor szűnnek meg működni, amikor az adott kliens frissül. A Google utasítása szerint az ilyen tanúsítvánnyal rendelkező webhely-üzemeltetőknek „azonnal be kell szerezniük és telepíteniük egy új TLS-tanúsítványt a Chrome Root Store-ban szereplő másik PKI-hierarchiából”.

A Chrome október 21-én körülbelül 30 800 le nem járt tanúsítványt számolt meg a CT-ben e gyökértanúsítvány alatt. Ebből 30 791 az InCommon két köztes CA-jától származott; az InCommon az Internet2 tanúsítványszolgáltatása amerikai egyetemek és kutatóintézetek számára, és ECC-tanúsítványokat az eMudhra platformján, a CERTInexten keresztül ad ki. Az eMudhra saját köztes CA-itól 18 származott. Az eMudhra szerint körülbelül 30 000 tanúsítványt kell átköltöztetni, ezek körülbelül 97%-át ACME-n keresztül adták ki, és a cég egy másik hierarchiából ad ki cseretanúsítványokat.

Ha a webhelye Full (strict) módban a Cloudflare mögött van, és az origin szerver e gyökértanúsítvány alá tartozó tanúsítványt küld, a Cloudflare szerint a bizalom megvonása „hibákat okozna”, és arra kéri az ügyfeleit: „Tekintsék át egyéni origin-tanúsítványaikat és szerverkonfigurációikat”.

Az eMudhra másik gyökértanúsítványa, az emSign Root CA - G1 alá tartozó RSA-tanúsítványok egyelőre nem érintettek. A Mozilla szerint ezt a gyökértanúsítványt „jelenleg” nem távolítja el; a Chrome „alaposan vizsgálja az eMudhra többi CA-tanúsítványának további szerepeltetését”. Ha bármilyen eMudhra- vagy CERTInext-tanúsítványtól függ, már most készítsen elő egy második hitelesítésszolgáltatót.

3. A GoDaddy ügyfelei

A GoDaddy ügyének semmi köze az eMudhrához, de ugyanazon a héten történt, és sokkal több webhelyet érintett. A GoDaddy október 15-én jelentette a Mozillának, hogy a GoDaddy és a Starfield hierarchiájából kiadott tanúsítványai olyan tanúsítványszabályzati adatokat (policy OID-kat és CPS-hivatkozásokat) tartalmaztak, amelyek nem egyeztek a saját CP/CPS-ében szereplő profilokkal; a CP/CPS az a dokumentum, amelyben egy hitelesítésszolgáltató rögzíti, mit ad ki. Ez nem biztonsági hiba a tanúsítványokban. A Baseline Requirements (az a szabályrendszer, amelyet minden nyilvános hitelesítésszolgáltató követ) szerint azonban ez is ok arra, hogy öt napon belül visszavonják őket.

Összesen 404 607 tanúsítvány volt érintett, ebből 396 055 domainvalidált (DV). A GoDaddy az október 18., 23:45 UTC-s határidőig 170 566-ot vont vissza, másnap reggelig pedig 227 422-t; az ügyfeleknek szóló tájékoztatója szerint a többit október 21-én vonták vissza. A GoDaddy újra kiadja a tanúsítványokat, de a telepítésük az ügyfél dolga: „a webhelye látogatói biztonsági figyelmeztetéseket láthatnak, és a webhelye elérhetetlenné válhat, amíg nem telepítenek új tanúsítványt.”

Mit ellenőrizzen még ma

1. Mit küldenek a saját szerverei? Minden nyilvános hosztnévnél listázza ki a kiadókat abban a láncban, amelyet a szerver küld:

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

Ha egy sorban az eMudhra, az emSign, az EM ... G3B vagy G3C CA-k egyike, illetve az InCommon Intermediate CA - DVG3C, OVG3C vagy EVG3C szerepel, a tanúsítványt október 27. előtt le kell cserélni. Az AAA Certificate Services önmagában normális, mert sok szokásos Sectigo-lánc még tartalmazza. Levelezési és címtárszolgáltatásoknál adja hozzá a -starttls smtp (vagy imap, ldap) kapcsolót és a megfelelő portot. A belső hosztokat, a terheléselosztókat és a CDN mögötti origin szervereket se hagyja ki.

2. Mit adtak ki a domainjeire? A CT minden olyan tanúsítványt listáz, amelyet egy nyilvános hitelesítésszolgáltató az Ön neveire kiadott, azokat is, amelyek megrendelésére a cégnél senki nem emlékszik:

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

A kimenetből az is látszik, mely hitelesítésszolgáltatókat használja ténylegesen a cége; ez a lentebb leírt leltár kiindulópontja.

3. Megbíznak-e a kliensei a kompromittálódott kulcsokban? A Mozilla tesztszerverei a kompromittálódott kulcsokkal kiadott tanúsítványokat küldenek, ezért a tanúsítványhiba a jó eredmény. Mindkét családot tesztelje: az első hoszt az eMudhra gyökértanúsítványához vezet, a második a Sectigóéhoz, és egy tanúsítványtár az egyik teszten megbukhat, a másikon átmehet.

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"

A curl csak a curlről árul el valamit. Futtassa le ugyanezt a kérést minden alkalmazás saját TLS-stackjén keresztül, abban a környezetben, ahol az alkalmazás fut:

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

A két Python-sor nem felesleges ismétlés: az urllib az operációs rendszer tanúsítványtárát használja, a requests a certifit. Ismételje meg mindegyik sort a dv-g3b-aaa-emudhra hoszttal is. Java esetében indítson bármilyen HTTPS-hívást a tesztszerverek felé az érintett JVM-ből, és listázza ki, tartalmazza-e a tanúsítványtára valamelyik gyökértanúsítványt (Java 9 vagy újabb; Java 8 esetén használja a -keystore $JAVA_HOME/jre/lib/security/cacerts kapcsolót):

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

Önmagában az, hogy egy gyökértanúsítvány szerepel a tanúsítványtárban, még nem bizonyítja a kitettséget, mert a Go, a Node.js, a Deno és a Rust-os rustls-webpki már a tanúsítványtár tartalmától függetlenül letiltja a nyolc kulcsot. A tesztszerverek döntik el a kérdést.

4. Windows-géppark. A Microsoft semmit nem tett közzé az incidensről, de a nem engedélyezett tanúsítványok listája, amelyet a Windows automatikusan letölt, október 20. óta mind a nyolc kulcsot letiltja. Kivételt képeznek azok a gépek, amelyeken a csoportházirend kikapcsolja a gyökértanúsítványok automatikus frissítését, valamint azok a hálózatok, amelyekből nem érhető el a Windows Update; ezekhez más úton kell eljuttatni a listát. A certutil -verifyCTL Disallowed megmutatja, melyik példányt tárolja a gép a gyorsítótárában. A Mozilla incidensoldala egyedi gépekhez kínál szkriptet, és azt írja, hogy az „nem ajánlott vállalati felügyelet alatt álló eszközökre”.

5. GoDaddy-tanúsítványok. Ellenőrizze minden szervernél, ténylegesen melyik tanúsítványt küldi:

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

Ha a kiadó a GoDaddy vagy a Starfield, vesse össze a sorozatszámot a GoDaddy-fiókjában lévő tanúsítványokkal. Ahol a GoDaddy az „Install your new certificate” (Telepítse az új tanúsítványát) feliratot mutatja, a szerveren még a visszavont tanúsítvány van.

Egy szabály mindvégig érvényes: ne úgy tüntessen el egy hibát, hogy kikapcsolja a tanúsítvány-ellenőrzést. A Cloudflare szavaival: „Fontos, hogy ezeket a hibákat ne az ellenőrzés kikapcsolásával oldják meg.” Az a kliens, amely nem ellenőriz, minden hamis tanúsítványban megbízik, nem csak ezekben.

Mit frissítsen ezen a héten

Kétféle javítás létezik. A két gyökértanúsítvány eltávolítása minden útvonalat lezár az adott tanúsítványtárat használó kliens számára, de az alájuk tartozó érvényes tanúsítványokat is működésképtelenné teszi. A nyolc kulcs letiltása a nyilvános kulcsuk hash-e alapján, ahogy a Go, a Node.js, a Deno, az Electron, a rustls-webpki, a Composer és a Windows teszi, bezárja a rést, és semmi mást nem ront el. Ahol a platformja a másodikat kínálja, azt válassza.

A „még nincs” azt jelenti, hogy október 22-ig semmi nem jelent meg. Mielőtt erre építve tervez, ellenőrizze újra.

Négy dolog szokta meglepni a csapatokat:

• A konténer-image-ek megtartják a régi listát. Egy október 20. vagy 21. előtt épített image addig megbízik a kulcsokban, amíg újra nem építik egy frissített alap-image-re, és ugyanannak a tagnek az újbóli letöltése csak akkor segít, ha az alap-image-et már újraépítették. Építse újra az image-eket, telepítse újra őket, és kérdezze meg azokat a szállítókat, akiknek az image-eit futtatja.
• A folyamatok megtartják, amit betöltöttek. Egy program induláskor olvassa be a tanúsítványtárát, ezért frissítés után indítsa újra a hosszan futó szolgáltatásokat. A Node.js hozzáteszi: a frissítés előtt létrejött és később folytatott TLS-munkameneteket nem ellenőrzi újra.
• Az alkalmazások saját CA-fájlokat hoznak magukkal. Az SDK-k és az alkalmazások gyakran saját cacert.pem vagy ca-bundle.crt fájlt szállítanak. Keressen rájuk a kódtárakban és az image-ekben, például a find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null paranccsal, és számítson rá, hogy nem csak egyet talál: a pip például a certifi saját példányát hozza magával.
• Az eszközök a gyártójukra várnak. Kérdezze meg írásban minden gyártótól, melyik tanúsítványtárat használja a termék, és mikor jelenik meg a frissítés. Amíg meg nem jelenik, az eszköz minden általa hívott szolgáltatásnál megbízik a hamis tanúsítványokban, ezért korlátozza, mit érhet el.

Ha kézzel távolítja el az AAA Certificate Services tanúsítványt, ahogy a Debian, az Ubuntu ESM, a Fedora és a Red Hat megkerülő megoldása teszi, utána tesztelje a kapcsolatokat a Sectigo-tanúsítványt használó szolgáltatások felé: egyes régebbi szerverek még mindig olyan láncot küldenek, amely ennél a gyökértanúsítványnál végződik.

Mit vezessen be a következő incidens előtt

Ritka, hogy egy hitelesítésszolgáltató ennyire gyenge kulcsokkal dolgozzon. A tömeges visszavonások viszont nem ritkák. A Mozilla hibakövető rendszerében rögzített 2026-os nagyobb esetek:

Az öt eset egyike sem volt biztonsági hiba. Mindegyikben egy tanúsítvány eltért a hitelesítésszolgáltató saját dokumentumától, és a Baseline Requirements (4.9.1.1. pont) ilyenkor is öt napon belüli visszavonást ír elő. Ha egy kulcs kompromittálódott, vagy a domainvalidálásra nem lehet támaszkodni, a határidő 24 óra. Ezt senki nem hosszabbíthatja meg Önnek. A DigiCert 83 267 tanúsítványt érintő 2024-es visszavonásánál a Chrome Root Program azt írta, hogy „nincs jogköre kivételeket engedélyezni”; egy ügyfél bírósági végzést szerzett a tanúsítványai visszavonásának leállítására, a végzést azonban négy nappal később hatályon kívül helyezték.

Sokat elárul, hogyan zajlott a csere. A HARICA júliusban az ACME Renewal Information (ARI) segítségével jelezte ügyfelei ACME-klienseinek, hogy idő előtt újítsák meg a tanúsítványokat, a többi tanúsítványt pedig maga adta ki újra; a két visszavonása közül a nagyobbiknál a határidő lejártakor az érintett nevek 87%-át már lecserélték. A GoDaddy, amelynek ügyfelei maguk töltenek le és telepítenek minden cseretanúsítványt, a határidejéig az érintett tanúsítványainak 42%-át vonta vissza.

A megújítási ciklus amúgy is rövidül:

• A CA/Browser Forum SC-081-es szavazása (ballot) alapján a nyilvános TLS-tanúsítványok érvényessége 2026. március 15. óta legfeljebb 200 nap. A korlát 2027. március 15-én 100 napra, 2029. március 15-én pedig 47 napra csökken, és ettől kezdve a domainvalidálás eredménye csak 10 napig használható fel újra.
• A Let's Encrypt 2027. február 10-én 64 napos tanúsítványokra állítja át az alapértelmezést, egy évvel később pedig 45 naposakra.
• A nyilvános TLS-tanúsítványok elveszítik a kliens-hitelesítési funkciót. A Let's Encrypt 2026. július 8-án abbahagyta az ilyen tanúsítványok kiadását, a Chrome Root Program pedig előírja, hogy a 2027. március 15-től kiadott tanúsítványok kizárólag szerver-hitelesítésre szolgáljanak. Ha nyilvános tanúsítványokat használ kliens-tanúsítványként kölcsönös TLS-hez (mutual TLS), ami a B2B API-integrációkban gyakori, ezekhez a kapcsolatokhoz privát hitelesítésszolgáltató kell.

100, majd 47 napos érvényesség mellett a tanúsítványok kézi telepítése már nem reális lehetőség. Az a cég, amely ehhez az ütemhez igazítva automatizál, a következő tömeges visszavonásra is felkészült. Mi kell ehhez:

1. Tudja, mi van Önnél, mindkét irányban. Egy lista minden tanúsítványról, amelyet kiszolgál, a hosztnévvel, a kiadóval, a lejárattal, a megújítás módjával és a felelőssel. Egy második lista minden tanúsítványtárról, amelyre a szoftverei támaszkodnak: az operációs rendszer csomagjáról, minden nyelvi csomagról, minden alkalmazásban vagy eszközben lévő CA-fájlról. Az első listát a fenti CT-keresés indítja el, a másodikat egy szoftverösszetevő-jegyzék (SBOM) vagy függőségleltár.
2. Automatizálja a kiadást és a telepítést. ACME mindenhol, ahol futtatható, ARI-val (RFC 9773), hogy a hitelesítésszolgáltató jelezhesse a klienseinek, ha idő előtt meg kell újítaniuk a tanúsítványt. Ahol egy eszközön nem futhat ACME, használja a gyártó automatizálását, vagy végezze a TLS-terminálást az eszköz előtt egy olyan komponensen, amely képes rá.
3. Tartson készenlétben egy második hitelesítésszolgáltatót. Egy működő, kipróbált ACME-fiók egy második szolgáltatónál, és olyan CAA-rekordok a DNS-ben, amelyek mindkettőt engedélyezik. Ha az egyik szolgáltatótól megvonják a bizalmat, vagy tömegesen von vissza tanúsítványokat, a váltás egy konfigurációs módosítás kérdése lesz.
4. Figyelje a CT-t a domainjeire. Kérjen riasztást minden új tanúsítványról, amelyet az Ön neveire adnak ki. Így a váratlan kiadásról még aznap értesül, amikor megtörténik.
5. Kezelje a tanúsítványtárakat függőségként. Frissítse őket a szokásos javítási folyamat részeként, és az image-eket ütemezetten építse újra, ne csak akkor, amikor a kód változik.
6. Írja meg a runbookot (műveleti forgatókönyvet) a két határidőre. 24 óra és öt nap: ki dönt, kinek van hozzáférése az egyes rendszerekhez, mely rendszerekhez kellenek kézi lépések, hogyan éri el az egyes szállítókat. Évente egyszer próbálja ki egy olyan szolgáltatás tanúsítványának cseréjével, amelyen megengedhető egy hiba. A nyilvános hitelesítésszolgáltatóknak 2025 óta saját tömeges visszavonási tervet kell vezetniük és tesztelniük; az ügyfeleiknek a másik felére van szükségük.

Ha olyan termékeket gyárt, amelyeket mások futtatnak

Ha a terméke tanúsítványtárat tartalmaz (egy eszköz, egy telepített alkalmazás, egy SDK), az ügyfelei csak akkor védettek, amikor eléri őket az Ön frissítése. Adja ki, és közölje az ügyfelekkel, mely verziók javítottak. A Mozilla tanácsa a tanúsítványtárak üzemeltetőinek: tiltsák le a nyolc köztes CA-t, ha a szoftverük képes rá, ellenkező esetben pedig „fontolják meg, hogy megfelelő-e megvonni a bizalmat azoktól a gyökértanúsítványoktól, amelyek ezeket a köztes CA-kat aláírták”.

A kiberrezilienciáról szóló rendelet kétféleképpen is érinti ezt. A 2026. szeptember 11. óta alkalmazandó bejelentési kötelezettsége az aktívan kihasznált sebezhetőségekre vonatkozik, ebben az esetben pedig nem jelentettek kihasználást. A 2027. december 11-től alkalmazandó alapvető követelményei között szerepel, hogy a sebezhetőségeket biztonsági frissítésekkel lehessen kezelni; az a termék, amelynek a megbízható tanúsítványokat tartalmazó listája nem frissíthető, nem felelne meg nekik. A NIS2-irányelv hatálya alá tartozó ügyfelek meg fogják kérdezni a beszállítóikat, milyen gyorsan kezelték ezt, és jól jön, ha a válasz írásban megvan.

Ami még nyitott

• Az eMudhra megmaradt gyökértanúsítványa. A Chrome október 21-én tizenkét kérdést tett fel az eMudhrának, és az emSign Root CA - G1 ügyében nem jelentett be döntést. A Mozilla „jelenleg” nem távolítja el.
• Az eMudhra átállási útvonala. A Mozillának azt mondta, hogy az ügyfeleit a G1 (RSA) hierarchiájába költözteti; az állapotoldala „egy alternatív, függetlenül üzemeltetett, nyilvánosan megbízható CA-hierarchiáról” beszél. A Chrome megkérdezte, melyikről.
• A Microsoft és az Apple. Egyikük sem adott ki nyilatkozatot, és egyikük sem távolította el egyik gyökértanúsítványt sem a tanúsítványtárából.
• Függőben lévő javítások. A Red Hat, az Amazon Linux, a Temurin és a Corretto október 22-ig semmit nem adott ki; a Bun javítását beolvasztották, de nem adták ki.
• A kiváltó ok. Az eMudhra nem erősítette meg, és közölte, hogy minden eddigi kulcsgenerálási ceremóniáját újra ellenőrzi.
• A Sectigo. Egy külön, szeptember 5. óta nyitott ügyben a Sectigo megtagadta azoknak a tanúsítványoknak a visszavonását, amelyeknek a kiterjesztett kulcshasználata (extended key usage) nem egyezett a CPS-e egyik mondatával, arra hivatkozva, hogy a mondat nem egyértelmű. Október 18-án körülbelül 72 millió ilyen, még aktív tanúsítványt számolt. A nyilvános vitában egyes résztvevők a bizalom megvonását sürgették; egyik gyökértanúsítvány-program (root program) sem jelentett be döntést. A Sectigo-tanúsítványokat használó cégeknek érdemes követniük az ügyet.

Hol kaphat segítséget

Egy tanúsítványprobléma ritkán mutatkozik be tanúsítványproblémaként. Úgy jelentkezik, hogy nem töltődik be a fizetési oldal, leáll egy integráció szinkronizálása, vagy egy eszköz nem küld több jelentést, általában hétvégén. Segítünk a cégeknek kiesés nélkül átvészelni az ilyen heteket, és úgy beállítani a rendszereiket, hogy a következő alkalom rutinfeladat legyen:

• Kitettségvizsgálat. Feltérképezzük, hol kezdeményeznek vagy fogadnak TLS-kapcsolatokat a rendszerei, melyik tanúsítványtárat használja mindegyik, és milyen tanúsítványokat szolgál ki, a konténereket, a Java-szolgáltatásokat, a bankokkal, fizetési és logisztikai szolgáltatókkal való integrációkat és az eszközöket is beleértve.
• A javítások. Frissítések, újraépített image-ek, letiltott kulcsok vagy lecserélt tanúsítványok, az Ön változáskezelési folyamatán keresztül elvégezve és a Mozilla tesztszerverein ellenőrizve.
• Automatizálás 2027-re. ACME és ARI a szervereken, a terheléselosztókon és az appliance-eken, egy második hitelesítésszolgáltató, CAA-rekordok, CT-figyelés és egy runbook, felkészülve a 2027. március 15-től érvényes 100 napos tanúsítványokra.
• A rendszerek, amelyekhez senki nem akar hozzányúlni. A régi Java-alkalmazások, az appliance-ek és a saját tanúsítványtárral rendelkező beágyazott kliensek pontosan azok, amelyekre a régi rendszerek karbantartására vonatkozó szolgáltatásunk szolgál.

Ha nem biztos benne, hogy érinti-e az ügy, írjon az office@c9group.dev címre, és adja meg a domainjeit és a használt platformokat, vagy foglaljon egy hívást. Megmondjuk, mit érdemes először ellenőriznie.