De gecompromitteerde CA-sleutels van eMudhra: wat bedrijven nu moeten controleren en oplossen

Op zaterdag 17 oktober 2026 meldde een beveiligingsonderzoeker dat acht intermediate-CA's (tussenliggende certificaatautoriteiten) van eMudhra, een Indiase certificaatautoriteit, privésleutels hadden die iedereen uit de openbare certificaten kon afleiden. Elk van die sleutels was een getal kleiner dan 256. Eén ervan was het getal 4. Zes van de acht konden TLS-certificaten uitgeven die Apple, Google, Microsoft en Mozilla vertrouwen; de andere twee konden Windows-software ondertekenen.

Chrome blokkeerde de zes TLS-sleutels een uur en veertig minuten na de melding, Firefox dezelfde avond. Voor wie op het web surft, was het gevaar zaterdagnacht voorbij.

Voor al het andere niet. Servers, containers, Java-applicaties, Python-scripts, betaalintegraties en verbonden apparaten controleren certificaten tegen hun eigen kopie van de lijst met vertrouwde certificaatautoriteiten, en de meeste van die kopieën veranderen pas als iemand een update installeert. Tot dat moment gaat een certificaat voor welk domein dan ook dat met een van deze sleutels is ondertekend door voor echt, en de sleutels zijn sinds 20 oktober openbaar.

In dezelfde week begon GoDaddy 404.607 certificaten in te trekken, omdat de beleidsinformatie erin niet overeenkwam met zijn eigen gepubliceerde documenten. De klanten moesten de vervangende certificaten zelf downloaden en installeren.

Deze gids is voor de mensen die de vraag “worden wij geraakt?” moeten beantwoorden: IT- en operationsmanagers, CTO's en oprichters van wie het bedrijf draait op een website, een API of een verbonden product. Hij behandelt wat er is gebeurd, op basis van de incidentverslagen die Mozilla, Google, eMudhra, GoDaddy en de softwareleveranciers hebben gepubliceerd; wat u vandaag controleert; wat u deze week bijwerkt; en wat u inricht zodat het volgende incident van deze soort routine wordt. Alles hier is de stand van 22 oktober 2026, en het incident is nog niet afgesloten.

Wat er is gebeurd

eMudhra maakte de acht intermediate-CA's aan tijdens een sleutelceremonie op 30 april 2025. Het verslag van eMudhra, dat op 19 oktober in de incidentbug bij Mozilla verscheen: een test van een stap voor key wrap en unwrap, goedgekeurd als afwijking van de gebruikelijke procedure, bevatte een fout waardoor in de hardware security module naast de bedoelde sleutels een tweede, zwakke set sleutels ontstond. De labels leken op elkaar, de zwakke sleutels werden per vergissing gebruikt om de certificaataanvragen te maken, en de root van eMudhra ondertekende ze. Dezelfde aanvragen gingen naar Sectigo, dat op 14 mei 2025 alle acht cross-signde vanuit zijn root AAA Certificate Services. eMudhra zegt dat het “de precieze grondoorzaak nog niet heeft bevestigd”.

Mozilla beschreef het resultaat: “Privésleutels voor P384 zijn willekeurig gekozen gehele getallen tussen 1 en de orde van de groep. De 8 getroffen sleutels gebruikten allemaal gehele getallen kleiner dan 256.” Mozilla ontving de melding om 20:06 UTC en achterhaalde de sleutels om 21:48 zelf, “zonder enige kennis van de methode die de oorspronkelijke melder gebruikte”. De onderzoeker zegt dat hij ze vond met paranoid_crypto, de opensourcebibliotheek van Google, “direct uit de doos”. De zwakke sleutels maakten al bijna 18 maanden deel uit van publiek vertrouwde ketens.

De acht certificaten:

