Kompromittierte CA-Schlüssel bei eMudhra: Was Unternehmen jetzt prüfen und beheben sollten

Am Samstag, dem 17. Oktober 2026, meldete ein Sicherheitsforscher, dass acht Intermediate-CAs der indischen Zertifizierungsstelle eMudhra private Schlüssel hatten, die jeder aus den öffentlichen Zertifikaten berechnen konnte. Jeder dieser Schlüssel war eine Zahl kleiner als 256. Einer davon war die Zahl 4. Sechs der acht konnten TLS-Zertifikate ausstellen, denen Apple, Google, Microsoft und Mozilla vertrauen; die anderen beiden konnten Windows-Software signieren.

Chrome sperrte die sechs TLS-Schlüssel eine Stunde und vierzig Minuten nach der Meldung, Firefox am selben Abend. Für alle, die im Browser surfen, war die Gefahr bis Samstagnacht gebannt.

Für alles andere nicht. Server, Container, Java-Anwendungen, Python-Skripte, Zahlungsintegrationen und vernetzte Geräte prüfen Zertifikate gegen ihre eigene Kopie der Liste vertrauenswürdiger Zertifizierungsstellen, und die meisten dieser Kopien ändern sich erst, wenn jemand ein Update installiert. Bis dahin gilt ein mit einem dieser Schlüssel signiertes Zertifikat für eine beliebige Domain als echt, und die Schlüssel sind seit dem 20. Oktober öffentlich.

In derselben Woche begann GoDaddy, 404.607 Zertifikate zu widerrufen, weil die Policy-Angaben darin nicht mit den eigenen veröffentlichten Dokumenten übereinstimmten. Die Kunden mussten die Ersatzzertifikate selbst herunterladen und installieren.

Dieser Leitfaden richtet sich an alle, die die Frage „Sind wir betroffen?“ beantworten müssen: IT- und Betriebsverantwortliche, CTOs und Gründer, deren Geschäft auf einer Website, einer API oder einem vernetzten Produkt läuft. Er beschreibt, was passiert ist (auf Grundlage der Vorfallsberichte, die Mozilla, Google, eMudhra, GoDaddy und die Softwarehersteller veröffentlicht haben), was Sie heute prüfen sollten, was Sie diese Woche aktualisieren sollten und was Sie einrichten sollten, damit der nächste Vorfall dieser Art Routine ist. Alle Angaben entsprechen dem Stand vom 22. Oktober 2026, und der Vorfall ist noch nicht abgeschlossen.

Was passiert ist

eMudhra erzeugte die acht Intermediate-CAs bei einer Schlüsselzeremonie am 30. April 2025. Die Darstellung des Unternehmens, am 19. Oktober in Mozillas Bug-Eintrag zum Vorfall veröffentlicht: Ein Test eines Schritts zum Ver- und Entpacken von Schlüsseln (Key Wrap und Unwrap), der als Abweichung vom üblichen Verfahren genehmigt worden war, hatte einen Fehler, durch den im Hardware-Sicherheitsmodul neben den vorgesehenen Schlüsseln ein zweiter, schwacher Satz Schlüssel entstand. Die Bezeichnungen ähnelten sich, die schwachen Schlüssel wurden versehentlich für die Zertifikatsanforderungen verwendet, und das Root-Zertifikat von eMudhra signierte sie. Dieselben Anforderungen gingen an Sectigo, das am 14. Mai 2025 alle acht mit seinem Root-Zertifikat AAA Certificate Services cross-signierte. eMudhra erklärt, es habe „die genaue Ursache noch nicht bestätigt“.

