Stand: 29. Oktober 2026 Mozilla verteilte die Sperrung der betroffenen eMudhra-Zwischenzertifikate in Firefox über OneCRL innerhalb von weniger als drei Stunden. Für andere Anwendungen kündigte Mozilla zusätzlich ein Update der NSS-Vertrauensliste an. Server, Container und Laufzeitumgebungen sollten deshalb separat auf betroffene Zertifikatsketten und Trust Stores geprüft werden. Zur Einordnung von Mozilla. Was bedeutet der eMudhra-Vorfall für das Zertifikatsmanagement? Zertifikatsmanagement entscheidet im Krisenfall darüber, ob ein Unternehmen betroffene TLS-Zertifikate schnell findet, ersetzt und in allen Systemen ausrollt. Beim eMudhra-Vorfall im Oktober 2026 wurden die privaten Schlüssel von acht Intermediate-CA-Zertifikaten kompromittiert. Mit ihnen hätten Angreifer gefälschte TLS-Zertifikate für fremde Domains ausstellen können. Mozilla blockierte die betroffenen Zwischenzertifikate in Firefox über OneCRL innerhalb von weniger als drei Stunden.Für Betreiber endet die Aufgabe nicht mit einer Browser-Sperre. Server, Container-Images, Laufzeitumgebungen, Appliances und Anwendungen können eigene Trust Stores oder Zertifikatsketten verwenden. Wer im Ernstfall nicht weiß, welche Systeme die betroffene CA nutzen, kann den Austausch weder sicher priorisieren noch vollständig verifizieren.Der eMudhra-Fall ist kein Beleg dafür, dass jede Zertifizierungsstelle unsicher ist. Er ist ein konkreter Stresstest für Inventar, Abhängigkeiten und Wechselprozesse. Zugleich werden die maximalen Laufzeiten öffentlich vertrauenswürdiger TLS-Serverzertifikate stufenweise kürzer. Was das für Ihre Erneuerungsprozesse bedeutet, zeigen die folgenden Schritte. Antworten auf häufige Fragen zu Zertifikatsmanagement und TLS-Laufzeiten. Ähnliche Fragen zur Reaktionsfähigkeit behandeln wir auch im Beitrag zu PHP2Shell und Patchprozessen. Sechs Bausteine für belastbares Zertifikatsmanagement Bei eMudhra / Für Sie: Was der Vorfall für Ihre Prozesse bedeutet 01 Zertifikate vollständig inventarisieren Bei eMudhra: Ein schneller Austausch setzt voraus, dass betroffene Aussteller und Zertifikatsketten in den eigenen Umgebungen auffindbar sind. Für Sie: Führen Sie ein aktuelles Inventar mit Aussteller, Seriennummer oder Fingerprint, Gültigkeit, Verwendungszweck, Speicherort, Systemverantwortung und abhängigen Diensten. Ergänzen Sie automatisierte Erkennung, damit auch vergessene Zertifikate sichtbar werden. 02 Erneuerung und Rollout automatisieren Bei eMudhra: Ein kompromittierter Aussteller erfordert mehr als das Ausstellen eines Ersatzes: Das neue Zertifikat muss auf allen betroffenen Systemen ankommen und dort funktionieren. Für Sie: Automatisieren Sie Ausstellung, Erneuerung und Deployment, wo Protokolle und Plattformen es unterstützen, etwa mit ACME oder CA-Schnittstellen. Überwachen Sie den gesamten Ablauf bis zum erfolgreichen Reload und Verbindungstest, nicht nur das Ausstellungsdatum. 03 Ausweichoptionen realistisch bewerten Bei eMudhra: Ein weiterer Anbieter hilft nur, wenn Zertifikate, Vertrauenskette und Integrationen tatsächlich kurzfristig umgestellt werden können. Für Sie: Bewerten Sie alternative CAs nach Kompatibilität, Richtlinien, Root-Store-Verteilung, Vertragslage und erreichbarem Support. Mehr als eine CA kann Abhängigkeiten reduzieren, erhöht aber auch Betriebs- und Governance-Aufwand. 04 Den CA-Wechsel üben Bei eMudhra: Wenn eine CA gesperrt oder nicht mehr vertrauenswürdig ist, genügt es nicht, auf das Ablaufdatum zu warten. Betroffene Zertifikate müssen identifiziert und ersetzt werden. Für Sie: Üben Sie einen Wechsel der Zertifizierungsstelle inklusive Re-Issuance, Verteilung, Widerruf, Reload und Verifikation. Halten Sie fest, wie Sie Abhängigkeiten priorisieren und welche Übergangsschritte im Notfall zulässig sind. 05 Ablaufdaten und Trust Stores überwachen Bei eMudhra: Browser, Betriebssysteme und Anwendungen beziehen Vertrauen nicht zwingend aus derselben Quelle oder zum selben Zeitpunkt. Für Sie: Überwachen Sie Ablaufdaten, CA- und Browser-Mitteilungen sowie Änderungen an Root- und Intermediate-Listen. Beziehen Sie Container-Images, Java- oder andere Laufzeit-Trust-Stores, Appliances und kundenspezifische Bundles in die Prüfung ein. 06 Zuständigkeiten und Eskalation festlegen Bei eMudhra: Ein koordinierter Vertrauensentzug betrifft PKI, Plattformbetrieb, Security und häufig auch externe Dienstleister. Für Sie: Benennen Sie Verantwortliche für Entscheidung, Freigabe, Rollout und Kommunikation. Legen Sie Eskalationswege und Erreichbarkeit fest und dokumentieren Sie, wer im Ernstfall Zertifikate tauschen oder Dienste kontrolliert einschränken darf. Kürzere TLS-Laufzeiten: Was sich tatsächlich ändert Der CA/Browser Forum-Ballot SC-081v3 verkürzt stufenweise die zulässige Laufzeit öffentlich vertrauenswürdiger TLS-Serverzertifikate. Für Zertifikate, die ab dem jeweiligen Stichtag ausgestellt werden, gilt nach dem Zeitplan: höchstens 200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029. Auch die Wiederverwendung von Domain-Validierungsdaten wird bis 2029 auf 10 Tage begrenzt. Wichtig für die Einordnung: Das ist keine pauschale Laufzeitvorgabe für jedes Zertifikat in jeder internen PKI. Der Geltungsbereich der TLS Baseline Requirements betrifft Zertifikate für Server, die über das Internet erreichbar sind. Interne Zertifikate folgen den dafür geltenden Richtlinien, Verträgen und Sicherheitsanforderungen. Mit jedem Schritt steigt die Zahl der Erneuerungsvorgänge. Eine Tabellenliste und einzelne Kalendererinnerungen werden bei vielen Systemen fehleranfällig. Certificate Lifecycle Management (CLM) verbindet Erkennung, Richtlinien, Ausstellung, Erneuerung, Verteilung, Widerruf und Monitoring zu einem kontrollierbaren Prozess. Automatisierung ersetzt dabei weder eine sichere CA noch einen Notfallplan: Wird ein Aussteller kompromittiert oder aus Trust Stores entfernt, müssen betroffene Zertifikate weiterhin schnell ersetzt und die Änderungen in den jeweiligen Laufzeitumgebungen verifiziert werden. CA/Browser Forum: Ballot SC-081v3 · TLS Baseline Requirements, Version 2.1.8 Zertifikatsmanagement im Detail Antworten zum eMudhra-Vorfall und zu kürzeren TLS-Laufzeiten Was passiert, wenn eine Zertifizierungsstelle kompromittiert wird? Kann eine CA oder eines ihrer Zwischenzertifikate nicht mehr als vertrauenswürdig gelten, müssen Betreiber zunächst feststellen, ob Systeme die betroffene Zertifikatskette verwenden. Danach folgen je nach Fall Sperrung, Ersatz durch eine vertrauenswürdige CA, Ausrollen der neuen Zertifikate und Tests in allen relevanten Clients und Laufzeitumgebungen. Beim eMudhra-Vorfall blockierte Mozilla die betroffenen Intermediate-Zertifikate in Firefox über OneCRL in weniger als drei Stunden; andere Trust Stores und Softwarepakete mussten separat berücksichtigt werden. Welche TLS-Zertifikate sind ab 2029 nur noch 47 Tage gültig? Die 47-Tage-Grenze aus dem CA/Browser Forum-Ballot SC-081v3 gilt ab dem 15. März 2029 für neu ausgestellte, öffentlich vertrauenswürdige TLS-Serverzertifikate. Die vorangehenden Stufen sind 200 Tage ab dem 15. März 2026 und 100 Tage ab dem 15. März 2027. Die Vorgabe gilt nicht automatisch für jedes interne Zertifikat einer privaten PKI. Wie hilft Certificate Lifecycle Management beim CA-Wechsel? Certificate Lifecycle Management schafft Transparenz darüber, wo Zertifikate liegen und wovon sie abhängen. Es kann Erneuerung und Deployment automatisieren, Ablauf- und Trust-Änderungen überwachen und den Austausch dokumentierbar machen. Ein CA-Wechsel sollte trotzdem geübt werden: Erst ein Ende-zu-Ende-Test zeigt, ob Ersatzketten auf allen Systemen funktionieren. Zielbild Was ein CLM-Ansatz abdecken sollte Ein belastbarer CLM-Prozess verbindet Technik, Zuständigkeiten und überprüfbare Abläufe. Diese Punkte sollten im Zielbild zusammenkommen: Inventar und Verantwortlichkeit Erfassen Sie Aussteller, Gültigkeit, Ketten, Speicherorte und Verantwortliche zentral und gleichen Sie den Bestand regelmäßig mit der tatsächlichen Infrastruktur ab. Erneuerung und Deployment Automatisieren Sie Erneuerung und Bereitstellung dort, wo CA und Plattform es unterstützen. Axians beschreibt die Zertifikatsverwaltung als Teil der Application-Security-Leistung für F5-Umgebungen. Mehr erfahren Integration in die Infrastruktur Testen Sie neue Zertifikate in Load Balancern, Webservern, Plattformen und Anwendungen. Überwachen Sie Reloads, Ketten und tatsächliche Verbindungen. Notfallwechsel und Prüfung Definieren Sie Abläufe für Sperrung, Ersatz, Rollback und Kommunikation. Üben Sie den CA-Wechsel, bevor Sie im Vorfall auf die Probe gestellt werden. Unsere Einschätzung Der Vorfall war kein flächendeckender Ausfall für Browsernutzer: Mozilla verteilte die Sperrung schnell, und heise online ordnete das unmittelbare Risiko für Endanwender als gering ein. Diese Einordnung darf jedoch nicht auf jede Server- und Laufzeitumgebung übertragen werden. Dort unterscheiden sich Trust Stores, Updatewege und Verantwortlichkeiten. Die strategische Lehre liegt deshalb nicht in pauschalem Misstrauen gegenüber CAs, sondern in der Fähigkeit, einen Ausstellerwechsel kontrolliert zu bewältigen. Kürzere Laufzeiten erhöhen den operativen Takt für öffentlich vertrauenswürdige TLS-Zertifikate. Sie machen Inventar und Automatisierung wichtiger, verhindern aber weder fehlerhafte Schlüsselprozesse noch ersetzen sie Sperrung, sichere CA-Governance oder einen geübten Notfallplan. Für IT-Leitung, Plattformteams und PKI-Verantwortliche lautet die Leitfrage: Wissen Sie, welche Zertifikate Sie einsetzen, welche Systeme ihnen vertrauen und wie schnell Sie die komplette Kette austauschen können? Quellen Mozilla Security Blog: Protecting Firefox users following the compromise of eMudhra intermediate certificates, 20. Oktober 2026 heise online: CA-Zertifikate gesperrt – Sicherheitsvorfall bei eMudhra, 20. Oktober 2026; aktualisiert am 21. Oktober 2026 CA/Browser Forum: Ballot SC-081v3, 11. April 2025 CA/Browser Forum: TLS Baseline Requirements, Version 2.1.8 Wie gut ist Ihr Zertifikatswechsel vorbereitet? Wir unterstützen Sie dabei, Zertifikate und Abhängigkeiten einzuordnen, Erneuerungsprozesse zu automatisieren und den Wechsel Ihrer TLS-Zertifikate in der Infrastruktur zu prüfen. Gespräch zum Zertifikatsmanagement vereinbaren. < Zurück zur Übersicht
01 Zertifikate vollständig inventarisieren Bei eMudhra: Ein schneller Austausch setzt voraus, dass betroffene Aussteller und Zertifikatsketten in den eigenen Umgebungen auffindbar sind. Für Sie: Führen Sie ein aktuelles Inventar mit Aussteller, Seriennummer oder Fingerprint, Gültigkeit, Verwendungszweck, Speicherort, Systemverantwortung und abhängigen Diensten. Ergänzen Sie automatisierte Erkennung, damit auch vergessene Zertifikate sichtbar werden.
02 Erneuerung und Rollout automatisieren Bei eMudhra: Ein kompromittierter Aussteller erfordert mehr als das Ausstellen eines Ersatzes: Das neue Zertifikat muss auf allen betroffenen Systemen ankommen und dort funktionieren. Für Sie: Automatisieren Sie Ausstellung, Erneuerung und Deployment, wo Protokolle und Plattformen es unterstützen, etwa mit ACME oder CA-Schnittstellen. Überwachen Sie den gesamten Ablauf bis zum erfolgreichen Reload und Verbindungstest, nicht nur das Ausstellungsdatum.
03 Ausweichoptionen realistisch bewerten Bei eMudhra: Ein weiterer Anbieter hilft nur, wenn Zertifikate, Vertrauenskette und Integrationen tatsächlich kurzfristig umgestellt werden können. Für Sie: Bewerten Sie alternative CAs nach Kompatibilität, Richtlinien, Root-Store-Verteilung, Vertragslage und erreichbarem Support. Mehr als eine CA kann Abhängigkeiten reduzieren, erhöht aber auch Betriebs- und Governance-Aufwand.
04 Den CA-Wechsel üben Bei eMudhra: Wenn eine CA gesperrt oder nicht mehr vertrauenswürdig ist, genügt es nicht, auf das Ablaufdatum zu warten. Betroffene Zertifikate müssen identifiziert und ersetzt werden. Für Sie: Üben Sie einen Wechsel der Zertifizierungsstelle inklusive Re-Issuance, Verteilung, Widerruf, Reload und Verifikation. Halten Sie fest, wie Sie Abhängigkeiten priorisieren und welche Übergangsschritte im Notfall zulässig sind.
05 Ablaufdaten und Trust Stores überwachen Bei eMudhra: Browser, Betriebssysteme und Anwendungen beziehen Vertrauen nicht zwingend aus derselben Quelle oder zum selben Zeitpunkt. Für Sie: Überwachen Sie Ablaufdaten, CA- und Browser-Mitteilungen sowie Änderungen an Root- und Intermediate-Listen. Beziehen Sie Container-Images, Java- oder andere Laufzeit-Trust-Stores, Appliances und kundenspezifische Bundles in die Prüfung ein.
06 Zuständigkeiten und Eskalation festlegen Bei eMudhra: Ein koordinierter Vertrauensentzug betrifft PKI, Plattformbetrieb, Security und häufig auch externe Dienstleister. Für Sie: Benennen Sie Verantwortliche für Entscheidung, Freigabe, Rollout und Kommunikation. Legen Sie Eskalationswege und Erreichbarkeit fest und dokumentieren Sie, wer im Ernstfall Zertifikate tauschen oder Dienste kontrolliert einschränken darf.
Inventar und Verantwortlichkeit Erfassen Sie Aussteller, Gültigkeit, Ketten, Speicherorte und Verantwortliche zentral und gleichen Sie den Bestand regelmäßig mit der tatsächlichen Infrastruktur ab.
Integration in die Infrastruktur Testen Sie neue Zertifikate in Load Balancern, Webservern, Plattformen und Anwendungen. Überwachen Sie Reloads, Ketten und tatsächliche Verbindungen.
Notfallwechsel und Prüfung Definieren Sie Abläufe für Sperrung, Ersatz, Rollback und Kommunikation. Üben Sie den CA-Wechsel, bevor Sie im Vorfall auf die Probe gestellt werden.