eMudhra: een geheime HTTPS-sleutel was 4
eMudhra gebruikte voorspelbare sleutels voor certificaten. Onze hercontrole bevestigt acht zwakke sleutels. Een browserblokkade beschermt niet elk script.
eMudhra gebruikte het getal 4 als geheime sleutel van een certificaatautoriteit. Geen wachtwoord met vier cijfers: het getal vier. Een partij die moest bevestigen welke website je voor je hebt, gebruikte daarmee een sleutel die met een paar pogingen te vinden was.
Het gaat om acht zwakke sleutels voor tussenliggende certificaatautoriteiten. Daarmee kon een aanvaller zelf certificaten ondertekenen. Voor het onderscheppen van een verbinding moest hij daarnaast op het netwerkpad zitten én software treffen die deze autoriteiten nog vertrouwde. Een kwetsbare sleutel bewijst geen afgeluisterde verbinding.
Acht sleutels, zestien certificaten: onze controle
De eerdere eigen meting op Humanfirewall is op 21 oktober opnieuw nagerekend. Zestien openbare certificaten bevatten acht verschillende publieke sleutels. Elke sleutel komt tweemaal voor doordat twee uitgevers dezelfde sleutel hebben ondertekend. Het aantal certificaten is dus niet het aantal afzonderlijke geheimen.
Voor elk opgeslagen resultaat hebben we het publieke punt opnieuw berekend en vergeleken met het eerdere certificaatbewijs. Alle zestien vergelijkingen klopten. Een bewust verkeerde kandidaat gaf telkens geen overeenkomst. Dat bevestigt de eerdere meting; het is geen nieuwe meting van misbruik.
Alle acht geheime getallen pasten dus in acht bits. De gebruikte cryptografie heet P-384. Die naam maakt een verkeerd gekozen geheim niet sterker. Het getal 4 uit de afbeelding komt overeen met de publieke sleutel van EM OV TLS CA – G3C in het bewijsbestand.
| Eigen hercontrole, 21 oktober 2026 | Uitkomst |
|---|---|
| Certificaten in het eerdere bewijsbestand | 16 |
| Verschillende publieke sleutels | 8 |
| Sleutels voor HTTPS-certificaten | 6 |
| Sleutels voor codeondertekening | 2 |
| Grootste geheime getal in die groep | Kleiner dan 256 |
| Gecontroleerde overeenkomsten en tegenproeven | 16 correct, 16 verkeerde kandidaten afgewezen |
Hoe maakt beveiligde hardware zulke zwakke sleutels?
Volgens eMudhra ontstond de fout tijdens een sleutelceremonie op 30 april 2025. Daarbij gebruikte het bedrijf hardwaremodules met FIPS 140-2 Level 3-certificering. Een stap voor het verpakken en terughalen van sleutels, wrap/unwrap, leverde volgens de verklaring van 21 oktober naast sterke sleutels een tweede, zwakke set op.
De certificaten met die zwakke sleutels kwamen in de vertrouwensketen terecht. Hoe de fout precies kon ontstaan, wordt nog onderzocht. De verklaring is wederhoor van het bedrijf, geen afgerond onafhankelijk onderzoek.
Mozilla beschrijft in zijn openbare incidentdossier dat alle acht geheime getallen kleiner waren dan 256. De fout zat bij het maken van de sleutels. Dit incident toont geen doorbraak waarmee goed gemaakte P-384-sleutels opeens te kraken zijn. RSA is bovendien een ander cryptografisch systeem.
Een audit is geen bewijs dat de sleutel deugt
eMudhra schrijft dat de betrokken infrastructuur in twee opeenvolgende jaren onafhankelijke audits doorliep. Dat maakt de vraag scherper: welke controle had deze zwakte moeten vinden, en waarom gebeurde dat niet? Die verklaring ontbreekt nog.
Een gecertificeerde hardwaremodule kan onderdeel zijn van een proces dat verkeerd uitpakt. Wie uitsluitend naar het certificeringslabel kijkt, mist het resultaat dat gecontroleerd moest worden. Hier waren dat de daadwerkelijk gebruikte sleutels.
Tegelijk gaat de conclusie dat het hele HTTPS-systeem waardeloos is veel te ver. Mozilla en Google blokkeerden de getroffen sleutels snel. Bij Firefox met standaardinstellingen bereikte de OneCRL-blokkade iedereen volgens Mozilla op 17 oktober om 22.59 UTC, 2 uur en 53 minuten na ontvangst van het rapport. Daarvoor hoefde Firefox niet opnieuw op te starten.
Waarom kan je browser beschermd zijn en je script niet?
Een browser kan een blokkadelijst bijwerken. Een Python-script of container kan ondertussen een eigen, oudere certificaatbundel gebruiken. Die ontvangt de browserblokkade niet vanzelf. Daarom vraagt dit incident ook aandacht voor software die op de achtergrond verbindingen maakt.
De beveiligingsmelding voor het Python-pakket certifi adviseert versie 2026.10.19 of nieuwer. Containers die een oude versie meeleveren moeten opnieuw worden gebouwd. Alleen iets op de host bijwerken zegt niet welke bundel het proces ín die container gebruikt.
Google meldt dat vóór zijn blokkade geen TLS-certificaten onder de zes getroffen HTTPS-autoriteiten in Certificate Transparency waren gelogd. Die registratieplicht beschermde clients die haar afdwingen. Voor software zonder die controle is dat geen sluitend bewijs van bescherming.
Ook bij openbare wifi hangt het risico af van de verbinding en de controles van het apparaat. Een human firewall helpt mensen bedreigingen herkennen, maar kan een verouderde certificaatbundel niet met oplettendheid repareren.
Welke vraag moet je beheerder vandaag beantwoorden?
Vraag welke certificaatbundel je applicatie werkelijk gebruikt en of de getroffen ketens worden geweigerd. Vraag om de pakketversie en de uitkomst van die controle vanuit de draaiende applicatie. Een bijgewerkte browser op de laptop van de beheerder is daarvoor geen bewijs.
Laat updates via de officiële beheerroute uitvoeren. Schakel certificaatcontrole niet uit om foutmeldingen weg te krijgen. Losse terminalcommando’s uit advertenties of gedeelde chats geven juist een extra risico, zoals bij ClickFix via gedeelde AI-chats.
Weet je niet welke apparaten of diensten nog verbindingen maken, begin dan met je thuisnetwerk in kaart brengen. Houd je browser en besturingssysteem bijgewerkt; laat onderzoek aan applicatiebundels bij de beheerder. Handmatig certificaten verwijderen is geen beginnersklus.
Op 27 oktober moet ook de vervangende keten werken
Google verwacht de bredere verwijdering van emSign ECC Root CA – G3 op 27 oktober 2026 in de Chrome Root Store uit te rollen, eerder in testversies. De eerdere blokkade van de zwakke sleutels is al actief. Websites met een keten naar deze root moeten volgens Google een andere vertrouwde certificaatketen installeren.
De controle heeft twee kanten: de getroffen keten moet worden geweigerd en de vervangende verbinding moet werken. Daarna blijft de onderzoeksvraag aan eMudhra staan: hoe kwamen zulke kleine geheimen door het eigen proces en de audits heen?
Bronnen: Mozilla Security Blog en Google Security Blog, 20 oktober 2026; openbaar incidentdossier Mozilla; eMudhra, verklaring van 21 oktober 2026; beveiligingsadvies certifi, 20 oktober 2026; eigen bewijscontrole, 21 oktober 2026.