Firefox en Chrome hebben onlangs trust in eMudhra intermediate CA’s geblokkeerd na een incident met gecompromitteerde private keys. Het gevolg: een deel van de wereldwijde vertrouwensketen voor HTTPS is opnieuw bekeken, en sommige clients moeten mogelijk worden bijgewerkt om niet langer afhankelijk te zijn van certificaten die inmiddels zijn ingetrokken.
In dit artikel zetten we de feiten op een rij: wat er misging bij eMudhra, welke partijen blokkeerden of revokeerden, en hoe je snel kunt controleren of jouw omgeving nog vertrouwt op de getroffen certificaten.
Wat is er gebeurd met eMudhra intermediate CA’s?
eMudhra gaf in april 2025 acht intermediate certificaten uit. Later bleek dat de private keys bij deze intermediate certificaten gecompromitteerd zijn. Door de zwakke generatie van die sleutels konden aanvallers naar verwachting misbruik maken van de vertrouwenspositie van de certificaatketen.
Volgens de toelichting die Google publiceerde, is het risico vooral groot doordat de sleutels niet met voldoende cryptografische randomisatie tot stand kwamen. Dat verlaagt de drempel om frauduleuze certificaten te maken waarmee een aanvaller zich kan voordoen als elke website, mits de getroffen clients de tussen-CA’s nog vertrouwen.
Welke browsers en organisaties blokkeerden het?
Toen het bekend werd, namen grote trust ecosystemen het incident snel mee in hun blocklist en trust updates.
- 17 oktober: Mozilla en Google blokkeerden de certificaten in respectievelijk Firefox en Chrome.
- 19 oktober: Apple voegde blokkades toe.
- 20 oktober: Microsoft volgde met blokkering.
- Sectigo zette ook revocation-stappen in gang.
- Cloudflare paste maatregelen toe in zijn diensten.
eMudhra heeft de gecompromitteerde certificaten daarna ook ingetrokken (revoked) en de afhandeling gecommuniceerd richting downstream trust stores.
Waarom is dit risico zo groot?
Het kernpunt is dat intermediate CA’s in een certificaatketen meestal niet alleen vertrouwen krijgen voor één eindcertificaat, maar voor de mogelijkheid om verder te signeren. Wanneer de private keys van zo’n tussen-CA zwak of te reconstrueren zijn, kan dat aanvallers in staat stellen om certificaten te genereren die voldoen aan de voorwaarden die clients verwachten.
Mozilla’s Dennis Jackson gaf aan dat de private keys praktisch te reconstrueren waren. Hij beschreef dat de sleutels vrijwel uit nullen bestaan, met alleen een afwijking op het laatste byte. Daardoor kunnen ze snel worden teruggevonden met een discrete-log benadering (baby-step giant-step).
Er is volgens de beschikbare informatie geen bewijs gevonden in Certificate Transparency (CT) logs dat de sleutels vóór de revocation daadwerkelijk misbruikt zijn. Tegelijk geldt: niet elke client controleert CT, en threat actors hadden mogelijk al pogingen kunnen ondernemen die niet in die logs terug te zien zijn.
Hoe kan je controleren of je systeem nog vertrouwt?
Omdat blokkeren en revocation tijd nodig hebben om door te werken naar alle softwareversies, is een praktische check verstandig. Dennis Jackson heeft een tool gepubliceerd waarmee je kunt nagaan of jouw client of omgeving nog eMudhra intermediate CA’s vertrouwt.
Jackson waarschuwde bovendien dat meerdere personen de sleutels zelfstandig al hebben opgehaald. Dat maakt een snelle inventarisatie extra belangrijk: niet alleen servers en browsers, maar ook OS-versies, embedded devices en runtime’s die eigen trust stores gebruiken.
Als je tool aangeeft dat de getroffen certificaten nog worden vertrouwd, is het tijd om te kijken naar updates of het verwijderen/aanpassen van trust-informatie op die systemen.
Waarom ging de key generation mis bij eMudhra?
eMudhra beschrijft dat er meerdere menselijke en procesmatige fouten zijn geweest rond de key generation ceremony. Daarbij werd naar verluidt een script gebruikt dat per ongeluk een tweede, zwakkere key pair aanmaakte.
Deze extra key pair werd volgens de uitleg mogelijk gebruikt bij het maken van certificate signing requests, omdat labels ervan te veel leken op die van de oorspronkelijke keys. Het incident leidde tot problemen in de integriteit van de key lifecycle.
Daarnaast gaf eMudhra aan dat sommige onderdelen van de opzet bedoeld waren voor export naar datacenters in de VS en Europa vanwege datarotaties en data sovereignty. Die exportvariant is niet volledig operationeel in productie gekomen, behalve voor één geval. De belangrijkste boodschap blijft echter: er is een fout in de key ceremony en/of bij de maker-checker controles ontstaan die de beveiligingskwaliteit aantastte.
Wat moet je nu doen als organisatie?
Ook al zijn certificaten geblokkeerd en ingetrokken, kan je omgeving nog altijd oude trust bevatten. Daarom is het verstandig om een korte actie-lijst te volgen:
- Inventariseer welke systemen verbinding maken via TLS en welke versies/clients (browsers, OS, libraries) je gebruikt.
- Check trust op aanwezigheid van de getroffen eMudhra intermediate CA’s met de door Mozilla gepubliceerde controletool.
- Update clients waar nodig. Soms is dat een OS-update, soms een applicatie- of browserupdate, en in sommige omgevingen een update van embedded trust stores.
- Controleer monitoring rond certificate anomalies. Let vooral op situaties waarin certificaten afwijken van het verwachte issuer-pad.
Heb je teams die veel met TLS-terminatie of proxy’s werken? Betrek dan ook die laag, want vertrouwde CA-informatie kan ook daar doorsijpelen.
Vergelijkbare incidenten: waarom governance en supply chain ertoe doen
Incidenten rond certificaatketens laten zien dat vertrouwen in de digitale infrastructuur niet vanzelfsprekend is. Je ziet dit soort dreigingen terug in bredere patronen: zwak ontwerp, procesfouten, of supply chain-impact die uiteindelijk terugkomt in het eindresultaat—namelijk de mogelijkheid om systemen te misleiden.
Als je meer wilt lezen over het beveiligen van agent-gedreven of geautomatiseerde ketens, kan dit artikel helpen als achtergrond: AI-agent runtime security: Beacon en beleid. Ook bij certificate- en trust-incidenten geldt immers hetzelfde principe: maak het proces toetsbaar en zorg dat uitwijk- en blokkademechanismen goed landen in de praktijk.
Conclusie
De blokkades van Firefox, Chrome, Apple en Microsoft tegen gecompromitteerde eMudhra intermediate CA’s onderstrepen hoe belangrijk private key-integriteit is voor internetveiligheid. Hoewel er geen harde aanwijzing is gevonden dat de sleutels al massaal misbruikt zijn vóór de revocation, is de potentiële impact aanzienlijk: aanvallers konden in theorie vertrouwde HTTPS-certificaten maken.
Voor organisaties is nu vooral actie nodig: check of je omgeving de getroffen intermediate CA’s nog vertrouwt en update systemen waar dat nog zo is. Daarmee verminder je het risico dat een deel van je clients nog kwetsbaar is via verouderde trust stores.
Bron: https://www.securityweek.com/browsers-block-emudhra-intermediate-cas-over-recoverable-private-keys/
