eMudhra-hændelsen: Otte CA-nøgler var lette at gætte – det skal indehavere af TLS-certifikater kontrollere nu

6. november 2026  |  Certifikater  |  IT-sikkerhed

I oktober 2026 kom det frem, at den indiske certifikatudsteder eMudhra havde udstedt otte mellemliggende certifikater (Intermediate CAs) med praktisk talt værdiløse private nøgler. De private nøgler var heltal mindre end 256, og en af dem var bogstaveligt talt tallet 4. Enhver, der kender sådan en nøgle, kan underskrive certifikater for vilkårlige domæner på certifikatudstederens vegne. Browserproducenterne reagerede derfor inden for få timer, blokerede de mellemliggende certifikater og fjernede den tilhørende rod-CA emSign ECC Root CA – G3 fra deres tillidslister.

Denne artikel forklarer præcis, hvad der skete, hvorfor en nøgle med værdien »4« er en total sikkerhedsbrist, hvem der er berørt – og hvem der ikke er – samt hvad administratorer af websteder, mailservere og firewalls bør kontrollere nu. Vi holder os nøje til det, primærkilderne dokumenterer. I den første omtale og på sociale medier cirkulerer der også fremstillinger, som ikke er korrekte. Mere om det om lidt.

Kort fortalt: Hvad er korrekt, og hvad er ikke?

Hændelsesforløbet

• 17. Oktober 2026: Der Vorfall wird an Mozilla gemeldet (Eingang 18:05 UTC laut Bugzilla). Bereits um 22:59 UTC ist die Sperre der Zwischenzertifikate über Mozillas OneCRL verteilt, also in weniger als drei Stunden nach Eingang der Meldung bei Mozilla.
• 18. oktober 2026: eMudhra tilbagekalder de otte mellemliggende certifikater.
• 19. oktober 2026: Sectigo tilbagekalder de krydscertifikater, som virksomheden havde brugt til at medunderskrive de otte mellemliggende CA'er.
• 20. oktober 2026: Mozilla udgiver Firefox 158.0.1, ESR 115.43.1 og ESR 153.5.1 samt NSS 3.131.1. Dermed fjernes rod-CA'en emSign ECC Root CA – G3. Mellem den 20. og 21. oktober dukker der desuden 107.107 certifikater op i Certificate Transparency-loggene, som er signeret med seks af de otte svage nøgler (se nedenfor).
• 22. oktober 2026: eMudhra meddeler, at virksomheden vil trække sig fra markedet for offentlige TLS-certifikater. Kodesignering og S/MIME fortsætter under separate rod-CA'er.
• 27. oktober 2026: Chrome fjerner også rod-CA'en.
• 16. og 30. november 2026: Frister for de ældre G1-certifikater (henholdsvis Chrome/Mozilla og Apple), som ifølge eMudhra er relevante for overgangen for den berørte amerikanske kundesammenslutning.

Hvorfor en privat nøgle med værdien »4« er en total sikkerhedsbrist

En certifikatudsteder (CA) bekræfter med sin digitale signatur, at et certifikat tilhører et domæne. Browsere stoler på denne signatur, så længe CA'en står på deres tillidsliste. Sikkerheden bygger på, at kun CA'en kender den private nøgle.

Ved certifikater med elliptiske kurver (ECDSA) er den private nøgle et meget stort tal d. Den offentlige nøgle er et punkt Q = d · G på kurven (G er det fastlagte basispunkt). At beregne tallet d ud fra Q er praktisk talt umuligt, når der er tale om et tilfældigt valgt tal på 384 bit. Men hvis d er lille, for eksempel 4, er det nok at beregne 1·G, 2·G, 3·G, 4·G … efter hinanden og sammenligne med det offentlige punkt. Det tager sekunder og kræver ingen specialviden.

Den offentlige nøgle står i hvert certifikat og er dermed synlig for alle. Derfor kan enhver, der efterregner den, oprette certifikater, der ser gyldige ud, på CA'ens vegne – for vilkårlige domæner, så længe en browser stadig stoler på CA'en. Det er netop derfor, Mozilla og andre straks blokerede dem.

