De privata nycklarna till åtta mellanliggande certifikat från den indiska certifikatutfärdaren eMudhra kan räknas fram av vem som helst på under en sekund. Med dem kan man utfärda certifikat för vilken domän som helst, och klienter som fortfarande litar på kedjan godtar dem. Chrome, Firefox och Safari har blockerat dem. Edge i Windows 11 godtog dem fortfarande när vi testade kl. 00.20 den 21-10-2026. API-integrationer, IoT-enheter, robotdammsugare, tv-apparater, kameror och annan utrustning som pratar med ett moln kan vara exponerade fram till 2039 om de litar på någon av kedjorna.
Hela genomgången med bevis, testsidor och uppdaterade versioner: emudhra.we-have-a-problem.com
Webbläsarna
Chrome och Firefox har blockerat de mellanliggande certifikaten sedan 17-10-2026 och Apple sedan 19-10-2026, utan att användaren behöver göra något, så länge webbläsaren har fått uppdateringen (Mozilla). Mozilla och Chrome tar dessutom bort hela eMudhras ECC-rot, emSign ECC Root CA - G3 (Bugzilla).
Chrome, Firefox och Safari godtar bara certifikat som finns i de offentliga CT-loggarna (Certificate Transparency) (Chrome, Firefox, Apple). Inga certifikat från de åtta mellanliggande certifikaten har hittats i CT-loggarna, så webbläsare som kräver CT har inte attackerats med dem under de 17 månader nycklarna var svaga.
Det skyddar bara bakåt i tiden. Nycklarna är nu allmänt kända, och vem som helst kan skicka in ett förfalskat certifikat till CT-loggarna och få de kvitton (SCT:er) som webbläsarna kräver. CT kontrollerar inte vem som äger domänen, så attacken syns i efterhand, men webbläsaren godtar certifikatet. Framåt är det bara uppdateringar som blockerar de mellanliggande certifikaten som skyddar en webbläsare. Testsidorna har just sådana certifikat, och Edge i Windows 11 öppnade dem fortfarande i vårt test. En Edge-installation som fortfarande godtar kedjan kan attackeras med ett förfalskat certifikat för vilken webbplats som helst av den som kan ta sig in på förbindelsen. Microsoft har inte sagt när det åtgärdas (Ars Technica).
All annan utrustning
Utrustning som pratar med ett moln utgår från att servern är den rätta när certifikatet stämmer med listan över rotcertifikat i enhetens firmware. Det gäller API-integrationer mellan system, IoT-enheter, robotdammsugare, luftkonditionering, tv-apparater, kameror, routrar och skrivare. Sådan utrustning kontrollerar sällan CT eller återkallelse (Scott Helme).
Så länge enheten inte får en ny lista över rotcertifikat kan den som tar sig in mellan enheten och internet utge sig för att vara tillverkarens moln med ett certifikat som enheten godtar. Det kan ske på samma wifi, i en hackad router eller hos en internetleverantör. Kedjorna fungerar:
- till 31-12-2028 om enheten litar på Sectigos gamla rot
AAA Certificate Services - till 09-07-2039, nästan 13 år, om den litar på
emSign ECC Root CA - G3 - till 28-04-2040 om den litar direkt på
emSign Root TLS CA - G3, vilket Windows gör
Ett exempel: ESP-IDF, som ESP32-kretsar i IoT-enheter byggs med, har emSign ECC Root CA - G3 med i sin standardlista. En enhet som bara litar på tillverkarens eget certifikat berörs inte.
Scott Helme skapade ett förfalskat certifikat för api.stripe.com, och curl, Python och Node godtog det utan fel (Scott Helme). Det är samma bibliotek som används i integrationer och CI/CD-flöden.
En bieffekt för den som vill styra sina egna prylar
Det kan bli lättare att ta kontroll över sin egen robotdammsugare, luftkonditionering eller annan enhet som bara vill prata med tillverkarens moln. Står man själv mellan enheten och internet kan enheten godta en lokal server som tillverkarens moln, om den litar på eMudhras certifikat. Det ger inte i sig kontroll över enheten, och vi har inte provat det på konkreta produkter. Det är samma teknik som en angripare använder, och certifikaten gäller en domän man inte äger. Projekt som Valetudo har i flera år gjort robotdammsugare fria från molnet på andra sätt.
Vilka är eMudhra
eMudhra är ett börsnoterat indiskt företag från Bangalore, grundat 2008, med en omsättning på 7 016 miljoner rupier, cirka 66 miljoner euro, under räkenskapsåret som slutade 31-03-2026. Företaget är Indiens största utfärdare av digitala signaturer, med cirka 38 % av marknaden (eMudhras resultatpresentation).
TLS-certifikat står för 6 % av eMudhras certifikatintäkter. Cirka 30 000 TLS-certifikat ligger under den rot som Mozilla och Chrome tar bort, och 97 % av dem är utfärdade via ACME (Bugzilla). Utanför Indien säljer eMudhra under namnet CertiNext, och sedan april 2026 levererar de certifikaten i InCommon, den gemensamma certifikattjänsten för amerikanska universitet.
Sectigo har korssignerat de berörda mellanliggande certifikaten under AAA Certificate Services. Det ger ytterligare en väg till förtroende, men det är eMudhras nycklar som är svaga. Sectigos egna nycklar berörs inte.
Vad gick fel
En privat P-384-nyckel ska vara ett slumpmässigt tal på 384 bitar. De åtta nycklarna är tal mellan 4 och 237. Scott Helme räknade fram dem ur de offentliga certifikaten på under en sekund genom att pröva talen från 1 och uppåt, och Mozilla fick AI-agenter att hitta dem på första försöket (Bugzilla).
Enligt eMudhra skapade ett fel i skriptet vid nyckelceremonin 30-04-2025 en extra uppsättning svaga nycklar i HSM:en, och de användes av misstag eftersom namnen liknade de rätta (Bugzilla). Felet gick att se i maj 2025, när de mellanliggande certifikatens spärrlistor hade ogiltiga signaturer.
Testa din utrustning
Öppna testsidan i webbläsaren. Den försöker själv ansluta till 12 testsidor med certifikat från de komprometterade mellanliggande certifikaten, via både eMudhras och Sectigos rot. "✅ Did not connect" vid alla 12 och "connected to 0 of 12" längst ned är rätt resultat. Står det "❌ Connected" litar webbläsaren på de knäckta certifikaten. Sidan kan inte skilja ett certifikatfel från ett nätverk som blockerar adressen, så testa även från ett nätverk utan filter.
För servrar och integrationer, kört från den dator eller container där integrationen körs:
curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
Ett certifikatfel är rätt resultat. Öppnas sidan utan fel litar klienten fortfarande på de komprometterade certifikaten. En timeout eller ett DNS-fel bevisar inte att klienten är skyddad.
Så åtgärdar du det
1. Uppdatera allt som kan uppdateras. Webbläsare, operativsystem och Docker-avbildningar, som ska byggas om med de nya paketen. Ubuntu, Debian, Alpine, Arch, Gentoo, Go, Python certifi, pip och curls CA-paket är uppdaterade. Fedora, FreeBSD, Node.js och Bun saknas fortfarande. Se den aktuella tabellen på sidan.
2. Windows: blockera certifikaten själv. Tills Microsoft uppdaterar kan du lägga alla 16 certifikat (åtta nycklar, var och en i två versioner, även de två för kodsignering) i Windows certifikatlager för certifikat som inte är betrodda. Kör PowerShell som administratör:
$ErrorActionPreference = 'Stop'
[Net.ServicePointManager]::SecurityProtocol = 'Tls12'
$certs = Invoke-RestMethod 'https://emudhra.we-have-a-problem.com/impacted-intermediates.json'
foreach ($c in $certs) {
$fil = Join-Path $env:TEMP ($c.sha256 + '.crt')
Set-Content -Path $fil -Value $c.pem -Encoding Ascii
certutil -addstore Disallowed $fil
if ($LASTEXITCODE -ne 0) { throw "Importen misslyckades för $($c.sha256)" }
Remove-Item $fil
}
För många datorer: spara de 16 certifikaten som filer och importera dem i grupprinciper under Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Untrusted Certificates. Testa sedan i Edge på testsidan.
3. Linux och macOS. Installera distributionens uppdaterade certifikatpaket, oftast ca-certificates. Tillfälliga lösningar för distributioner som inte är uppdaterade och för macOS inbyggda /usr/bin/curl finns på sidan.
4. Integrationer och CI/CD. Ta reda på vilken lista över rotcertifikat varje integration använder: operativsystemets, Python certifi, ett Java-keystore eller en fil som följer med programmet. Uppdatera den, starta om processen och testa från samma miljö. Go-program ska byggas om med en uppdaterad Go-version. Börja med CI/CD och installationsskript (curl | sh), eftersom de har tillgång till nycklar och token.
5. Utrustning. Fråga leverantören om firmwaren litar på någon av de tre rötterna ovan och när det kommer en uppdatering. Utrustning som inte får någon kan du isolera och begränsa till de anslutningar den behöver. Det minskar risken men åtgärdar inte felet. Kan risken inte accepteras, koppla bort enhetens anslutning till molnet.
Behöver ni byta era egna certifikat?
Bara om de är utfärdade av eMudhra, även under namnen CertiNext eller InCommon, med en kedja till emSign ECC Root CA - G3. Den roten tas bort ur Firefox och Chrome, och eMudhra flyttar kunderna till kedjor under RSA-roten emSign Root CA - G1, som inte tas bort. Kontrollera utfärdaren och fråga eMudhra om er kedja behöver ändras:
openssl s_client -connect www.example.se:443 </dev/null 2>/dev/null | openssl x509 -noout -issuer
Källor
- emudhra.we-have-a-problem.com: bevis, testsidor, uppdaterade versioner
- Mozilla Bugzilla 2083449: tidslinje, orsak och eMudhras svar
- Mozillas meddelande i dev-security-policy
- Mozilla Security Blog
- Ars Technica: Microsofts svar
- Scott Helme: Eight Bits of Trust: vad som är exponerat och test med ett förfalskat certifikat