Mozilla beschrieb das Ergebnis so: „Private P384-Schlüssel sind zufällig gewählte ganze Zahlen zwischen 1 und der Gruppenordnung. Die 8 betroffenen Schlüssel verwendeten alle ganze Zahlen kleiner als 256.“ Mozilla erhielt die Meldung um 20:06 UTC und ermittelte die Schlüssel um 21:48 selbst, „ohne jede Kenntnis der Methode, die der ursprüngliche Melder verwendet hat“. Der Forscher gibt an, er habe sie mit Googles Open-Source-Bibliothek paranoid_crypto gefunden, „im Auslieferungszustand“. Die schwachen Schlüssel waren fast 18 Monate lang Teil öffentlich vertrauenswürdiger Zertifikatsketten.

Die acht Zertifikate:

Jeder Schlüssel steckt in zwei Zertifikaten. Eines wurde von eMudhras emSign Root TLS CA - G3 oder emSign Root CS CA - G3 ausgestellt, die ihrerseits auf emSign ECC Root CA - G3 zurückgehen; das andere ist Sectigos Cross-Zertifikat von AAA Certificate Services. Der zweite Pfad ist wichtig, weil manche Trust Stores, die nie ein Root-Zertifikat von eMudhra enthielten, diesem alten Root-Zertifikat von Sectigo weiterhin vertrauen.

Wurde jemand angegriffen?

Niemand hat einen Missbrauch gemeldet, und für Browser gibt es gute Gründe anzunehmen, dass es keinen gab. Chrome akzeptiert, wie andere Clients, die Certificate Transparency (CT) durchsetzen, ein Zertifikat nur, wenn es in den öffentlichen CT-Logs verzeichnet ist. Laut Google wurden vor der Sperre keine TLS-Zertifikate geloggt, die auf diese sechs Intermediate-CAs zurückgehen, sodass „keine von diesen CAs ausgestellten betrügerischen Zertifikate gegen Clients hätten eingesetzt werden können, die CT durchsetzen“.

Außerhalb des Browsers sieht es anders aus. Mozillas Seite zum Vorfall: „Viele Clients außerhalb des Browser-Ökosystems setzen Certificate Transparency nicht durch. Wir wissen nicht, ob Angreifer die fehlerhafte Schlüsselerzeugung ausgenutzt haben, um diese Clients anzugreifen.“ Dieses Zeitfenster öffnete sich im Frühjahr 2025 und schließt sich für jeden Client erst, wenn er aktualisiert wird. eMudhra gibt an, keine Hinweise darauf zu kennen, dass die Schlüssel vor der Offenlegung ermittelt wurden, und Cloudflare erklärt, seine Prüfung habe keine aktive Ausnutzung in den eigenen Diensten ergeben.

Da die Schlüssel jetzt öffentlich sind, ist das Fälschen eines Zertifikats keine Kunst mehr. Mozillas Seite zum Vorfall nennt Testserver, die mit den kompromittierten Schlüsseln ausgestellte Zertifikate ausliefern, damit jeder seine Clients dagegen prüfen kann (die Befehle folgen weiter unten).

Was ein gefälschtes Zertifikat ermöglicht: Wer den Datenverkehr zwischen Ihrer Software und einem von ihr aufgerufenen Dienst abfangen kann (in einem geteilten Netz, über einen kompromittierten Router oder eine manipulierte DNS-Antwort), kann sich als dieser Dienst ausgeben, mitlesen, was Ihre Software sendet, API-Schlüssel und personenbezogene Daten eingeschlossen, und verändern, was sie empfängt. Software, die mit einem der beiden Codesignatur-Schlüssel signiert wurde, hätte die Signaturprüfung von Windows bestanden, bis Microsofts Sperre den Rechner erreichte.

Wer betroffen ist

Es gibt drei getrennte Probleme, und ein Unternehmen kann alle drei haben.

1. Software, die den kompromittierten Schlüsseln noch vertraut

Dieses Problem hat fast jedes Unternehmen: jedes Programm, das HTTPS-Aufrufe macht, dessen Trust Store noch emSign ECC Root CA - G3 oder AAA Certificate Services enthält und das noch keine Sperre für die acht Schlüssel erhalten hat. Typische Stellen:

• Linux-Server und Container-Images, die vor dem 20. oder 21. Oktober gebaut wurden. Ein ungepatchtes Debian 12 etwa vertraut beiden Ketten.
• Laufzeitumgebungen von Programmiersprachen, die eine eigene Liste mitbringen: Node.js, certifi für Python, cacerts von Java, das Composer-Bundle für PHP, webpki-roots für Rust.
• Kommandozeilenwerkzeuge unter macOS. Mozillas Seite zum Vorfall schreibt, dass die vorinstallierten curl, git, python3, perl, ruby und openssl Zertifikate gegen /etc/ssl/cert.pem prüfen, ohne den Widerrufsstatus zu prüfen, und dass Apple diese Datei nicht aktualisiert hat.
• Windows-Rechner, die Microsofts automatische Updates der Liste nicht vertrauenswürdiger Zertifikate nicht erhalten, meist weil eine Gruppenrichtlinie sie abschaltet oder das Netz offline ist.
• Appliances, Geräte und Software von Drittanbietern, die eine eigene CA-Datei mitbringen, etwa Load Balancer, VPN-Gateways, SDKs und eingebettete Steuerungen.

Jede Laufzeitumgebung muss einzeln geprüft werden. In einem eigenen Test am 22. Oktober akzeptierte ein ungepatchter Debian-12-Rechner mit Node.js 24.18 die Kette, die beim Root-Zertifikat von eMudhra endet, und lehnte die ab, die bei dem von Sectigo endet, während Python auf demselben Rechner beide akzeptierte.

2. Unternehmen, deren eigene Zertifikate auf das entfernte Root-Zertifikat zurückgehen

Mozilla und die Linux-Distributionen haben emSign ECC Root CA - G3 entfernt, Chrome folgt am 27. Oktober. Gültige Zertifikate unter diesem Root-Zertifikat funktionieren in jedem Client nicht mehr, sobald er aktualisiert wird. Googles Anweisung: Website-Betreiber mit solchen Zertifikaten „müssen umgehend ein neues TLS-Zertifikat aus einer anderen PKI-Hierarchie beschaffen und installieren, die im Chrome Root Store enthalten ist“.

Chrome zählte am 21. Oktober in CT etwa 30.800 nicht abgelaufene Zertifikate unter diesem Root-Zertifikat. 30.791 davon stammten von zwei Intermediate-CAs von InCommon, dem Zertifikatsdienst, den Internet2 für US-Universitäten und Forschungseinrichtungen betreibt und der ECC-Zertifikate über CERTInext ausstellt, die Plattform von eMudhra. 18 stammten von eMudhras eigenen Intermediate-CAs. eMudhra zufolge müssen etwa 30.000 Zertifikate migriert werden, davon etwa 97 % über ACME ausgestellt, und das Unternehmen stellt nach eigenen Angaben Ersatzzertifikate aus einer anderen Hierarchie aus.

Wenn Ihre Website hinter Cloudflare im Modus Full (strict) läuft und der Origin-Server ein Zertifikat unter diesem Root-Zertifikat ausliefert, würde der Vertrauensentzug laut Cloudflare „zu Ausfällen führen“; Cloudflare bittet Kunden: „Überprüfen Sie Ihre benutzerdefinierten Origin-Zertifikate und Serverkonfigurationen“.

RSA-Zertifikate von eMudhras anderem Root-Zertifikat, emSign Root CA - G1, sind bisher nicht betroffen. Mozilla erklärt, dieses Root-Zertifikat „zum jetzigen Zeitpunkt“ nicht zu entfernen; Chrome „untersucht eingehend den weiteren Verbleib der übrigen CA-Zertifikate von eMudhra“. Wenn Sie auf Zertifikate von eMudhra oder CERTInext gleich welcher Art angewiesen sind, sorgen Sie jetzt für eine zweite Zertifizierungsstelle.