Vi har hentet de otte mellemliggende certifikater, der er nævnt i Bugzilla, fra de offentlige transparenslogs (crt.sh) ved hjælp af deres SHA-256-fingeraftryk. For hvert certifikat har vi sammenlignet k · G for k = 1 til 1000 med det offentlige punkt. Alle otte certifikater har en P-384-nøgle, og alle otte gav et match:

Værdierne stemmer overens med oplysningerne i Bugzilla og i mediedækningen (bl.a. The Register: en af nøglerne skulle være »bogstaveligt talt 4«). Vi har hverken signeret eller udstedt noget med disse værdier. Beregningen er udelukkende en kontrol af offentlige certifikater.

Årsagen ifølge eMudhra

Ifølge eMudhras redegørelse i Bugzilla opstod de svage nøgler under en nøgleceremoni den 30. april 2025. Her blev der gennemført en wrap/unwrap-test som led i en godkendt afvigelse fra den normale procedure. En fejl i koden skulle have medført, at der blev genereret endnu et nøglepar med svage nøgler i enheden. Dette skulle så ved en fejl være blevet brugt til at oprette certifikatanmodningen, fordi nøglernes betegnelser lignede hinanden. Certifikaterne blev derefter udstedt, optaget på tillidslister og lå der i over et år, indtil fejlen blev opdaget offentligt.

Ifølge The Register opdagede sikkerhedsforskeren Scott Helme nøglen »4«. De primærkilder, vi har gennemgået, beskriver ikke, hvilken metode der førte til opdagelsen. Alle kan dog kontrollere for små nøgleværdier ud fra offentlige certifikater.

Hvem er berørt – og hvem er ikke?

Kæden består af tre niveauer: rod-CA, mellemliggende CA og webstedets eller serverens slutcertifikat. Det var det midterste niveau, der var berørt. Det betyder:

• Certifikatindehavernes nøgler (din servernøgle) er ifølge alle de kilder, vi har til rådighed, ikke berørt. De skal ikke udskiftes med den begrundelse, at de skulle være »kendte«.
• Certifikater, hvis kæde går via den fjernede rod-CA, accepteres ikke længere af browsere. De skal udskiftes, fordi tillidskæden er brudt, ikke fordi servernøglen er svag. Ifølge analysen fra Chrome Root Program (pr. 21.10.2026) drejer det sig om cirka 30.800 stadig gyldige certifikater. 30.791 af dem blev udstedt af underordnede CA'er hos Internet2/InCommon, en amerikansk sammenslutning, der primært betjener universiteter og forskningsinstitutioner. eMudhra omtaler én enkelt kundesammenslutning i USA.
• Alle andre eMudhra-kunder er ifølge eMudhra ikke berørt. Digitale signaturer, eSign, emSigner, CertiNext, SecurePass, PrivaTrust og emCA fortsætter på separat infrastruktur.

For kunder i Tyskland, Østrig og Schweiz er sandsynligheden for at bruge et certifikat under denne rod-CA derfor lille. Du kan kun være sikker, hvis du kontrollerer det. Det tager få minutter, se tjeklisten.

De 107.107 certifikater i transparensloggene

Efter tilbagekaldelsen dukkede der ifølge Bugzilla mellem den 20. og 21. oktober 2026 107.107 certifikater op i Certificate Transparency-loggene, som var signeret med seks af de otte svage nøgler. Blandt dem er der dokumenterede proof of concept-certifikater, eksempelvis med google.com som navn. De fleste af dem går via Sectigos krydscertifikater, som i mellemtiden er blevet tilbagekaldt.

Det viser to ting: For det første kunne fejlen udnyttes med det samme af enhver med grundlæggende viden om kryptografi. For det andet viser det værdien af transparensloggene, hvor sådanne udstedelser bliver synlige for alle. Om nogen af certifikaterne er blevet misbrugt uden for tests, fremgår ikke af de kilder, vi har til rådighed, og det påstår vi heller ikke.

Hvad browserproducenterne og certifikatudstederne har gjort

Mozilla geht nach eigener Aussage in der Diskussion auf dev-security-policy nicht davon aus, dass andere Zertifizierungsstellen betroffen sind.

