eMudhra revokt extra CAs: na de bekendmaking rond een key compromise in oktober heeft het bedrijf opnieuw acht intermediate certificate authorities (CAs) ingetrokken. Volgens eMudhra waren hun sleutels niet per se “verzwakt” door het bekende scenario, maar ging het mis in een ander onderdeel van het proces rond het ophalen, verpakken en terug opbouwen van privésleutelmateriaal.
Voor organisaties die certificaten van deze CAs gebruiken, is dit vooral relevant omdat certificaatketens via de ingetrokken CAs mogelijk hun vertrouwen verliezen in meerdere browsers en besturingssystemen. In dit artikel zetten we de kern van het incident op een rij en wat houders nu moeten controleren.
Wat is er precies gebeurd met de ingetrokken intermediate CAs?
eMudhra beschrijft dat het in oktober al een key compromise-melding had, en dat die situatie nu doorwerkt in een nieuwe reeks intrekkingen: acht extra intermediate CAs zijn gerevoke. Het bedrijf zegt dat de keys van deze acht CAs in oktober niet dezelfde “key weakening” veroorzaakten als eerder was vastgesteld.
De kern zit volgens het incidentrapport in een regel in een intern Python-script. Tijdens een ceremonie voor het overzetten/verplaatsen van keys zou het script privésleutels hebben teruggelezen uit een hardware security module (HSM). Daarbij is bij de acht ECDSA-keys een bewerking opgetreden die de privésleutel “truncatet” tot één leading byte.
Waarom waren de sleutels toch bruikbaar?
Opvallend is dat de zwak gekopieerde sleutels nog steeds geldige handtekeningen konden produceren. Ook certificaten die daarmee werden gecertificeerd, doorstonden test- en auditprocessen: ze leverden correcte signatures op en zouden volgens het rapport linting en twee WebTrust auditcycli hebben gehaald.
Daarmee is het risico niet alleen theoretisch. Wie de certificaten vertrouwt op ketenniveau, kan te maken krijgen met verlies van vertrouwen zodra browsers, OS-leveranciers of root-programma’s de ingetrokken CAs afwijzen.
TLS en code signing: welke certificate types waren betroffen?
Van de acht ingetrokken intermediate CAs waren er zes bedoeld voor website TLS-certificaten en twee voor code signing. eMudhra geeft ook aan dat vier van die intermediate CAs al in mei in productie zijn gezet.
Op basis van de certificatielijst gaat het om een totaal van 195 certificates die aan deze intermediate CAs te koppelen zijn. Daarbij zijn er 29 voor de eigen domeinen van eMudhra, en daarnaast certificaten voor andere organisaties en instellingen, waaronder universiteiten/colleges en een county.
De link met het ceremonieproces en de rol van HSM’s
eMudhra plaatst de oorsprong van beide problemen in een key ceremony op 30 april 2025. Op die dag werden 16 CA-keys gegenereerd op Utimaco HSM’s, waaronder de keys die later in oktober/november in het nieuws kwamen.
Omdat eMudhra aangeeft dat het verplaatsen van keys tussen HSM-omgevingen van verschillende leveranciers beperkt is, ontwierp het PKI-team een Python-script om de keys te “wrap” voor transport en later weer “unwrap” om opnieuw te gebruiken.
Het rapport stelt verder dat de “round trip” die dag een oefenrun was, waarbij de bron-HSM in een FIPS-goedgekeurde modus werd uitgeschakeld als een uitzondering binnen het acceptabele proces.
Waarom eMudhra niet met zekerheid kan aantonen dat het volgens beleid ging
Hoewel het bedrijf stelt dat de HSM’s zelf correct werkten, blijft volgens eMudhra de procescontrolevraag overeind: eMudhra geeft aan dat het niet positief kan aantonen dat het gebruikte sleutelmateriaal voldeed aan een eigen regel, specifiek over naleving van CPS §6.2.6 rond het in- en uitnemen van keys uit een HSM.
In de beschrijving gaat het vooral mis bij hoe de keys na het lezen uit de HSM in het geheugen van een ceremoniecomputer terechtkwamen. eMudhra zegt dat logs en bestanden van dat systeem niet betrouwbaar genoeg aantonen hoe het materiaal precies is verwerkt.
Welke gevolgen kunnen houders verwachten?
eMudhra geeft aan dat alle houders van certificaten zijn overgezet naar nieuwe certificaten. Er zou volgens het rapport geen concrete misbruikcasus bekend zijn.
Tegelijkertijd betekent intrekking doorgaans dat ketens niet meer (of later) worden vertrouwd in grote ecosystemen. eMudhra meldt dat het bedrijf de certificaatactiviteiten voor de publieke TLS-markt aan het afbouwen is na de aankondiging van 22 oktober.
Microsoft: trust verwijderen van resterende roots
Microsoft start met het verwijderen van de 10 resterende eMudhra roots, inclusief emSign Root CA – G1, vanaf 16 november. Certificaten die aan die roots ketenen verliezen dan standaardvertrouwen in Windows en Edge en mogelijk in andere Microsoft-producten volgens hun eigen planningen.
Chrome, Firefox en Apple
Volgens de phase-out planning van eMudhra geldt: Chrome en Firefox zullen G1-certificaten die na 16 november zijn uitgegeven niet meer vertrouwen. Apple beëindigt het vertrouwen in alle G1-certificaten, inclusief oudere, op 30 november.
Apple meldt daarnaast dat specifieke macOS-updates (zoals macOS 27.2.1, 26.7.3 en 15.8.3) de gebundelde command-line tools (waaronder curl en git) laten stoppen met het accepteren van de gecompromitteerde TLS CA-certificaten. Ook verdwijnen er roots uit /etc/ssl/cert.pem, wat impact kan hebben op tools die dat bestand gebruiken om certificaten te verifiëren.
Wat moeten houders nu zelf controleren?
Als organisatie die certificaten gebruikt die (mogelijk) via de betreffende eMudhra hiërarchieën lopen, draait het nu om snel inzicht en opvolging.
- Zoek affected certificaten in de lijst van eMudhra of via Certificate Transparency logs, specifiek gericht op de ingetrokken G2C TLS issuers.
- Controleer certificaatketens in je omgevingen: welke servers, APIs of interne endpoints gebruiken certificaten die ketenen via de betreffende intermediate CAs?
- Vervang tijdig waar ketens afhankelijk zijn van de ingetrokken CAs. eMudhra geeft aan dat nieuwe certificaten beschikbaar zijn, maar de praktijk is dat je vooral je eigen deployment- en trust-instellingen moet bijwerken.
- Let op TLS én code signing. eMudhra’s intrekking omvat ook code signing CAs; verifieer of je build, releases of softwareverdeling daarvan afhankelijk is.
Heb je in je organisatie ook te maken met AI-agenten die beleid of regels “doorzoeken” en omzeilen? Dan is de manier waarop interne tooling en control-paden soms toch afwijken van wat je verwacht een terugkerend thema. Lees bijvoorbeeld hoe je AI-regels openbreekt met een agent in de browser als achtergrond over waarom safeguards in de praktijk kunnen misgrijpen.
Waarom dit een belangrijk PKI-signaal is
Deze case laat zien hoe een kleine fout in een intern script of een ongeteste stap in een ceremonieproces kan leiden tot grootschalige vertrouwensimpact. Belangrijk hierbij is dat eMudhra stelt dat certificaten valide handtekeningen bleven opleveren en auditcycli konden passeren.
Daarmee verschuift de focus van “wel of niet technisch geldig” naar “wel of niet aantoonbaar compliant volgens beleid” en “wel of niet correct gekoppeld aan de juiste sleutelgeneratie-historie.” Voor security teams is dat een extra reden om PKI-processen niet alleen op cryptografische output te beoordelen, maar ook op controleerbaarheid en traceerbaarheid van key lifecycle-events.
Als je breder kijkt naar supply chain en verificatieprocessen, dan past dit ook in het grotere veiligheidsbeeld. Een nuttige aanvulling is software transparency met SBOMs, AI BOMs en VEX uitgelegd, omdat het dezelfde vraag raakt: hoe maak je herkomst en status van componenten aantoonbaar?
Vooruitblik: beoordeling door onafhankelijke reviewer
eMudhra geeft aan dat het bedrijf KPMG heeft ingehuurd als onafhankelijke reviewer. Volgens de planning moet die review 4 december afgerond zijn. Daarnaast verwacht eMudhra zijn inventarisatie van alle CA-keys op 30 november te publiceren.
In de bugthread vragen deelnemers ook om publicatie van het script, en om uitleg hoe privésleutels überhaupt de HSM’s hebben kunnen verlaten. Dat blijft relevant, omdat het antwoord bepaalt welke technische en procesmatige verbeteringen nodig zijn om herhaling te voorkomen.
Conclusie
eMudhra revokt extra CAs: acht intermediate certificate authorities zijn ingetrokken nadat een Python-scriptfout tijdens een key ceremony leidde tot het genereren/certificeren van sleutels die niet volgens de eigen compliance-eisen waren verwerkt. Voor houders betekent dit vooral dat ze certificaatketens moeten nalopen, tijdig moeten overstappen naar nieuwe certificaten en rekening moeten houden met trust-verwijdering door grote leveranciers (zoals Microsoft, Chrome/Firefox en Apple).
Ook al is er volgens eMudhra geen bewijs van misbruik bekend, de combinatie van TLS-impact, code signing en het afbouwscenario maakt dit een incident waar je snel actie op wilt nemen.
Bron: https://thehackernews.com/2026/11/emudhra-revokes-8-more-cas-it.html