3. GoDaddy-Kunden

Der Fall GoDaddy hat nichts mit eMudhra zu tun, fiel aber in dieselbe Woche und traf viel mehr Websites. Am 15. Oktober meldete GoDaddy bei Mozilla, dass Zertifikate aus seinen Hierarchien GoDaddy und Starfield Angaben zur Zertifikats-Policy (Policy-OIDs und CPS-Links) enthielten, die nicht zu den Profilen in der eigenen CP/CPS passten, dem Dokument, in dem eine Zertifizierungsstelle festlegt, was sie ausstellt. Das ist keine Sicherheitslücke in den Zertifikaten. Nach den Baseline Requirements, den Regeln, an die sich jede öffentliche Zertifizierungsstelle hält, ist es trotzdem ein Grund, sie innerhalb von fünf Tagen zu widerrufen.

Betroffen waren 404.607 Zertifikate, davon 396.055 domänenvalidiert. GoDaddy widerrief 170.566 bis zur Frist am 18. Oktober, 23:45 UTC, und 227.422 bis zum nächsten Morgen; laut der Kundeninformation wurden die übrigen am 21. Oktober widerrufen. GoDaddy stellt die Zertifikate neu aus, die Installation liegt aber beim Kunden: „Besucher Ihrer Website sehen möglicherweise Sicherheitswarnungen, und Ihre Website ist unter Umständen nicht erreichbar, bis ein neues Zertifikat installiert ist.“

Was Sie heute prüfen sollten

1. Was senden Ihre eigenen Server? Listen Sie für jeden öffentlichen Hostnamen die Aussteller in der Kette auf, die er ausliefert:

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

Nennt eine Zeile eMudhra, emSign, eine der Zertifizierungsstellen EM ... G3B oder G3C oder InCommon Intermediate CA - DVG3C, OVG3C oder EVG3C, muss das Zertifikat vor dem 27. Oktober ersetzt werden. AAA Certificate Services allein ist normal, da viele gewöhnliche Sectigo-Ketten es noch enthalten. Für Mail- und Verzeichnisdienste ergänzen Sie -starttls smtp (oder imap, ldap) und den passenden Port. Beziehen Sie interne Hosts, Load Balancer und Origin-Server hinter einem CDN ein.

2. Was wurde für Ihre Domains ausgestellt? CT verzeichnet jedes Zertifikat, das eine öffentliche Zertifizierungsstelle für Ihre Namen ausgestellt hat, auch solche, an deren Bestellung sich im Unternehmen niemand erinnert:

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

Die Ausgabe zeigt auch, welche Zertifizierungsstellen Ihr Unternehmen tatsächlich nutzt, und ist damit der Anfang des weiter unten beschriebenen Inventars.

3. Vertrauen Ihre Clients den kompromittierten Schlüsseln? Mozillas Testserver liefern Zertifikate aus, die mit den kompromittierten Schlüsseln ausgestellt wurden, ein Zertifikatsfehler ist also das gute Ergebnis. Testen Sie beide Familien: Der erste Host führt zum Root-Zertifikat von eMudhra, der zweite zu dem von Sectigo, und ein Trust Store kann den einen Test bestehen und am anderen scheitern.

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 gibt nur Auskunft über curl. Führen Sie dieselbe Anfrage über den eigenen TLS-Stack jeder Anwendung aus, in der Umgebung, in der die Anwendung läuft:

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')"

Die beiden Python-Zeilen sind nicht doppelt: urllib nutzt den Trust Store des Betriebssystems, requests nutzt certifi. Wiederholen Sie jede Zeile mit dem Host dv-g3b-aaa-emudhra. Für Java rufen Sie die Testserver aus der betreffenden JVM per HTTPS auf und lassen auflisten, ob deren Trust Store eines der beiden Root-Zertifikate enthält (Java 9 oder neuer; unter Java 8 verwenden Sie -keystore $JAVA_HOME/jre/lib/security/cacerts):

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