Tjekliste: Det bør du kontrollere nu

1. Find ud af, hvem der har udstedt dine certifikater. På en hvilken som helst computer med OpenSSL:

   openssl s_client -connect ihre-domain.example:443 -servername ihre-domain.example </dev/null 2>/dev/null | openssl x509 -noout -issuer -dates

   Hvis udstederen er eMudhra eller emSign (f.eks. »EM DV TLS CA – G3B« eller »G3C«), skal du kontrollere hele kæden og rod-CA'en med -showcerts. Går kæden via emSign ECC Root CA – G3, skal certifikatet udskiftes.
2. Gennemgå alle tjenester, ikke kun webstedet. Mailservere (SMTPS, IMAPS), VPN-gateways, firewallbrugerflader, load balancere, interne tjenester, enheder og appliances med egne certifikater.
3. Se de offentlige certifikater for dit domæne. Via crt.sh (søg efter %.ihre-domain.example) kan du se alle certifikater, der er udstedt til dit domæne, også dem, du ikke kender til. Det er en god anledning til at opdage uønskede udstedelser.
4. Udskift berørte certifikater. Hos en anden, etableret CA eller via ACME (f.eks. Let’s Encrypt). Generér samtidig en ny servernøgle. Hændelsen gør det ikke obligatorisk, men det er under alle omstændigheder god praksis, når du skifter CA.
5. Kontrollér tillidslagrene på dine egne enheder. Hvis du har tilføjet eMudhras rod-CA fast i egne enheder, Java-keystores, containere eller certifikatsamlinger, bør du fjerne den derfra. Browsere opdaterer selv deres tillidslagre, men det gør disse installationer ikke.
6. Opdatér Firefox. Blokeringerne er inkluderet fra version 158.0.1 og ESR 115.43.1 / 153.5.1. Kontrollér på centralt administrerede computere, at opdateringerne bliver installeret.
7. Automatisér. Hvis du administrerer certifikater manuelt, bør du skifte til automatisk fornyelse (ACME). Så kræver et skift af CA blot en konfigurationsændring frem for en akut indsats.

Hvad vi kan lære af det