Elke sleutel zit in twee certificaten. Het ene is uitgegeven door emSign Root TLS CA - G3 of emSign Root CS CA - G3 van eMudhra, waarvan de keten eindigt bij emSign ECC Root CA - G3; het andere is het cross-certificaat van Sectigo vanuit AAA Certificate Services. Dat tweede pad doet ertoe, want sommige trust stores die nooit een root van eMudhra bevatten, vertrouwen die oude root van Sectigo nog wel.

Is er iemand aangevallen?

Niemand heeft misbruik gemeld, en voor browsers is er goede reden om aan te nemen dat het er ook niet was. Chrome accepteert, net als andere clients die Certificate Transparency (CT) afdwingen, een certificaat alleen als het in de openbare CT-logs is vastgelegd. Google: vóór zijn blokkade waren er geen TLS-certificaten onder deze zes intermediate-CA's gelogd, dus “kunnen er geen frauduleuze certificaten van deze CA's zijn gebruikt tegen clients die CT afdwingen”.

Buiten de browser ligt dat anders. De incidentpagina van Mozilla: “veel clients buiten het browserecosysteem dwingen Certificate Transparency niet af. We weten niet of aanvallers de gebrekkige sleutelgeneratie hebben misbruikt om deze clients aan te vallen.” Dat venster ging in het voorjaar van 2025 open en sluit voor elke client pas als die wordt bijgewerkt. eMudhra zegt niet bekend te zijn met enig bewijs dat de sleutels vóór de openbaarmaking zijn achterhaald, en Cloudflare zegt bij zijn onderzoek geen actief misbruik op zijn diensten te hebben gevonden.