Ein Root-Zertifikat im Trust Store beweist für sich allein noch keine Gefährdung, denn Go, Node.js, Deno und rustls-webpki für Rust sperren die acht Schlüssel inzwischen unabhängig vom Inhalt des Trust Stores. Die Testserver schaffen Klarheit.

4. Windows-Rechnerflotten. Microsoft hat zu dem Vorfall nichts veröffentlicht, aber die Liste nicht vertrauenswürdiger Zertifikate, die Windows automatisch herunterlädt, sperrt seit dem 20. Oktober alle acht Schlüssel. Ausnahmen sind Rechner, auf denen eine Gruppenrichtlinie die automatische Aktualisierung der Root-Zertifikate abschaltet, und Netze ohne Verbindung zu Windows Update; dort muss die Liste auf anderem Weg ankommen. certutil -verifyCTL Disallowed zeigt die Kopie, die ein Rechner zwischengespeichert hat. Mozillas Seite zum Vorfall bietet ein Skript für einzelne Rechner an und schreibt, es sei „für Geräte, die von Unternehmen verwaltet werden, nicht empfohlen“.

5. GoDaddy-Zertifikate. Prüfen Sie, welches Zertifikat jeder Server tatsächlich ausliefert:

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

Ist der Aussteller GoDaddy oder Starfield, vergleichen Sie die Seriennummer mit den Zertifikaten in Ihrem GoDaddy-Konto. Wo GoDaddy „Install your new certificate“ (Neues Zertifikat installieren) anzeigt, hat der Server noch das widerrufene.

Eine Regel gilt durchgehend: Beseitigen Sie einen Fehler nicht, indem Sie die Zertifikatsprüfung abschalten. Cloudflare formuliert es so: „Es ist wichtig, diese Fehler nicht durch Deaktivieren der Prüfung zu beheben.“ Ein Client, der nicht prüft, vertraut jedem gefälschten Zertifikat, nicht nur diesen.

Was Sie diese Woche aktualisieren sollten

Es gibt zwei Arten, das Problem zu beheben. Das Entfernen der beiden Root-Zertifikate schließt jeden Pfad für einen Client, der diesen Trust Store nutzt, macht aber auch die gültigen Zertifikate darunter unbrauchbar. Das Sperren der acht Schlüssel über den Hash ihres öffentlichen Schlüssels, wie es Go, Node.js, Deno, Electron, rustls-webpki, Composer und Windows tun, schließt die Lücke und macht sonst nichts kaputt. Wo Ihre Plattform die zweite Variante anbietet, ziehen Sie sie vor.

„Noch kein“ und „noch nicht“ heißen: Bis zum 22. Oktober war nichts veröffentlicht. Prüfen Sie erneut, bevor Sie Ihre Planung darauf aufbauen.

An vier Stellen stolpern Teams immer wieder:

• Container-Images behalten die alte Liste. Ein Image, das vor dem 20. oder 21. Oktober gebaut wurde, vertraut den Schlüsseln, bis es auf einem aktualisierten Basis-Image neu gebaut wird, und das erneute Pullen desselben Tags hilft erst, wenn das Basis-Image neu gebaut wurde. Bauen Sie neu, deployen Sie neu, und fragen Sie die Anbieter, deren Images Sie betreiben.
• Prozesse behalten, was sie geladen haben. Ein Programm liest seinen Trust Store beim Start, starten Sie lang laufende Dienste nach dem Update also neu. Node.js weist zusätzlich darauf hin, dass TLS-Sitzungen, die aus der Zeit vor dem Upgrade wiederaufgenommen werden, nicht erneut geprüft werden.
• Anwendungen bringen eigene CA-Dateien mit. SDKs und Anwendungen liefern oft eine eigene cacert.pem oder ca-bundle.crt mit. Durchsuchen Sie Repositories und Images danach, zum Beispiel mit find / -xdev \( -name 'cacert*.pem' -o -name 'ca-bundle*.crt' \) 2>/dev/null, und rechnen Sie mit mehr als einer: pip etwa bringt seine eigene Kopie von certifi mit.
• Geräte warten auf ihren Hersteller. Fragen Sie jeden Hersteller schriftlich, welchen Trust Store das Produkt nutzt und wann das Update erscheint. Bis dahin vertraut das Gerät gefälschten Zertifikaten für jeden Dienst, den es aufruft; schränken Sie also ein, was es erreichen kann.