• Valget af CA er en beslutning om risiko. Det afgørende er gennemsigtighed, kvaliteten af processerne og deltagelse i rodprogrammerne. Prisen siger intet om det. Hændelsen viser en procesfejl under en nøgleceremoni, som kunne forekomme hos enhver CA.
• Certificate Transparency virker. De offentligt tilgængelige logs gjorde det muligt hurtigt at afgrænse hændelsen og identificere de 107.107 certifikater.
• Kryptografisk agilitet betaler sig. Hvis du fornyer certifikater automatisk og kan skifte CA uden at skulle ændre snesevis af systemer manuelt, kan du håndtere sådanne hændelser med én dags arbejde i stedet for en uge.
• Overvåg dine domæner. Overvågning af transparensloggene (f.eks. via crt.sh eller tjenester med e-mailnotifikationer) viser, når nogen udsteder certifikater til dit domæne.
• Flere lag af beskyttelse. TLS-certifikater er kun ét lag. CAA-poster i DNS (de bestemmer, hvilke CA'er der må udstede certifikater til dit domæne) og login med tofaktorgodkendelse giver yderligere beskyttelse. Læs mere i vores artikel Beskyt Odoo 19: Firewall, 2FA & Web RBL.

Ofte stillede spørgsmål

Hvad skete der præcis hos eMudhra?

Otte mellemliggende certifikater fra certifikatudstederen eMudhra havde private nøgler, som var heltal mindre end 256 (en af dem var tallet 4). Dermed kunne enhver beregne den private nøgle ud fra det offentlige certifikat og underskrive certifikater, der så gyldige ud. De mellemliggende CA'er blev tilbagekaldt, og rod-CA'en emSign ECC Root CA – G3 blev fjernet fra Firefox (20.10.2026) og Chrome (27.10.2026).

Har eMudhra udleveret den private nøgle »4« til kunder?

Nej. De svage nøgler tilhørte certifikatudstederens egne mellemliggende certifikater. Det var ikke kundenøgler, og de blev ikke udleveret til kunder. At der blev påstået noget andet på sociale medier, ændrer ikke på det.

Skal jeg som eMudhra-kunde straks udskifte mit certifikat?

Kun hvis dit TLS-certifikats kæde går via rodcertifikatet emSign ECC Root CA – G3. Ifølge eMudhra berører det en enkelt amerikansk kundegruppe med omkring 30.800 certifikater. Ifølge eMudhra behøver alle andre kunder ikke at foretage sig noget. Kontrollér, hvem der har udstedt dit certifikat, før du handler.

Hvordan kan jeg se, om mit certifikat er berørt?

Det kan du se på udstederen og certifikatkæden: Se certifikatet i browseren, eller brug OpenSSL-kommandoen fra tjeklisten. Navne som »EM DV TLS CA – G3B«, »EM OV TLS CA – G3C« eller »emSign ECC Root CA – G3« peger på den berørte kæde.

Skal jeg udskifte min private servernøgle?

Ikke på grund af denne hændelse. Ifølge kilderne er servernøglen ikke berørt. Hvis certifikatet skal udskiftes, anbefales det dog også at oprette en ny nøgle.

Kan angribere oprette falske certifikater til mit domæne?

Med de otte nøgler var det teknisk muligt at signere certifikater til vilkårlige domæner. Det virkede kun, så længe browserne havde tillid til kæden. Efter Mozillas og Chromes blokeringer er det ikke længere muligt i opdaterede browsere. På enheder, der ikke opdateres, eller hvor rodcertifikatet er fast indbygget, kan risikoen bestå i længere tid. Overvåg derfor certifikaterne til dit domæne.

Er certifikater fra Let’s Encrypt eller andre certifikatudstedere berørt?

Ikke ifølge de offentliggjorte kilder. Mozilla vurderer ikke, at andre certifikatudstedere er berørt.

Hvad betyder det, at eMudhra trækker sig ud af TLS-markedet?

eMudhra udsteder ikke længere nye offentlige TLS-certifikater. Kodesignering, S/MIME, digitale signaturer og eSign fortsætter. Hvis du hidtil har fået TLS-certifikater fra eMudhra, skal du finde en ny udbyder.

Er Odoo berørt?

Selve Odoo er ikke berørt. Men som for alle webapplikationer gælder det, at TLS-certifikatet til dit Odoo-domæne bør komme fra en betroet certifikatudsteder. Kontrollér udstederen, især hvis certifikaterne ikke fornys automatisk.

Kilder

Tilgået den 6. november 2026:

• Mozilla Bugzilla, fejlrapport 2083449 (hændelsesrapport, tidslinje, certifikatfingeraftryk): bugzilla.mozilla.org/show_bug.cgi?id=2083449
• Mozilla Security Blog, 20.10.2026: Beskyttelse af Firefox-brugere efter kompromitteringen af eMudhras mellemliggende certifikater
• eMudhra, udtalelse: emudhra.com/en/post/certificate-security-incident
• The Register, 20.10.2026: Den indiske certifikatudsteder eMudhras private nøgler kompromitteret – en af dem var tallet 4
• Mozilla dev-security-policy: Diskussionstråd om hændelsen
• Søgning i Certificate Transparency: crt.sh

Beregningen af de otte nøgleværdier er vores egen efterregning baseret på offentlige certifikater. Oplysninger om årsagen, om at der ikke blev udstedt slutcertifikater, og om antallet af berørte kunder stammer fra eMudhra eller Bugzilla og er ikke blevet verificeret uafhængigt af os.

Hjælp fra Biricon IT Services

Hvis du er i tvivl om, hvem der har udstedt dine TLS-certifikater, hjælper vi gerne med at kortlægge alle certifikater på webservere, mailservere, firewalls og appliances, skifte til en anden certifikatudsteder, gå over til automatisk fornyelse (ACME) og overvåge dine domæner. Som IT-serviceleverandør administrerer vi servere, firewalls og webapplikationer for små og mellemstore virksomheder.

Kontakt os nu

Stand: 6. November 2026. Die Lage kann sich ändern; maßgeblich sind die Veröffentlichungen von Mozilla, Google, Apple und eMudhra.