EMudhra stopt certificaattak na blunder met zwakke private keys

EMudhra stopt helemaal met zijn TLS-certificaatuitgaven. Dat gebeurt nadat het bedrijf eerder deze week certificaten bleek uit te geven waarvan de cryptografische sleutels eenvoudig te achterhalen waren. Volgens eMudhra werden die certificaten niet in de praktijk gebruikt, maar het bedrijf vindt dat het door dat geschade vertrouwen niet meer door kan gaan.

Dat schrijft het bedrijf in een persbericht. De raad van bestuur van het Indiase bedrijf heeft besloten dat eMudhra zich volledig terugtrekt uit de markt van SSL- en TLS-certificaten. Dat gebeurde via dochterbedrijf emSign. Het bedrijf gaat nog wel met zijn andere activiteiten door, zoals het uitgeven van certificaten voor het ondertekenen van documenten en voor identiteitsmanagement. De SSL-tak gaf certificaten voor websites uit en daar stopt eMudhra nu mee.

Die tak was overigens maar klein, zegt eMudhra. Het ging maar om ongeveer een procent van de omzet. Het bedrijf had ook weinig keuze; door het recente nieuws verloren veel klanten hun vertrouwen en daalde de beurswaarde flink.

Zwakke certificaten

Dat nieuws draaide om acht intermediate certificaten waarvan eerder deze week bleek dat ze waren gecompromitteerd. Een beveiligingsonderzoeker zette een website op en ondertekende een tekstbericht met dezelfde keys als die certificaten hadden. Het ging in zes gevallen om SSL/TLS-certificaten, waarmee aanvallers zich als websites konden voordoen of verkeer konden afluisteren.

Dat lijkt door eMudhra's eigen schuld te komen. Het bedrijf gebruikte private keys die bestonden uit slechts een, twee of hooguit drie cijfers.

Het bedrijf schrijft in een postmortem dat het de certificaten inmiddels heeft ingetrokken. Ook merkt eMudhra op dat zeven van de acht certificaten nooit in productie zijn genomen. Het enige intermediate certificaat dat wél in productie kwam nooit een certificaat heeft uitgegeven. Overigens zegt eMudhra dat stellig, maar zoals een tweaker inmiddels ook opmerkt, is dat niet zo zeker. Het bedrijf weet hooguit dat het zelf geen certificaat heeft uitgegeven.

Het bedrijf vindt de aandacht zelf overtrokken. "Het niveau waarop het incident op sociale media werd uitvergroot, heeft onze SSL/TLS-tak onder een buitenproportioneel vergrootglas gelegd". Daarmee verklaart het bedrijf waarom het bestuur die tak heeft stopgezet.

Reacties (19)

[ApexAlpha]

Dat lijkt door eMudhra's eigen schuld te komen. Het bedrijf gebruikte private keys die bestonden uit slechts een, twee of hooguit drie cijfers.

Hun hoogste intermediate cert was het getal 4.... Niet 4 bytes, of 4 bits. Of 4 regels.

Het getal 4, was de totale private key.

Die zit in elke trust store, dus tot je update kan iedereen doen alsof ze elk domain zijn. Google.com Rijksoverheid.nl Tweakers.net

Het is echt een bizarre constatering en volledig terecht dat ze de business sluiten. De rest van hun business is ook allemaal "trust" gerelateerd en ik zou zeer sterk onderzoek doen als ik een van die producten zou afnemen.

Het werd overschaduwd door het Php gebeuren maar het is echt bizar ja. Hier meer info op Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c30

Alsof we nu erachter komen dat het getal "4" werkt voor elke pinpas van ING of zo... Vertrouwen is totaal, maar dan ook totaal weg.

[Reactie gewijzigd door ApexAlpha op 23 oktober 2026 14:11]

[Scribe]

256-bit encryptie is toch een willekeurig getal tussen 0 en 256?

[Stetsed]

Dus hier will ik well even wat context voor geven. Het probleem was nooit dat het valide certificaten waren. Technisch gezien is 4 inderdaad een valide nummer voor de ECC certificaten die zij gebruiken. Dus met die eerste had het KUNNEN zijn dat ze gewoon zo ongelukkig waren dat ze dat nummer raakte. Maar het was niet alleen 4, het was een hele reeks aan nummers onder de 255, dus 1 byte. Dit gaf aan dat het niet een enkel echt onlukkige situatie was, maar een structurele fout.

Daarom duurde het ook zo lang voordat het is gemerkt, omdat ze certificate die hij uitspuugt gewoon normaal lijkt zonder problemen. Maar fundamenteel hadden ze dit intern moeten merken en had dit nooit moeten kunnen gebeuren. Even gluren en het lijkt mogelijk dat er meer requirements rond om entropy/length testing zal komen voor keys in de certificate stores, maar wat we hier precies in zullen krijgen zullen we nog moeten zien.