Wenn Sie AAA Certificate Services von Hand entfernen, wie es Debian, Ubuntu ESM, Fedora und der Workaround von Red Hat tun, testen Sie danach die Verbindungen zu Diensten mit Sectigo-Zertifikaten: Manche älteren Server senden noch eine Kette, die bei diesem Root-Zertifikat endet.

Was vor dem nächsten Vorfall stehen sollte

Dass eine Zertifizierungsstelle so schwache Schlüssel in Umlauf bringt, kommt selten vor. Massenwiderrufe nicht. Das sind die großen des Jahres 2026, die in Mozillas Bugtracker verzeichnet sind:

Keiner dieser fünf Fälle war ein Sicherheitsversagen. In jedem widersprach ein Zertifikat dem eigenen Dokument der Zertifizierungsstelle, und die Baseline Requirements (Abschnitt 4.9.1.1) verlangen trotzdem den Widerruf innerhalb von fünf Tagen. Ist ein Schlüssel kompromittiert oder ist auf die Domainvalidierung kein Verlass, beträgt die Frist 24 Stunden. Niemand kann sie für Sie verlängern. Beim Widerruf von 83.267 Zertifikaten durch DigiCert im Jahr 2024 schrieb das Chrome Root Program, es habe „nicht die Befugnis, Ausnahmen zu gewähren“; ein Kunde erwirkte eine gerichtliche Anordnung, die den Widerruf seiner Zertifikate stoppen sollte, und die Anordnung wurde vier Tage später aufgehoben.

Wie der Austausch verlief, sagt viel. Im Juli nutzte HARICA ACME Renewal Information (ARI), um den ACME-Clients seiner Kunden eine vorzeitige Erneuerung zu signalisieren, und stellte andere Zertifikate selbst neu aus; beim größeren seiner beiden Widerrufe waren bei Fristende 87 % der betroffenen Namen ersetzt. GoDaddy, dessen Kunden jeden Ersatz selbst herunterladen und installieren, hatte bis zu seiner Frist 42 % der betroffenen Zertifikate widerrufen.

Der Erneuerungszyklus wird ohnehin kürzer:

• Nach dem Ballot SC-081 des CA/Browser Forum sind öffentliche TLS-Zertifikate seit dem 15. März 2026 auf 200 Tage begrenzt. Die Grenze sinkt am 15. März 2027 auf 100 Tage und am 15. März 2029 auf 47 Tage; ab dann lässt sich eine Domainvalidierung nur noch 10 Tage lang wiederverwenden.
• Let's Encrypt stellt den Standard am 10. Februar 2027 auf Zertifikate mit 64 Tagen Laufzeit um und ein Jahr später auf 45 Tage.
• Öffentliche TLS-Zertifikate verlieren die Client-Authentifizierung. Let's Encrypt stellt sie seit dem 8. Juli 2026 nicht mehr aus, und das Chrome Root Program verlangt, dass ab dem 15. März 2027 ausgestellte Zertifikate nur noch der Server-Authentifizierung dienen. Wenn Sie öffentliche Zertifikate als Client-Zertifikate für Mutual TLS nutzen, was bei B2B-API-Integrationen verbreitet ist, brauchen diese Verbindungen eine private Zertifizierungsstelle.

