De private nøgler til otte mellemudstedere (intermediate CA'er) fra den indiske CA eMudhra kan regnes ud af hvem som helst på under et sekund. Med dem kan man udstede certifikater til et hvilket som helst domæne, som klienter, der stadig stoler på kæden, godtager. Chrome, Firefox og Safari har blokeret dem. Edge på Windows 11 godtog dem stadig, da vi testede kl. 00.20 den 21-10-2026. API-integrationer, IoT-enheder, robotstøvsugere, fjernsyn, kameraer og andet udstyr, der taler med en cloud, kan være udsat til 2039, hvis de stoler på en af kæderne.

Den fulde gennemgang med bevis, testsider og patchede versioner: emudhra.we-have-a-problem.com

Browserne

Chrome og Firefox har blokeret mellemudstederne siden 17-10-2026 og Apple siden 19-10-2026, uden at brugeren skal gøre noget, så længe browseren har fået opdateringen (Mozilla). Mozilla og Chrome fjerner desuden hele eMudhras ECC-rod, emSign ECC Root CA - G3 (Bugzilla).

Chrome, Firefox og Safari godtager kun certifikater, der står i de offentlige Certificate Transparency-logs (Chrome, Firefox, Apple). Der er ikke fundet certifikater fra de otte mellemudstedere i CT-logs, så browsere, der kræver CT, er ikke blevet angrebet med dem i de 17 måneder, nøglerne var svage.

Det beskytter kun bagud. Nøglerne er nu offentligt kendt, og enhver kan indsende et falsk certifikat til CT-logs og få de kvitteringer (SCT'er), browserne kræver. CT tjekker ikke, hvem der ejer domænet, så angrebet bliver synligt bagefter, men browseren godtager certifikatet. Fremadrettet er det kun opdateringer, der blokerer mellemudstederne, som beskytter en browser. Testsiderne har netop den slags certifikater, og Edge på Windows 11 åbnede dem stadig i vores test. En Edge-installation, der stadig godtager kæden, kan angribes med et falsk certifikat til et hvilket som helst website af den, der kan komme ind på forbindelsen. Microsoft har ikke sagt, hvornår det bliver rettet (Ars Technica).

Alt det andet udstyr

Udstyr, der taler med en cloud, går ud fra, at serveren er den rigtige, når certifikatet passer med listen over rodcertifikater i enhedens firmware. Det gælder API-integrationer mellem systemer, IoT-enheder, robotstøvsugere, aircondition, fjernsyn, kameraer, routere og printere. Den slags tjekker sjældent CT eller tilbagetrækning (Scott Helme).

Så længe enheden ikke får en ny liste over rodcertifikater, kan den, der kommer imellem enheden og internettet, udgive sig for producentens cloud med et certifikat, enheden godtager. Det kan være på samme wifi, i en hacket router eller hos en internetudbyder. Kæderne virker:

  • til 31-12-2028, hvis enheden stoler på Sectigos gamle rod AAA Certificate Services
  • til 09-07-2039, knap 13 år, hvis den stoler på emSign ECC Root CA - G3
  • til 28-04-2040, hvis den stoler direkte på emSign Root TLS CA - G3, som Windows gør

Ét eksempel: ESP-IDF, som ESP32-chips i IoT-enheder bygges med, har emSign ECC Root CA - G3 med i sin standardliste. En enhed, der kun stoler på producentens eget certifikat, er ikke ramt.

Scott Helme lavede et falsk certifikat til api.stripe.com, og curl, Python og Node godtog det uden fejl (Scott Helme). Det er de samme biblioteker, der bruges i integrationer og CI/CD-pipelines.

En bivirkning for dem, der vil styre deres egne dimser

Det kan blive lettere at tage kontrol over sin egen robotstøvsuger, aircondition eller anden enhed, der kun vil tale med producentens cloud. Står man selv mellem enheden og internettet, kan enheden godtage en lokal server som producentens cloud, hvis den stoler på eMudhras certifikater. Det giver ikke i sig selv kontrol over enheden, og vi har ikke prøvet det på konkrete produkter. Det er samme teknik, en angriber bruger, og certifikaterne er til et domæne, man ikke ejer. Projekter som Valetudo har i årevis gjort robotstøvsugere fri af cloud ad andre veje.

Hvem er eMudhra

eMudhra er en børsnoteret indisk virksomhed fra Bangalore, grundlagt i 2008, med en omsætning på 7.016 mio. rupees, ca. 66 mio. euro, i regnskabsåret til 31-03-2026. Den er Indiens største udsteder af digitale signaturer, med ca. 38 % af markedet (eMudhras regnskabspræsentation).

TLS-certifikater er 6 % af eMudhras certifikatomsætning. Ca. 30.000 TLS-certifikater ligger under den rod, Mozilla og Chrome fjerner, og 97 % af dem er udstedt via ACME (Bugzilla). Uden for Indien sælger eMudhra under navnet CertiNext, og siden april 2026 leverer de certifikaterne i InCommon, den fælles certifikattjeneste for amerikanske universiteter.

Sectigo har cross-signet de berørte mellemudstedere under AAA Certificate Services. Det giver en ekstra vej til tillid, men det er eMudhras nøgler, der er svage. Sectigos egne nøgler er ikke ramt.

Hvad gik galt

En privat P-384-nøgle skal være et tilfældigt tal på 384 bit. De otte nøgler er tal mellem 4 og 237. Scott Helme regnede dem ud fra de offentlige certifikater på under et sekund ved at prøve tallene fra 1 og opefter, og Mozilla fik AI-agenter til at finde dem i første forsøg (Bugzilla).

Ifølge eMudhra lavede en fejl i scriptet ved nøgleceremonien 30-04-2025 et ekstra sæt svage nøgler i HSM'en, og de blev brugt ved en fejl, fordi navnene lignede de rigtige (Bugzilla). Fejlen kunne ses i maj 2025, hvor mellemudstedernes CRL'er havde ugyldige signaturer.

Test dit udstyr

Åbn testsiden i browseren. Den prøver selv at forbinde til 12 testsider med certifikater fra de kompromitterede mellemudstedere, via både eMudhras og Sectigos rod. "✅ Did not connect" ud for alle 12 og "connected to 0 of 12" nederst er det rigtige resultat. Står der "❌ Connected", stoler browseren på de brudte certifikater. Siden kan ikke skelne en certifikatfejl fra et netværk, der blokerer adressen, så test også fra et netværk uden filter.

For servere og integrationer, kørt fra den maskine eller container, integrationen kører i:

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

En certifikatfejl er det rigtige resultat. Åbner siden uden fejl, stoler klienten stadig på de kompromitterede mellemudstedere. En timeout eller DNS-fejl beviser ikke, at klienten er beskyttet.

Sådan retter du det

1. Opdater alt, der kan opdateres. Browsere, styresystemer og Docker-images, som skal bygges igen med de nye pakker. Ubuntu, Debian, Alpine, Arch, Gentoo, Go, Python certifi, pip og curls CA-bundle er opdateret. Fedora, FreeBSD, Node.js og Bun mangler stadig. Se den aktuelle tabel på siden.

2. Windows: bloker certifikaterne selv. Indtil Microsoft opdaterer, kan du lægge alle 16 certifikater (otte nøgler, hver i to udgaver, også de to til code signing) i Windows' lager for certifikater uden tillid. Kør PowerShell som administrator:

$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 fejlede for $($c.sha256)" }
    Remove-Item $fil
}

Til mange maskiner: gem de 16 certifikater som filer, og importer dem i Group Policy under Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Untrusted Certificates. Test bagefter i Edge på testsiden.

3. Linux og macOS. Installer distributionens opdaterede certifikatpakke, typisk ca-certificates. Midlertidige løsninger for distributioner, der ikke er opdateret, og for macOS' indbyggede /usr/bin/curl står på siden.

4. Integrationer og pipelines. Find ud af, hvilken liste over rodcertifikater hver integration bruger: styresystemets, Python certifi, et Java-keystore eller en fil, der følger med programmet. Opdater den, genstart processen, og test fra samme miljø. Go-programmer skal bygges igen med en opdateret Go-version. Start med CI/CD og installationsscripts (curl | sh), fordi de har adgang til nøgler og tokens.

5. Udstyr. Spørg leverandøren, om firmwaren stoler på en af de tre rødder ovenfor, og hvornår der kommer en opdatering. Udstyr, der ikke får en, kan du isolere og begrænse til de forbindelser, det har brug for. Det mindsker risikoen, men retter ikke fejlen. Kan risikoen ikke accepteres, så afbryd enhedens forbindelse til cloud.

Skal jeres egne certifikater skiftes?

Kun hvis de er udstedt af eMudhra, også under navnene CertiNext eller InCommon, med en kæde til emSign ECC Root CA - G3. Den rod fjernes fra Firefox og Chrome, og eMudhra flytter kunderne til kæder under RSA-roden emSign Root CA - G1, som ikke fjernes. Se udstederen, og spørg eMudhra, om jeres kæde skal ændres:

openssl s_client -connect www.example.dk:443 </dev/null 2>/dev/null | openssl x509 -noout -issuer

Kilder