eMudhra: gelekte CA-sleutels, wat je nu moet doen
Bijgewerkt: 22 oktober 2026
Kort antwoord: bij acht tussencertificaten van de Indiase certificaatautoriteit eMudhra was de geheime sleutel terug te rekenen. Wie die sleutel heeft, kan voor elk domein een certificaat maken. Browsers blokkeren deze certificaten al. Het risico zit in software met een eigen of verouderde lijst van vertrouwde uitgevers. Daarnaast verdwijnt emSign ECC Root CA - G3 uit de browsers, en certificaten daaronder werken binnenkort niet meer. Controleer je eigen certificaten en werk de lijst van vertrouwde uitgevers bij in software die zelf certificaten controleert.
Wat er is gebeurd
Op 17 oktober 2026 meldde een onderzoeker dat de privésleutels van acht tussencertificaten van eMudhra terug te rekenen waren. eMudhra had ze op 30 april 2025 aangemaakt, zonder de willekeur die een sleutel onraadbaar maakt. Zes zijn bedoeld voor TLS-certificaten van websites en servers, twee voor het ondertekenen van software. Alle acht waren ook door Sectigo kruisgecertificeerd, en daardoor werden ze breed vertrouwd.
- Binnen enkele uren blokkeerden Chrome en Firefox de acht tussencertificaten, zonder dat gebruikers iets hoefden bij te werken.
- Op 18 en 19 oktober trokken eMudhra en Sectigo de certificaten in, en volgde Apple.
- Op 20 oktober volgde Microsoft, en haalde Mozilla emSign ECC Root CA - G3 uit Firefox.
- Chrome haalt diezelfde root rond 27 oktober 2026 weg.
Onderzoekers hebben met de gelekte sleutels inmiddels meer dan 100.000 demonstratiecertificaten gemaakt en in de openbare certificaatlogboeken gezet. eMudhra zegt dat onder de acht geen echte klantcertificaten zijn uitgegeven.
Wat het voor jou betekent
Er zijn drie vragen, en ze vragen elk iets anders van je.
- Gebruikt een van je servers een certificaat van een van de acht? Dan werkt het al niet meer in browsers, en moet het vandaag vervangen worden door een certificaat van een andere uitgever.
- Gebruikt een van je servers een certificaat onder emSign ECC Root CA - G3? Die root is niet gelekt, maar Firefox vertrouwt hem al niet meer en Chrome volgt rond 27 oktober. Vervang zo'n certificaat vóór die datum, anders krijgen bezoekers een waarschuwing in plaats van je site.
- Vertrouwt je eigen software de gelekte uitgevers nog? Dit is het echte beveiligingsrisico. Met een nagemaakt certificaat kan iemand zich tegenover je software voordoen als een server die dat niet is, bijvoorbeeld om verkeer mee te lezen. Browsers zijn al beschermd. Software die zijn eigen lijst meebrengt of ingetrokken certificaten niet controleert, is dat niet vanzelf.
Wat je zelf moet controleren
Loop software na die zelf bepaalt welke uitgevers ze vertrouwt, en werk die lijst bij. Denk aan:
- Besturingssystemen en hun CA-pakket, ook in containers en virtuele machines.
- Java (cacerts), Python (certifi), Node.js en andere programmeeromgevingen met een eigen lijst.
- Programma's in Go: versie 1.27.3 en 1.26.10 en hoger weigeren een keten met een van de acht sleutels.
- VPN-clients, proxies, loadbalancers en gateways.
- Buildstraten (CI/CD) en apparaten met ingebouwde software, zoals IoT.
Test daarbij het echte pad: dat je browser of je laptop een nagemaakt certificaat weigert, zegt niets over de software die in productie verbinding maakt.
Wat Exposure Watch controleert
Twee van de drie vragen zijn van buitenaf te beantwoorden, en die nemen we mee in elke scan, ook in de gratis scan op de voorpagina:
- De certificaatlogboeken. Voor elk certificaat dat voor je domein is uitgegeven, kijken we met welke sleutel het is ondertekend. Staat er een certificaat van een van de acht gelekte sleutels voor je domein, dan melden we dat als hoog risico. Een geldig certificaat onder emSign ECC Root CA - G3 melden we ook, zodat je het op tijd vervangt.
- De certificaten die je servers laten zien. Voor elk systeem bekijken we de keten van certificaten die het meestuurt. De passieve scan doet dat uit openbare internetscan-archieven, de actieve scan stelt het zelf vast bij je servers.
We kijken op de sleutel zelf, niet alleen op de naam van de uitgever. Daardoor vangen we ook een nagemaakt certificaat dat een andere naam draagt. Andere certificaten van eMudhra, die niets met dit incident te maken hebben, melden we niet.
De derde vraag, welke uitgevers je eigen software vertrouwt, kunnen we van buitenaf niet zien. Dat zit binnen in je organisatie, en daarvoor is de lijst hierboven.
Welke tussencertificaten het zijn
| Naam | Gebruik |
|---|---|
| EM DV TLS CA - G3B en - G3C | TLS (domeinvalidatie) |
| EM OV TLS CA - G3B en - G3C | TLS (organisatievalidatie) |
| EM EV TLS CA - G3B en - G3C | TLS (uitgebreide validatie) |
| EM OV CS CA - G3B en - G3C | Software ondertekenen |
Een certificaat dat door software is ondertekend met een van de twee laatste, staat niet in de certificaatlogboeken. Wat daarmee is ondertekend, is van buitenaf dus niet na te gaan.
Weten of jouw domein geraakt is?
Start de gratis scan op de voorpagina. Die bekijkt de certificaatlogboeken en de certificaten van je systemen, zonder iets naar je servers te sturen.
Bronnen
- Cisco Talos: Compromised eMudhra intermediate certificates
- Red Sift: eMudhra CA key compromise, what it means for you