Bei 100 Tagen und später bei 47 ist die manuelle Installation von Zertifikaten keine realistische Option mehr. Wer für diesen Takt automatisiert, ist auch für den nächsten Massenwiderruf gerüstet. Was das erfordert:

1. Wissen, was Sie haben, in beide Richtungen. Eine Liste aller Zertifikate, die Sie ausliefern, mit Hostname, Aussteller, Ablaufdatum, Erneuerungsweg und Verantwortlichem. Eine zweite Liste aller Trust Stores, auf die sich Ihre Software verlässt: das Paket des Betriebssystems, jedes Bundle einer Programmiersprache, jede CA-Datei in einer Anwendung oder einem Gerät. Die CT-Suche oben ist der Anfang der ersten Liste, eine Software-Stückliste (SBOM) oder ein Abhängigkeitsinventar der Anfang der zweiten.
2. Ausstellung und Installation automatisieren. ACME überall, wo es laufen kann, mit ARI (RFC 9773), damit eine Zertifizierungsstelle Ihren Clients eine vorzeitige Erneuerung signalisieren kann. Wo ein Gerät kein ACME ausführen kann, nutzen Sie die Automatisierung des Herstellers oder terminieren TLS davor auf etwas, das es kann.
3. Eine zweite Zertifizierungsstelle bereithalten. Ein funktionierendes, getestetes ACME-Konto bei einer zweiten Zertifizierungsstelle und CAA-Einträge im DNS, die beide erlauben. Wenn einer Zertifizierungsstelle das Vertrauen entzogen wird oder sie massenhaft widerruft, ist der Wechsel eine Konfigurationsänderung.
4. CT für Ihre Domains überwachen. Lassen Sie sich bei jedem neuen Zertifikat für Ihre Namen alarmieren. So erfahren Sie von einer unerwarteten Ausstellung noch am selben Tag.
5. Trust Stores als Abhängigkeiten behandeln. Aktualisieren Sie sie über das normale Patching und bauen Sie Images nach Zeitplan neu, nicht nur bei Codeänderungen.
6. Das Runbook für die beiden Fristen schreiben. 24 Stunden und fünf Tage: Wer entscheidet, wer Zugang zu welchem System hat, welche Systeme manuelle Schritte brauchen, wie jeder Hersteller erreichbar ist. Üben Sie es einmal im Jahr, indem Sie das Zertifikat eines Dienstes tauschen, der einen Fehler verkraftet. Öffentliche Zertifizierungsstellen müssen seit 2025 einen eigenen Plan für Massenwiderrufe vorhalten und testen; ihre Kunden brauchen die andere Hälfte.

Wenn Sie Produkte herstellen, die andere betreiben

Wenn Ihr Produkt einen Trust Store enthält (ein Gerät, eine installierte Anwendung, ein SDK), sind Ihre Kunden erst geschützt, wenn Ihr Update sie erreicht. Liefern Sie es aus und sagen Sie Ihren Kunden, welche Versionen korrigiert sind. Mozillas Rat an Betreiber von Trust Stores: die acht Intermediate-CAs sperren, wenn Ihre Software das kann, andernfalls „prüfen, ob es angemessen ist, den Root-Zertifikaten, die diese Intermediate-CAs signiert haben, das Vertrauen zu entziehen“.

Der Cyber Resilience Act greift hier auf zwei Arten. Seine Meldepflicht, die seit dem 11. September 2026 gilt, betrifft aktiv ausgenutzte Schwachstellen, und in diesem Fall wurde keine Ausnutzung gemeldet. Zu seinen grundlegenden Anforderungen, die ab dem 11. Dezember 2027 gelten, gehört, dass sich Schwachstellen durch Sicherheitsupdates beheben lassen; ein Produkt, dessen Trust Store sich nicht aktualisieren lässt, würde sie nicht erfüllen. Kunden, die unter NIS2 fallen, werden ihre Lieferanten fragen, wie schnell sie das erledigt haben, und es hilft, die Antwort schriftlich parat zu haben.

