---
title: "eMudhra: een geheime HTTPS-sleutel was 4"
date: 2026-10-21
author: "Redactie Humanfirewall"
featured_image: "https://humanfirewall.nl/wp-content/uploads/2026/10/emudhra-zwakke-sleutels.jpg"
categories:
  - name: "Beveiligingsnieuws"
    url: "/category/beveiligingsnieuws.md"
---

# eMudhra: een geheime HTTPS-sleutel was 4

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.



![Vergelijking tussen een groot P-384-geheim en het getal 4](https://humanfirewall.nl/wp-content/uploads/2026/10/HVGkVqQXgAEc9y7.jpg)Beeld: IntCyberDigest, 20 oktober 2026. Het getal 4 klopt met ons eerdere certificaatbewijs. De genoemde 116 cijfers zijn een orde van grootte, geen vaste lengte-eis voor iedere geldige P-384-sleutel.

## 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 2026UitkomstCertificaten in het eerdere bewijsbestand16Verschillende publieke sleutels8Sleutels voor HTTPS-certificaten6Sleutels voor codeondertekening2Grootste geheime getal in die groepKleiner dan 256Gecontroleerde overeenkomsten en tegenproeven16 correct, 16 verkeerde kandidaten afgewezenEigen hercontrole, 21 oktober 2026. Bestaand bewijs opnieuw nagerekend; geen nieuwe meting van misbruik.

## 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.



![Overzicht van de acht kleine geheime getallen bij de getroffen certificaatautoriteiten](https://humanfirewall.nl/wp-content/uploads/2026/10/HVGkU8CW4AAPCXv.jpg)Beeld: IntCyberDigest, 20 oktober 2026. Deze visualisatie laat kleine geheime getallen zien. Onze hercontrole bevestigt de publieke punten; de afbeelding zelf is geen bewijs van onderschept verkeer.

## 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.



**Volgens eMudhra**Gecertificeerde hardware en audits in twee opeenvolgende jaren.

**Nog niet verklaard**Welke controle de zwakke sleutels had moeten vinden.



Verklaring van het bedrijf, 21 oktober 2026. Onderzoek naar de precieze oorzaak loopt.

## 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](https://github.com/advisories/GHSA-6q48-6c7w-9gw2) 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](https://humanfirewall.nl/openbare-wifi-risico) hangt het risico af van de verbinding en de controles van het apparaat. Een [human firewall](https://humanfirewall.nl/) helpt mensen bedreigingen herkennen, maar kan een verouderde certificaatbundel niet met oplettendheid repareren.



**Je browser**Kan een blokkade via zijn eigen lijst ontvangen.

**Een script of container**Kan een andere certificaatbundel gebruiken.



De software die verbinding maakt bepaalt welke keten nog wordt vertrouwd.

## 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](https://humanfirewall.nl/clickfix-gedeelde-ai-chat-terminal).

Weet je niet welke apparaten of diensten nog verbindingen maken, begin dan met je [thuisnetwerk in kaart brengen](https://humanfirewall.nl/thuisnetwerk-in-kaart-brengen). Houd je browser en besturingssysteem bijgewerkt; laat onderzoek aan applicatiebundels bij de beheerder. Handmatig certificaten verwijderen is geen beginnersklus.



**Pakketversie**Uit de daadwerkelijk draaiende omgeving.

**Weigering**De getroffen certificaatketens worden afgewezen.

**Bereikbaarheid**De nieuwe, vertrouwde keten blijft werken.





## 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?



**17 oktober**Chrome en Firefox blokkeren de getroffen sleutels.

**21 oktober**Nieuwste bedrijfsverklaring en onze hercontrole.

**27 oktober**Google verwacht de bredere rootverwijdering uit te rollen.



Planning van Google; eerdere browserblokkades staan al los van deze stap.

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.