Op 20 oktober bevestigden Mozilla en het Chrome Root Program dat de eMudhra CA-keys gecompromitteerd zijn. Het gaat om private sleutels van acht intermediate certificaatautoriteiten (CA’s). Omdat intermediates certificaten ondertekenen die browsers kunnen accepteren, was er direct reden om noodmaatregelen te activeren.
In korte tijd blokkeerden Chrome en Firefox de betrokken certificaten. Ook Go publiceerde een fix op het strengste niveau, bedoeld voor bedreigingen die de integriteit van het ecosysteem kunnen raken.
Waarom CA-keys zoveel invloed hebben
Een intermediate CA is onderdeel van de certificaatketen die een website aan een browser toont tijdens een TLS-verbinding. De intermediate CA ondertekent die certificaten. Als iemand de private sleutel van zo’n intermediate bezit, kan die partij in theorie certificaten uitgeven voor websites die browsers normaal vertrouwen.
Dat maakt een compromis van CA-sleutels anders dan een “gewone” bug in een applicatie. Het raakt niet één dienst, maar het vertrouwensmodel dat veel software gebruikt om verbindingen veilig te houden.
Wat er precies gecompromitteerd is
Volgens de bevestigingen en details in de melding zijn de volgende acht intermediate CA-certificaten betroffen. Ze vallen uiteen in TLS-certificaten (domain validated, organization validated en extended validation) en code signing certificaten:
- TLS domain validated: EM DV TLS CA – G3B (eMudhra BV, Nederland) en EM DV TLS CA – G3C (eMudhra Inc, VS)
- TLS organization validated: EM OV TLS CA – G3B en EM OV TLS CA – G3C
- TLS extended validation: EM EV TLS CA – G3B en EM EV TLS CA – G3C
- Code signing: EM OV CS CA – G3B en EM OV CS CA – G3C
Daarnaast bestonden er voor elk van deze acht certificaten ook cross-signed varianten met dezelfde publieke sleutel, via Sectigo’s AAA Certificate Services root. Die kopieën zijn relevant omdat sommige systemen vertrouwen op basis van root-implementaties en ketenopbouw.
Belangrijk detail: niet alles was vooraf zichtbaar
Chrome Root Program gaf aan dat er geen TLS certificate chaining voor de zes web-gerelateerde intermediates was gelogd in Certificate Transparency (CT) vóór de blokkade. CT is bedoeld als zichtbaarheid: als certificaten correct worden ingeschreven, wordt misbruik sneller detecteerbaar.
Omdat de betrokken certificaatketens niet eerder gelogd waren, konden ze in de praktijk niet “standaard” vertrouwd worden in Chrome en andere omgevingen die CT-logging vereisen.
Wie maakte de melding, en hoe snel volgden blokkades?
Een onderzoeker rapporteerde het probleem op de avond van 17 oktober. Chrome ontving de melding om 18:05 UTC en zette binnen enkele uren een blokkade in via een CRLSet-update (om 19:45 UTC). Firefox kreeg de melding later, rond 20:06 UTC, en duwde vervolgens een OneCRL-block uit naar installaties met standaardinstellingen om 22:59 UTC.
De snelheid is relevant: in dit type scenario wil je voorkomen dat een aangepaste certificaatketen op grote schaal geaccepteerd wordt, voordat leveranciers de trust-basis aanpassen.
Hoe Chrome en Firefox het vertrouwen intrekken
Chrome’s blokkade is opgezet op basis van de public key in plaats van alleen het certificate object. Daardoor pakt de maatregel niet alleen de directe intermediates, maar ook de Sectigo cross-gesigneerde kopieën.
Firefox volgt met een revocation-aanpak. Beide browsers stopten bovendien eerder al met het vertrouwen op de AAA Certificate Services root voor websites in hun respectieve trustmechanismen, en in Chrome is de root-store configuratie aangepast.
Volgens de betrokken partijen vergrootte het bestaan van de cross-signed varianten de blootstelling in Chrome en Firefox niet verder dan waar de primaire blokkade al tegen beschermt.
Go bracht een noodfix uit (en waarom dat telt)
De melding bevat ook een technische reactie van Go. Go blokkeerde de betrokken keys in een urgent release-track. Die urgent track is bedoeld voor situaties die de integriteit van het ecosysteem bedreigen of als er misbruik in het wild wordt gezien.
Voor Go betekent dit concreet dat de standaard TLS-validatieketen wordt gefilterd: ketens die één van de acht gecompromitteerde intermediate sleutels bevatten, worden afgewezen.
Als je Go-toepassingen draait, is dit extra belangrijk omdat veel systemen TLS-verificatie afhandelen via de Go-standaardbibliotheek. Daarbij geldt ook: oudere Go-versies buiten support vallen niet onder deze fixes.
Wat betekent dit voor organisaties en trust stores?
Een kernpunt uit de adviezen: niet alle software controleert revocation-informatie op dezelfde manier. Sommige bibliotheken of runtime-omgevingen vertrouwen jarenlang op een keten zolang die “logisch” is binnen hun root bundle, zonder te verifiëren of een intermediate daadwerkelijk is ingetrokken.
Mozilla adviseert trust store operators om te kijken naar hun huidige clientgedrag:
- Als clients betrouwbare revocation checks uitvoeren en verbindingen weigeren wanneer revocation niet kan worden vastgesteld, is er in sommige gevallen “niets extra nodig”.
- Als dat niet zo is, moeten operators mogelijk individuele intermediates kunnen blokkeren, of zelfs vertrouwen in de roots die de intermediate ondertekenden verwijderen.
Daarbij waarschuwt Mozilla ook voor praktische impact: als je een root uit trust bundles haalt, worden ook legitieme certificaten die via die root ketenen onbereikbaar voor niet-Firefox gebruikers totdat servers nieuwe ketens gebruiken.
Welke fixes zijn er al gepubliceerd?
Er zijn meerdere sporen tegelijk zichtbaar. Sommige richten zich op blokkeren op key-niveau, andere halen roots uit trust bundles:
Go: filter in de standaardverificatie
Go’s fix werkt via een interne filter die ketens afwijst waar een van de acht keys in voorkomt. Deze wijziging komt alleen beschikbaar via een herbouw op basis van de nieuwe Go release. Go 1.25 en oudere versies ontvangen geen extra updates.
Trust bundles: roots verwijderen in plaats van alleen blokkeren
Verder zijn er updates aangekondigd of doorgevoerd in systemen die wortel-CA’s onderhouden in een bundel. In de melding gaat het onder meer om:
- certifi
- webpki-roots
- Homebrew ca-certificates
In die aanpak worden relevante roots uit de bundel gehaald. Concreet wordt genoemd dat emSign ECC Root CA – G3 wordt verwijderd. Homebrew laat in dezelfde lijn ook Sectigo’s AAA Certificate Services root en emSign Root TLS CA – G3 vallen.
Firefox: geen directe handeling voor de meeste setups
Firefox heeft volgens Mozilla geen extra actie nodig voor standaardinstallaties, tenzij remote settings door beleid is uitgeschakeld of in de netwerkroute geblokkeerd. Voor de standaarduitrol zaten de blocklists al in de releases van 20 oktober.
Kun je misbruik achteraf detecteren?
Een lastige vraag is: “Hoe weten we of de keys eerder misbruikt zijn tegen onze omgeving?” De melding stelt dat er geen directe detectiemethode bestaat voor misbruik buiten wat Chrome’s CT-zoekfunctie kan vinden. Certificate Transparency dekt namelijk alleen certificaatketens die gelogd zijn.
Praktisch betekent dit: je kunt vooral vertrouwen op de blokkades en op het vervangen van trustconfiguraties in je eigen software-stack, en daarnaast logbestanden en certificaatketenwissels bekijken waar dat mogelijk is.
Wat gebeurt er met eMudhra in de trustketen?
De broninformatie meldt dat eMudhra de acht certificaten intussen heeft ingetrokken (revoked). Ook Apple en Microsoft hebben de betrokken intermediates op respectievelijk 19 en 20 oktober geblokkeerd.
Mozilla heeft bovendien emSign ECC Root CA – G3 uit NSS verwijderd op 20 oktober. Chrome geeft aan dat het dezelfde root later in zijn root store zal verwijderen en onderzoekt ook de status van een andere eMudhra root in zijn store (emSign Root CA – G1), mede vanwege de ernst van het incident.
Checklist: wat je nu kunt doen
Als je TLS gebruikt in toepassingen, API’s of interne portals, is dit een moment om je aanpak te controleren. Een korte, praktische checklist:
- Werk browsers en runtime-omgevingen bij die trust-bundles en certificaatvalidatie bevatten (zeker als je Go, Python-bibliotheken of systemen met certifi draait).
- Controleer welke clients revocation-gegevens wel of niet gebruiken. Als revocation niet betrouwbaar wordt toegepast, kan het nodig zijn om trust anchors te herzien.
- Laat services certificaatketens vernieuwen wanneer je provider of interne PKI laat weten dat chains niet langer via de oude routes moeten worden aangeboden.
- Bekijk compatibiliteit: verwijder je roots uit een bundel, dan kan dit tijdelijk leiden tot “niet beschikbaar” situaties voor sommige gebruikers, afhankelijk van hun browser of trustmodel.
Wil je breder inzicht in hoe CA-issues en certificaatvertrouwen zich vertalen naar incidentrespons? Lees dan ook: (algemeen) incidentrespons aanpak—of, specifieker voor incidentstappen rondom high-impact IT-issues: incidentrespons in 5 stappen bij rogue AI-agents.
Conclusie
De compromis van de eMudhra CA-keys laat zien hoe snel veranderingen in het digitale vertrouwensmodel doorwerken. Waar CT en snelle revocation-distributie helpen, moeten organisaties met eigen trust stores en runtime-omgevingen extra letten op updates en verificatiegedrag.
De kernboodschap: update waar mogelijk, vervang certificaatketens indien nodig en controleer of je software revocation werkelijk gebruikt. Zo verklein je de kans dat clients certificaten accepteren die niet meer als betrouwbaar horen te gelden.
Bron: https://thehackernews.com/2026/10/eight-emudhra-ca-keys-compromised.html