Was noch offen ist

• Das verbleibende Root-Zertifikat von eMudhra. Chrome hat eMudhra am 21. Oktober zwölf Fragen gestellt und keine Entscheidung zu emSign Root CA - G1 bekanntgegeben. Mozilla entfernt es „zum jetzigen Zeitpunkt“ nicht.
• Der Migrationsweg von eMudhra. Gegenüber Mozilla erklärte das Unternehmen, es werde Kunden auf seine G1-Hierarchie (RSA) umziehen; seine Statusseite spricht von „einer alternativen, unabhängig betriebenen, öffentlich vertrauenswürdigen CA-Hierarchie“. Chrome hat gefragt, welche.
• Microsoft und Apple. Keiner der beiden hat eine Stellungnahme veröffentlicht oder eines der beiden Root-Zertifikate aus seinem Trust Store entfernt.
• Ausstehende Fixes. Red Hat, Amazon Linux, Temurin und Corretto hatten bis zum 22. Oktober nichts ausgeliefert; der Fix für Bun war gemergt, aber nicht veröffentlicht.
• Die Ursache. eMudhra hat sie nicht bestätigt und angekündigt, jede bisher durchgeführte Schlüsselzeremonie erneut zu überprüfen.
• Sectigo. In einem separaten Fall, der seit dem 5. September offen ist, hat Sectigo es abgelehnt, Zertifikate zu widerrufen, deren Extended Key Usage nicht zu einem Satz in seiner CPS passte, mit dem Argument, der Satz sei mehrdeutig. Am 18. Oktober zählte Sectigo noch etwa 72 Millionen davon als aktiv. Einige Teilnehmer der öffentlichen Diskussion haben einen Vertrauensentzug gefordert; kein Root-Programm hat eine Entscheidung bekanntgegeben. Unternehmen mit Sectigo-Zertifikaten sollten den Fall verfolgen.

Wo Sie Hilfe bekommen

Ein Zertifikatsproblem gibt sich selten als solches zu erkennen. Es zeigt sich als Checkout, der nicht mehr lädt, als Integration, die nicht mehr synchronisiert, oder als Gerät, das sich nicht mehr meldet, meist am Wochenende. Wir helfen Unternehmen, Wochen wie diese ohne Ausfall zu überstehen, und richten die Dinge so ein, dass die nächste Routine ist:

• Eine Bestandsaufnahme der Gefährdung. Wir finden heraus, wo Ihre Systeme TLS-Verbindungen aufbauen oder annehmen, welchen Trust Store jedes davon nutzt und welche Zertifikate Sie ausliefern, einschließlich Containern, Java-Diensten, Integrationen mit Banken, Zahlungs- und Logistikdienstleistern sowie Geräten.
• Die Korrekturen. Updates, neu gebaute Images, gesperrte Schlüssel oder ersetzte Zertifikate, umgesetzt über Ihren Change-Prozess und gegen Mozillas Testserver bestätigt.
• Automatisierung für 2027. ACME mit ARI auf Servern, Load Balancern und Appliances, eine zweite Zertifizierungsstelle, CAA-Einträge, CT-Monitoring und ein Runbook, bereit für Zertifikate mit 100 Tagen Laufzeit ab dem 15. März 2027.
• Die Systeme, die niemand anfassen will. Alte Java-Anwendungen, Appliances und eingebettete Clients mit eigenen Trust Stores sind genau das, wofür unsere Wartung von Bestandssystemen da ist.

Wenn Sie nicht sicher sind, ob Sie betroffen sind, schreiben Sie an office@c9group.dev mit den Domains und Plattformen, die Sie betreiben, oder buchen Sie ein Gespräch. Wir sagen Ihnen, was Sie zuerst prüfen sollten.