[Reactie gewijzigd door Stetsed op 23 oktober 2026 14:16]

[Capsman]

nee, dat zijn maar 8 bits.


256-bits zijn getallen tussen 0 en115792089237316195423570985008687907853269984665640564039457584007913129639935

[Chris van der G]

Ook dan is 4 een geldig willekeurig getal tussen 0 en 115792089237316195423570985008687907853269984665640564039457584007913129639935

Niet veilig, wel geldig!

[Rannasha]

Ze hebben deze private key gewoon gegenereerd met een degelijke random number generator: https://xkcd.com/221/

[Blokker_1999]

Het is uiteraard bizar, maar de belangrijkste vraag is natuurlijk hoe dit is kunnen gebeuren. Dit schrijven ze er zelf over:

These issuing CAs were created under eMudhra’s ECC root in a Key Generation Ceremony (KGC) held on April 30, 2025, using FIPS 140-2 Level 3 Hardware Security Modules (HSMs).

A flaw in the KGC caused a wrap/unwrap step to produce a second set of weak keys alongside the original strong keys. The weak keys were the ones published to the browser root stores. eMudhra is working to establish the root cause.

Dan moet je je dus afvragen hoe dat dit is kunnen misgaan, waarom er een tweede keypair gegeneerd werd en hoet het kan dat dat foutieve paar uiteindelijk het productiepaar is geworden zonder dat iemand het opmerkte.

Alsook zeer benieuwd hoe AI dit heeft kunnen ontdekken, want het lijkt me niet dat je dit even gaat bruteforcen.

[Stetsed]

Ik denk dat de redenering gewoon om het even bot te zeggen: BS is. De post neemt weinig verantwoordelijkheid, het speelt hoe erg dit is echt heel erg omlaag. Dat nu ze revoked zijn er helemaal geen probleem is, terwijl dat het nog zeker is en dat overal nu updates moeten worden gedaan voor embedded trust stores.

Eerlijk gezegd had ik all eerder gezegd dat dit zoiezo all zou gebeuren, ik had niet verwacht dat zij dit zelf zouden doen. Maar na een fout van deze schaal was het bijna een garantie dat bij de volgende meeting van het Certificate Authority/Browser forum(CAB), dat zij direct eruit zouden worden gegooid. Dit was een fout op zo’n fundamentele en gigantische schaal dat er geen kans was dat ze er nog in zouden blijven.

Ze proberen te onderspelen hoe grote fout dit was, fundamenteel weet ik niet hoe er ook maar iemand is die hun andere business units zou vertrouwen. Dit is een fout die een bedrijf die gebaseerd is op vertrouwen, en dat zijn hun andere business ook, gewoon zou zinken in meeste situaties.

Om het even kort te zeggen: Dit is heel duidelijk een marketing/disaster recovery post, daarom zeggen ze ook hoe weinig van hun winst hier uit komt etc. Het was all bijna gegarandeerd dat ze eruit zouden worden gehaald alleen hebben ze het nu zelf gedaan inplaats van de CAB

—-

“Volgens eMudhra werden die certificaten niet in de praktijk gebruikt, maar het bedrijf vindt dat het door dat geschade vertrouwen niet meer door kan gaan.”

En hier hebben ze MISSCHIEN, gelijk in. Er zijn geen certificates in de CT log die hier vanuit komen dus het kan zeker zijn dat deze certs niet werden gebruikt. Het probleem is dat hij zit in elke root trust store die er was. En voor de mensen die niet weten wat ik daarmee bedoel, de root trust store is een lijst aan certificaten die bepaalde bedrijven managen, de grootste zijn Google’s, Mozilla’s, Apple’s, Microsoft’s. En vanaf die worden degene die 99% van devices gebruiken gebouwd.

Dit betekent dat het niet uitmaakt of het een certificate die overall gebruikt werdt was of eentje die nergens gebruikt werdt. Fundamenteel is de schade nog steeds gigantisch, het enige wat net minder is is dat er minder sites zijn die hun certs opnieuw moeten doen.

[Reactie gewijzigd door Stetsed op 23 oktober 2026 14:22]

[ApexAlpha]

Ze proberen de rest van hun bedrijf te beschermen tegen de fallout.

Alle producten die ze leveren hebben een vertrouwelijk karakter. PKI services, inlogcertificaten etc...

De backlash is uiteraard gigantisch, vooral in India.

[elmuerte]

Er zijn geen certificates in de CT log die hier vanuit komen dus het kan zeker zijn dat deze certs niet werden gebruikt