Nu de sleutels openbaar zijn, vraagt het vervalsen van een certificaat geen enkele vaardigheid. De incidentpagina van Mozilla noemt testservers die certificaten presenteren die met de gecompromitteerde sleutels zijn uitgegeven, zodat iedereen er zijn clients tegen kan testen (de commando's staan hieronder).

Wat een vervalst certificaat mogelijk maakt: wie het verkeer kan onderscheppen tussen uw software en een dienst die die aanroept (op een gedeeld netwerk, via een gecompromitteerde router of een vergiftigd DNS-antwoord), kan zich als die dienst voordoen, lezen wat uw software verstuurt, API-sleutels en persoonsgegevens inbegrepen, en aanpassen wat uw software ontvangt. Software die met een van de twee sleutels voor codeondertekening is ondertekend, zou door de handtekeningcontrole van Windows zijn gekomen totdat de blokkade van Microsoft de machine bereikte.

Wie er geraakt wordt

Het gaat om drie afzonderlijke problemen, en één bedrijf kan ze alle drie hebben.

1. Software die de gecompromitteerde sleutels nog vertrouwt

Dit probleem heeft bijna elk bedrijf: elk programma dat HTTPS-verzoeken doet, waarvan de trust store nog emSign ECC Root CA - G3 of AAA Certificate Services bevat en dat nog geen blokkade voor de acht sleutels heeft gekregen. Typische plekken:

• Linux-servers en containerimages die vóór 20 of 21 oktober zijn gebouwd. Een ongepatchte Debian 12 vertrouwt bijvoorbeeld beide ketens.
• Runtimes van programmeertalen die hun eigen lijst meeleveren: Node.js, certifi van Python, cacerts van Java, de Composer-bundel van PHP, webpki-roots van Rust.
• Commandlinetools op macOS. Volgens de incidentpagina van Mozilla controleren de ingebouwde curl, git, python3, perl, ruby en openssl certificaten tegen /etc/ssl/cert.pem zonder op intrekking te controleren, en heeft Apple dat bestand niet bijgewerkt.
• Windows-machines die de automatische updates van de lijst met geweigerde certificaten van Microsoft niet ontvangen, meestal omdat Groepsbeleid ze uitschakelt of het netwerk offline is.
• Appliances, apparaten en software van derden met een eigen CA-bestand, zoals load balancers, VPN-gateways, SDK's en embedded controllers.

Elke runtime moet u afzonderlijk controleren. In een test die wij op 22 oktober uitvoerden, accepteerde een ongepatchte Debian 12-machine met Node.js 24.18 de keten die eindigt bij de root van eMudhra en weigerde hij de keten die eindigt bij de root van Sectigo, terwijl Python op dezelfde machine beide accepteerde.

2. Bedrijven waarvan de eigen certificaten onder de verwijderde root vallen

Mozilla en de Linux-distributies hebben emSign ECC Root CA - G3 verwijderd, en Chrome volgt op 27 oktober. Geldige certificaten onder die root werken in elke client niet meer zodra die wordt bijgewerkt. De instructie van Google: websitebeheerders met zulke certificaten “moeten onmiddellijk een nieuw TLS-certificaat aanschaffen en installeren uit een andere PKI-hiërarchie die in de Chrome Root Store is opgenomen”.

Chrome telde op 21 oktober in CT ongeveer 30.800 niet-verlopen certificaten onder de root. Daarvan kwamen er 30.791 van twee intermediate-CA's van InCommon, de certificaatdienst die Internet2 voor Amerikaanse universiteiten en onderzoeksinstellingen beheert en die ECC-certificaten uitgeeft via CERTInext, het platform van eMudhra. De eigen intermediate-CA's van eMudhra waren goed voor 18. eMudhra zegt dat ongeveer 30.000 certificaten gemigreerd moeten worden, waarvan ongeveer 97% via ACME is uitgegeven, en dat het vervangende certificaten uitgeeft vanuit een andere hiërarchie.

Staat uw site achter Cloudflare in de modus Full (strict) en presenteert de origin een certificaat onder deze root, dan zegt Cloudflare dat het wegvallen van het vertrouwen “storingen zou veroorzaken”, en vraagt het klanten “hun eigen origincertificaten en serverconfiguraties na te lopen”.

RSA-certificaten van de andere root van eMudhra, emSign Root CA - G1, zijn tot nu toe niet getroffen. Mozilla zegt dat het die root “op dit moment” niet verwijdert; Chrome “onderzoekt nauwgezet de verdere opname van de resterende CA-certificaten van eMudhra”. Bent u afhankelijk van certificaten van eMudhra of CERTInext, van welke soort ook, regel dan nu een tweede certificaatautoriteit.

3. Klanten van GoDaddy

De zaak van GoDaddy heeft niets met eMudhra te maken, maar speelde in dezelfde week en raakte veel meer sites. Op 15 oktober meldde GoDaddy aan Mozilla dat certificaten uit zijn GoDaddy- en Starfield-hiërarchieën certificaatbeleidsinformatie bevatten (policy-OID's en CPS-links) die niet overeenkwam met de profielen in zijn eigen CP/CPS, het document waarin een certificaatautoriteit vastlegt wat ze uitgeeft. Dat is geen beveiligingsfout in de certificaten. Volgens de Baseline Requirements, de regels die elke publieke certificaatautoriteit volgt, is het toch een reden om ze binnen vijf dagen in te trekken.

Het ging om 404.607 certificaten, waarvan 396.055 domeingevalideerd. GoDaddy trok er 170.566 in vóór de deadline van 18 oktober, 23:45 UTC, en 227.422 tegen de volgende ochtend; volgens zijn klantbericht is de rest op 21 oktober ingetrokken. GoDaddy geeft de certificaten opnieuw uit, maar installeren is aan de klant: “bezoekers van uw website kunnen beveiligingswaarschuwingen zien, en uw site kan onbereikbaar worden totdat er een nieuw certificaat is geïnstalleerd.”

Wat u vandaag controleert

1. Wat sturen uw eigen servers? Vraag voor elke openbare hostnaam de uitgevers op in de keten die hij presenteert:

h=www.example.com
openssl s_client -connect "$h:443" -servername "$h" -showcerts </dev/null 2>/dev/null | grep -E '^ +i:'

Noemt een regel eMudhra, emSign, een van de autoriteiten EM ... G3B of G3C, of InCommon Intermediate CA - DVG3C, OVG3C of EVG3C, dan moet het certificaat vóór 27 oktober worden vervangen. AAA Certificate Services op zichzelf is normaal, want veel gewone Sectigo-ketens bevatten die nog. Voeg voor mail- en directorydiensten -starttls smtp (of imap, ldap) en de juiste poort toe. Neem ook interne hosts, load balancers en origins achter een CDN mee.

2. Wat is er voor uw domeinen uitgegeven? CT bevat elk certificaat dat een publieke certificaatautoriteit voor uw namen heeft uitgegeven, ook certificaten waarvan niemand in het bedrijf zich herinnert dat ze zijn besteld:

curl -s 'https://crt.sh/?q=%25.example.com&output=json&exclude=expired' | jq -r '.[].issuer_name' | sort | uniq -c

De uitvoer laat ook zien welke certificaatautoriteiten uw bedrijf werkelijk gebruikt, en dat is het begin van de inventaris die verderop wordt beschreven.

3. Vertrouwen uw clients de gecompromitteerde sleutels? De testservers van Mozilla presenteren certificaten die onder de gecompromitteerde sleutels zijn uitgegeven, dus een certificaatfout is de goede uitkomst. Test beide families: de keten van de eerste host eindigt bij de root van eMudhra, die van de tweede bij de root van Sectigo, en een trust store kan de ene weigeren en de andere accepteren.

curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ && echo "TRUSTED: update this system"

curl geeft alleen antwoord voor curl. Voer hetzelfde verzoek uit via de eigen TLS-stack van elke applicatie, in de omgeving waarin die applicatie draait:

node -e "require('https').get('https://dv-g3b-emudhra.we-have-a-problem.com/', () => console.log('TRUSTED')).on('error', e => console.log('rejected:', e.code))"
python3 -c "import urllib.request; urllib.request.urlopen('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"
python3 -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('TRUSTED')"

De twee Python-regels zijn niet overbodig: urllib gebruikt de trust store van het besturingssysteem, requests gebruikt certifi. Herhaal elke regel met de host dv-g3b-aaa-emudhra. Doe voor Java een willekeurige HTTPS-aanroep naar de testservers vanuit de betreffende JVM, en controleer of de trust store een van beide roots bevat (Java 9 of later; gebruik op Java 8 -keystore $JAVA_HOME/jre/lib/security/cacerts):

keytool -list -v -cacerts -storepass changeit | grep -E 'Owner: .*(emSign ECC Root CA - G3|AAA Certificate Services)'

Een root in een trust store bewijst op zichzelf nog niet dat u kwetsbaar bent, want Go, Node.js, Deno en rustls-webpki van Rust blokkeren de acht sleutels nu, wat de trust store ook zegt. De testservers geven uitsluitsel.

4. Windows-machines. Microsoft heeft niets over het incident gepubliceerd, maar de lijst met geweigerde certificaten die Windows automatisch downloadt, blokkeert sinds 20 oktober alle acht sleutels. Uitzonderingen zijn machines waarop Groepsbeleid de automatische updates van rootcertificaten uitschakelt, en netwerken zonder route naar Windows Update; daar moet de lijst op een andere manier worden afgeleverd. certutil -verifyCTL Disallowed toont de kopie die een machine in de cache heeft. De incidentpagina van Mozilla biedt een script voor losse machines en zegt dat het “niet wordt aanbevolen voor apparaten die door een organisatie worden beheerd”.

5. Certificaten van GoDaddy. Controleer welk certificaat elke server werkelijk presenteert:

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -issuer -serial -startdate

Is de uitgever GoDaddy of Starfield, vergelijk dan het serienummer met de certificaten in uw GoDaddy-account. Waar GoDaddy “Install your new certificate” (installeer uw nieuwe certificaat) toont, heeft de server nog het ingetrokken certificaat.

Eén regel geldt overal: laat een fout niet verdwijnen door de certificaatverificatie uit te schakelen. In de woorden van Cloudflare: “Het is belangrijk deze fouten niet op te lossen door de verificatie uit te schakelen.” Een client die niet verifieert, vertrouwt elk vervalst certificaat, niet alleen deze.

Wat u deze week bijwerkt

Er zijn twee soorten fixes. Het verwijderen van de twee roots sluit elk pad af voor een client die die trust store gebruikt, maar het breekt ook de geldige certificaten eronder. Het blokkeren van de acht sleutels op de hash van hun publieke sleutel, zoals Go, Node.js, Deno, Electron, rustls-webpki, Composer en Windows doen, dicht het gat en breekt verder niets. Biedt uw platform de tweede aanpak, kies die dan.

“Nog geen” en “nog niet” betekenen dat er tot 22 oktober niets was gepubliceerd. Controleer het opnieuw voordat u uw planning erop afstemt.

Op vier punten gaan teams vaak de mist in:

• Containerimages houden de oude lijst. Een image dat vóór 20 of 21 oktober is gebouwd, vertrouwt de sleutels totdat het opnieuw wordt gebouwd op een bijgewerkt basisimage, en dezelfde tag opnieuw pullen helpt pas als dat basisimage opnieuw is gebouwd. Bouw opnieuw, rol opnieuw uit, en vraag het na bij de leveranciers van de images die u draait.
• Processen houden vast wat ze hebben geladen. Een programma leest zijn trust store bij het starten, dus herstart langlopende diensten na het bijwerken. Node.js voegt eraan toe dat TLS-sessies die worden hervat van vóór de upgrade niet opnieuw worden gecontroleerd.
• Applicaties hebben hun eigen CA-bestanden. SDK's en applicaties leveren vaak een eigen cacert.pem of ca-bundle.crt mee. Doorzoek repository's en images erop, bijvoorbeeld met find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, en reken op meer dan één: pip heeft bijvoorbeeld een eigen kopie van certifi.
• Apparaten wachten op hun leverancier. Vraag elke leverancier schriftelijk welke trust store het product gebruikt en wanneer de update verschijnt. Tot dan vertrouwt het apparaat vervalste certificaten voor elke dienst die het aanroept, dus beperk wat het kan bereiken.

Verwijdert u AAA Certificate Services met de hand, zoals Debian, Ubuntu ESM, Fedora en de workaround van Red Hat doen, test daarna dan verbindingen met diensten die certificaten van Sectigo gebruiken: sommige oudere servers sturen nog een keten die bij die root eindigt.

Wat u inricht voor het volgende incident

Een certificaatautoriteit die zulke zwakke sleutels in gebruik laat, is zeldzaam. Massale intrekkingen zijn dat niet. Dit zijn de grote van 2026 die in de bugtracker van Mozilla zijn vastgelegd:

Geen van deze vijf was een beveiligingsfout. Telkens week een certificaat af van het eigen document van de autoriteit, en de Baseline Requirements (sectie 4.9.1.1) eisen dan toch intrekking binnen vijf dagen. Is een sleutel gecompromitteerd, of valt er niet op de domeinvalidatie te vertrouwen, dan is de termijn 24 uur. Niemand kan die voor u verlengen. Bij de intrekking van 83.267 certificaten door DigiCert in 2024 schreef het Chrome Root Program dat het “niet de bevoegdheid heeft om uitzonderingen toe te staan”; één klant kreeg een rechterlijk bevel om de intrekking van zijn certificaten te stoppen, en dat bevel werd vier dagen later opgeheven.

Hoe de vervanging verliep, zegt veel. In juli gebruikte HARICA ACME Renewal Information (ARI) om de ACME-clients van zijn klanten te laten weten dat ze vroeg moesten vernieuwen, en gaf het andere certificaten zelf opnieuw uit; bij de grootste van zijn twee intrekkingen was 87% van de getroffen namen vervangen toen de deadline verstreek. GoDaddy, waarvan de klanten elk vervangend certificaat zelf downloaden en installeren, had bij zijn deadline 42% van de getroffen certificaten ingetrokken.

De vernieuwingscyclus wordt hoe dan ook korter:

• Op grond van ballot SC-081 van het CA/Browser Forum zijn publieke TLS-certificaten sinds 15 maart 2026 beperkt tot 200 dagen. De limiet zakt op 15 maart 2027 naar 100 dagen en op 15 maart 2029 naar 47 dagen; vanaf dan mag domeinvalidatie nog maar 10 dagen worden hergebruikt.
• Let's Encrypt stapt op 10 februari 2027 standaard over op certificaten van 64 dagen, en een jaar later op 45 dagen.
• Publieke TLS-certificaten verliezen clientauthenticatie. Let's Encrypt stopte op 8 juli 2026 met het uitgeven ervan, en het Chrome Root Program eist dat certificaten die vanaf 15 maart 2027 worden uitgegeven alleen voor serverauthenticatie zijn. Gebruikt u publieke certificaten als clientcertificaten voor mutual TLS, wat gebruikelijk is bij B2B-API-integraties, dan hebben die verbindingen een private certificaatautoriteit nodig.

Bij 100 dagen, en daarna bij 47, is certificaten met de hand installeren geen realistische optie meer. Een bedrijf dat voor dat schema automatiseert, is ook klaar voor de volgende massale intrekking. Wat daarvoor nodig is:

1. Weet wat u hebt, in beide richtingen. Eén lijst van elk certificaat dat u serveert, met hostnaam, uitgever, vervaldatum, vernieuwingsmethode en eigenaar. Een tweede lijst van elke trust store waarop uw software vertrouwt: het pakket van het besturingssysteem, elke taalbundel, elk CA-bestand in een applicatie of apparaat. De CT-zoekopdracht hierboven is het begin van de eerste lijst; een software bill of materials (SBOM) of een inventaris van afhankelijkheden is het begin van de tweede.
2. Automatiseer uitgifte en installatie. ACME overal waar het kan draaien, met ARI (RFC 9773), zodat een certificaatautoriteit uw clients kan laten weten dat ze vroeg moeten vernieuwen. Kan een apparaat geen ACME draaien, gebruik dan de automatisering van de leverancier, of termineer TLS ervoor op iets dat dat wel kan.
3. Houd een tweede certificaatautoriteit achter de hand. Een werkend, getest ACME-account bij een tweede autoriteit, en CAA-records in DNS die beide toestaan. Verliest de ene autoriteit het vertrouwen of trekt ze massaal certificaten in, dan is overstappen een configuratiewijziging.
4. Monitor CT voor uw domeinen. Laat u waarschuwen bij elk nieuw certificaat voor uw namen. Dan hoort u van onverwachte uitgifte op de dag dat die plaatsvindt.
5. Behandel trust stores als afhankelijkheden. Werk ze bij via het gewone patchen, en bouw images volgens een schema opnieuw in plaats van alleen wanneer de code verandert.
6. Schrijf het runbook voor de twee klokken. 24 uur en vijf dagen: wie beslist, wie toegang heeft tot elk systeem, welke systemen handmatige stappen nodig hebben, hoe u elke leverancier bereikt. Oefen het één keer per jaar door het certificaat te wisselen op een dienst waar een fout geen kwaad kan. Publieke certificaatautoriteiten moeten sinds 2025 een eigen plan voor massale intrekking bijhouden en testen; hun klanten hebben de andere helft nodig.

Als u producten maakt die bij anderen draaien

Bevat uw product een trust store (een apparaat, een geïnstalleerde applicatie, een SDK), dan zijn uw klanten pas beschermd als uw update hen bereikt. Lever die uit, en vertel klanten welke versies de fix bevatten. Het advies van Mozilla aan beheerders van trust stores: blokkeer de acht intermediate-CA's als uw software dat kan, en “overweeg anders of het passend is het vertrouwen op te zeggen in de roots die deze intermediate-CA's hebben ondertekend”.

De Cyber Resilience Act speelt hier op twee manieren mee. De meldplicht, die sinds 11 september 2026 geldt, betreft actief misbruikte kwetsbaarheden, en in deze zaak is geen misbruik gemeld. De essentiële cyberbeveiligingseisen, die vanaf 11 december 2027 gelden, houden onder meer in dat kwetsbaarheden via beveiligingsupdates kunnen worden verholpen; een product waarvan de trust store niet kan worden bijgewerkt, zou daar niet aan voldoen. Klanten die onder NIS2 vallen, zullen hun leveranciers vragen hoe snel ze dit hebben afgehandeld, en het helpt als u het antwoord op papier hebt.

Wat nog openstaat

• De resterende root van eMudhra. Chrome stelde eMudhra op 21 oktober twaalf vragen en heeft geen besluit over emSign Root CA - G1 aangekondigd. Mozilla verwijdert die root “op dit moment” niet.
• Het migratiepad van eMudhra. eMudhra vertelde Mozilla dat het klanten naar zijn G1-hiërarchie (RSA) zou overzetten; zijn statuspagina spreekt van “een alternatieve, onafhankelijk beheerde, publiek vertrouwde CA-hiërarchie”. Chrome heeft gevraagd welke.
• Microsoft en Apple. Geen van beide heeft een verklaring gepubliceerd of een van de twee roots uit zijn trust store verwijderd.
• Openstaande fixes. Red Hat, Amazon Linux, Temurin en Corretto hadden tot 22 oktober niets uitgebracht; de fix van Bun was gemerged maar niet uitgebracht.
• De grondoorzaak. eMudhra heeft die niet bevestigd, en heeft gezegd dat het elke sleutelceremonie die het heeft uitgevoerd opnieuw zal verifiëren.
• Sectigo. In een afzonderlijke zaak, die sinds 5 september loopt, heeft Sectigo geweigerd certificaten in te trekken waarvan de extended key usage niet overeenkwam met een zin in zijn CPS, met het argument dat die zin dubbelzinnig was. Op 18 oktober telde Sectigo er nog ongeveer 72 miljoen die actief waren. Sommige deelnemers aan de openbare discussie hebben opgeroepen tot het opzeggen van het vertrouwen; geen enkel rootprogramma heeft een besluit aangekondigd. Bedrijven met certificaten van Sectigo doen er goed aan de zaak te volgen.

Waar u hulp krijgt

Een certificaatprobleem dient zich zelden aan als certificaatprobleem. Het duikt op als een checkout die niet meer laadt, een integratie die niet meer synchroniseert of een apparaat dat niets meer doorgeeft, meestal in het weekend. Wij helpen bedrijven zonder storing door weken als deze, en richten alles zo in dat de volgende routine wordt:

• Een blootstellingscheck. We zoeken uit waar uw systemen TLS-verbindingen opzetten of accepteren, welke trust store elk ervan gebruikt en welke certificaten u serveert, inclusief containers, Java-diensten, integraties met banken, betaal- en logistieke dienstverleners, en apparaten.
• De fixes. Updates, opnieuw gebouwde images, geblokkeerde sleutels of vervangen certificaten, doorgevoerd via uw changeproces en gecontroleerd tegen de testservers van Mozilla.
• Automatisering voor 2027. ACME met ARI op servers, load balancers en appliances, een tweede certificaatautoriteit, CAA-records, CT-monitoring en een runbook, klaar voor certificaten van 100 dagen vanaf 15 maart 2027.
• De systemen waar niemand aan wil komen. Oude Java-applicaties, appliances en embedded clients met hun eigen trust stores zijn precies waarvoor onze dienst voor onderhoud van legacysystemen en code bestaat.

Weet u niet zeker of u geraakt wordt, schrijf dan naar office@c9group.dev met de domeinen en platforms die u draait, of plan een gesprek. Wij vertellen u wat u als eerste moet controleren.