Als ik de private key heb van een CA, waarom zou ik de certificaten die ik maak dan publiceren in de CT log?

[UnanyMoose]

Het bedrijf vindt de aandacht zelf overtrokken. "Het niveau waarop het incident op sociale media werd uitvergroot, heeft onze SSL/TLS-tak onder een buitenproportioneel vergrootglas gelegd".

Het was te verwachten dat de certificaattak eraan ten onder zou gaan, het hele principe van een certificaat authoriteit is dat je ze kan vertrouwen. Als je daar zo onverantwoord en onprofessioneel mee omgaat is dat niet opeens de schuld van anderen.

[Keypunchie]

Sowieso is SSL/TLS als een razende gaan consolideren sinds Let's Encrypt. Dus dat ze er mee stoppen is geen gekke zet.

Wat denk ik wel belangrijk is dat we als Europa in de gaten houden dat dit niet ook alleen een "Big Tech" feestje wordt.

Een Europese non-profit tegenhanger van Let's Encrypt zou echt geen gek idee zijn.

[Reactie gewijzigd door Keypunchie op 23 oktober 2026 14:20]

[3raser]

Een Europese non-profit tegenhanger van Let's Encrypt zou echt geen gek idee zijn.

Die is er volgens mij ook.
https://europeantechmap.eu/alternative-to/lets-encrypt

Maar zo goed geïntegreerd als Let's Encrypt is er natuurlijk niet één.

[edit] Ik zag het verkeerd. Het is wel ACME-enabled maar niet gratis.
Ik lees trouwens dat het ongeveer 3 miljoen per jaar kost om Let's Encrypt te runnen. Dat moet in Europa toch ook wel op te brengen zijn door sponsors en donateurs?

[Reactie gewijzigd door 3raser op 23 oktober 2026 14:38]

[Keypunchie]

Ben niet de diepte in gegaan, maar meen dat Actalis geen wildcards doet en ZeroSSL niet daadwerkelijk gratis is.

Maar inderdaad. Het budget lijkt me haalbaar voor zo'n belangrijk fundament van de online dienstverlening.

[Pieter_621]

Ze hadden mogelijk nog iets kunnen redden met een afdoende reactie. In plaats daarvan was hun incident-pagina beperkt tot 'oh, dit is maar een klein incident, we hebben het bijna niet gebruikt om certificaten uit te geven'. Waarmee ze aangeven niets te begrijpen van het probleem, en hun vertrouwen verder hebben ondermijnd. De opmerking dat de aandacht overtrokken zou zijn versterkt dit beeld.

[Menesis]

Wat zijn de gevolgen van die slechte certificaten? Op die bugzilla staat er o.a.:

6 of the impacted certificates are for TLS and trusted by the Chrome, Mozilla, Microsoft and Apple root programs. The other two certificates are for codesigning and trusted by Microsoft.

Wat kan iemand daar mee doen?

[_JGC_]

Dat betekent dat je op elk OS en elke browser gewoon fake certificaten kunt genereren om je voor te doen als iemand anders. In geval van codesigning kan je ook programma's ondertekenen met een fake certificaat en gaat Windows daar niet over piepen.

[Muncher]

There were no end entity certificates issued out of the affected CA’s. Its infrastructure was not compromised and no data was breached. All physical and logical security controls remained intact.

Dit is misschien wel de meest dubbelzinnige uitspraak die ik recentelijk heb gezien. Je hoeft eindgebruikerscertificaten rechtstreeks via de betrokken certificeringsautoriteiten uit te geven als je fysieke en logische beveiligingsmaatregelen ‘4’ als privésleutel bevatten. Dat is eigenlijk precies waar het om draait. Zo suf.

Ik vind het gebruik van het woord voluntarily ook mooi hier. Nee maat, niemand wilde meer met je keys werken. Doei doei.

En dan de opmerking: This is a small part of our revenue but the internet is making it out to be a big deal. Ik vraag me oprecht af of de mensen die dit hebben geschreven het probleem wel begrijpen. Waarschijnlijk wel maar word het lekker in eigen voordeel gedraaid.

[Rukapul]

Buiten dat dit natuurlijk een enorme fuckup is, bevestigt het ook de fundamentale onmogelijkheid van een sustainable business model voor een trusted third party.

We hebben nu bij herhaling gezien dat het business model van een TTP binair is: een fout is fataal. En iedereen kan die fout maken. Daar staat tegenover dat het opzetten, en leveren, van een TTP dienst kosten met zich mee brengt.

Het is daarmee verworden tot spelers die
- hun bestaande business uitmelken tot ook zij getroffen worden
- een dubbele agenda hebben (bv business control point)