Mozilla von Firefox folgt Google und misstraut den TLS-Zertifikaten von Entrust

Kurz gesagt: Mozilla hat die Vertrauenswürdigkeit von Entrust-TLS-Root-Zertifikaten, die nach dem 30. November 2024 ausgestellt wurden – einen Monat nach dem Stichtag bei Google Chrome am 11. November 2024 – aufgrund jahrelanger, ungelöster Compliance-Probleme eingestellt. Entrust verkaufte später sein gesamtes Geschäft mit öffentlichen Zertifikaten an Sectigo; der Verkauf wurde am 18. September 2025 abgeschlossen. Organisationen, die noch Entrust-Zertifikate verwenden, sollten jetzt migrieren und die Lebenszyklusverwaltung automatisieren.

Entrust war jahrzehntelang eine der etablierten Zertifizierungsstellen im Internet und genoss das Vertrauen von rund 10 % der Fortune-500-Unternehmen beim Schutz ihrer wichtigsten Webseiten. Das änderte sich 2024. Google Chrome und Mozilla Firefox entfernten Entrust nach jahrelangen, ungelösten Compliance-Problemen aus ihren Root-Trust-Stores. Die Folgen waren damit aber noch nicht absehbar: 2025 verkaufte Entrust sein gesamtes Geschäft mit öffentlichen Zertifikaten an Sectigo. Für alle Organisationen, die noch von Entrust ausgestellte Zertifikate in ihrer Umgebung nutzen oder verstehen möchten, wie eine Zertifizierungsstelle das Vertrauen der Browser verliert, bietet dieses Dokument einen umfassenden Überblick über die aktuelle Lage.

Executive Summary

Entrust verlor das Vertrauen der Browser schrittweise: Google Chrome stellte die Ausstellung neuer Entrust-Zertifikate am 11. November 2024 ein, Apple folgte am 15. November 2024 und Mozilla Firefox am 30. November 2024. Alle drei begründeten dies mit jahrelangen, ungelösten Compliance-Verstößen und nicht mit einem einzelnen Vorfall. Entrust verkaufte daraufhin sein gesamtes Geschäft mit öffentlichen Zertifikaten an Sectigo und schloss den Übergang am 18. September 2025 ab. Derselbe zugrunde liegende Druck – eine Branche, die sich von der Toleranz gegenüber langsamer, manueller Zertifikatsverwaltung abwendet – treibt auch die Abstimmung SC-081v3 des CA/Browser Forums an . Diese sieht eine schrittweise Reduzierung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate auf 200 Tage im März 2026, 100 Tage im März 2027 und 47 Tage im März 2029 vor. Laut der DigiCert Trust Pulse Survey vom Juli 2025 hatten 45 % der Unternehmen im vergangenen Jahr zertifikatsbedingte Ausfallzeiten, wobei 37.5 % davon auf ein abgelaufenes Zertifikat zurückzuführen waren (Quelle: DigiCert Trust Pulse Survey, Juli 2025 ). Organisationen, die Ende 2024 nicht schnell beantworten konnten, welche ihrer Zertifikate von Entrust stammen, werden auch 2029 mit den 47-tägigen Erneuerungszyklen zu kämpfen haben. Beide Probleme lassen sich auf dieselbe Lücke in der Zertifikatserkennung und -automatisierung zurückführen.

Direkt zu: Wichtigste Erkenntnisse | Zeitleiste | Auswirkungen nach Rolle | Checkliste zur Vorbereitung | Migrationsplan | Wie EC helfen kann | FAQ

Wichtige Erkenntnisse

• Mozilla Firefox vertraut seit dem 30. November 2024 keinen Entrust TLS-Zertifikaten mehr, also einen Monat nach dem Stichtag bei Google Chrome am 11. November 2024 und bei Apple Safari am 15. November 2024.
• Beide Browser nannten jahrelange, ungelöste Verstöße gegen die Compliance-Vorschriften, nicht einen einzelnen Vorfall, als Grund für das Misstrauen.
• Entrust verkaufte anschließend sein gesamtes öffentliches Zertifikatsgeschäft an Sectigo; die Transaktion wurde am 29. Januar 2025 angekündigt und am 18. September 2025 abgeschlossen.
• Akamai riet seinen Kunden, die Entrust-Ursprungszertifikate zu ersetzen und entfernte die Entrust- und AffirmTrust-Root-Zertifikate bis zum 1. März 2025 aus seinem Trust Store.
• Der im April 2025 verabschiedete Wahlvorschlag SC-081v3 des CA/B Forums verkürzt die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate auf 200 Tage bis zum 15. März 2026, auf 100 Tage bis zum 15. März 2027 und auf 47 Tage bis zum 15. März 2029, wodurch manuelle CA-Übergänge zunehmend unüberschaubar werden.
• Die DigiCert Trust Pulse Survey vom Juli 2025 ergab, dass 45 % der Unternehmen im vergangenen Jahr Ausfallzeiten im Zusammenhang mit Zertifikaten erlebten, und 37.5 % dieser Ausfälle ließen sich auf abgelaufene Zertifikate zurückführen.

Googles anfängliche Entscheidung, Entrust zu misstrauen

Im Juni 2024 kündigte Googles Chrome-Root-Programm als erstes an, Entrust nicht mehr als Zertifizierungsstelle (CA) zu vertrauen . Grund dafür waren besorgniserregende Verhaltensweisen, die über mehrere Jahre beobachtet worden waren. Zahlreiche Verstöße gegen die Compliance-Richtlinien hatten Googles Vertrauen in Entrusts Fähigkeit, die Anforderungen des Chrome-Root-Programms zu erfüllen, untergraben. Die Sperrung betrifft Entrust-Zertifikate mit einem frühesten Signed Certificate Timestamp (SCT) nach dem 11. November 2024, 11:59:59 Uhr UTC, und tritt mit Chrome-Version 131 in Kraft.

Mozillas Entscheidung, Entrust zu misstrauen

Ben Wilson, der Leiter des Mozilla-Root-Stores, erläuterte die Entscheidung in einem öffentlichen Beitrag im Mozilla-Entwicklerforum für Sicherheitsrichtlinien. Er merkte an, dass die Reaktion von Entrust trotz der erklärten Bemühungen des Unternehmens, die Probleme zu beheben, kein Vertrauen erweckt habe. Wilson betonte, dass sich der aktualisierte Bericht von Entrust nicht wesentlich von den Zusagen unterscheide, die das Unternehmen 2020 gemacht und später gebrochen habe.

Mozillas Entscheidung beruhte auf drei Faktoren:

• Wiederholte Verstöße gegen die Compliance-Vorschriften: Zwischen März und Mai 2024 verzeichnete Mozilla 22 separate Vorfälle im Zusammenhang mit Entrust, viele davon im Zusammenhang mit Verzögerungen und verpassten Fristen.
• Unzureichende Reaktion: Die Reaktion von Entrust auf Mozillas Bedenken zeigte keine wesentliche Änderung seiner Geschäftstätigkeit.
• Historischer Zusammenhang: Die von Entrust im Jahr 2020 gemachten Zusagen wurden nicht eingehalten, was Mozillas Vertrauen in die Reaktion im Jahr 2024 beeinträchtigte.

Zeitleiste von Entrust Distrau: Gültigkeitsdaten, Auswirkungen und Quellen

Die nachfolgende Tabelle listet alle bestätigten Meilensteine ​​des Misstrauens gegenüber Entrust auf, von den anfänglichen Browser-Abschaltungen über den Ausstieg von Entrust aus dem Geschäft mit öffentlichen Zertifikaten bis hin zum branchenweiten Übergang zu kürzeren Zertifikatslebensdauern.

Datum des Inkrafttretens	Anforderung	Wer ist betroffen?	Erforderliche Maßnahmen	Quelle
November 11, 2024	Google Chrome vertraut neuen Entrust TLS-Zertifikaten (SCT-Zertifikate, die nach diesem Stichtag ausgestellt wurden) nicht mehr.	Chrome-Nutzer ab Version 131 unter Windows, macOS, ChromeOS, Android und Linux	Ersetzen Sie jedes nach diesem Datum ausgestellte Entrust-Zertifikat.	Google Online-Sicherheitsblog
November 15, 2024	Apple misstraut neuen Zertifikaten von betroffenen Entrust-Stammzertifikaten.	Safari und andere Apple-Plattform-Nutzer	Bestätigen Sie, dass nach diesem Datum keine neuen, von Entrust ausgestellten Zertifikate auf dem Apple-Vertrauenszertifikat basieren.	DigiCert Entrust-Leitfaden zum Zertifikatsvertrauen
November 30, 2024	Mozilla Firefox vertraut neuen Entrust-TLS-Zertifikaten nicht mehr.	Firefox-Nutzer auf allen Plattformen sowie Nicht-Browser-Software, die auf den Mozilla-Truststore angewiesen ist.	Ersetzen Sie jedes nach diesem Datum ausgestellte Entrust-Zertifikat.	Ankündigung der Mozilla-Entwickler-Sicherheitsrichtlinie
1. März 2025	Akamai entfernt die Entrust- und AffirmTrust-Roots aus seinem Ursprungs-Truststore.	Akamai-Kunden, die Entrust-Zertifikate am Ursprung verwenden	Ursprungszertifikate müssen vor diesem Datum ersetzt werden.	Akamai-Kundenberatung
11. März 2025	Entrust stellt keine neuen öffentlichen TLS-Zertifikate mehr von seinen eigenen Stammzertifizierungsstellen aus.	Alle Entrust TLS-Zertifikatskunden	Beginnen Sie mit der Migration der Zertifikatsausstellung zu Sectigo.	Entrust TLS-Zertifikatsinformationszentrum
September 18, 2025	Entrust schließt die Übertragung seines Geschäfts mit öffentlichen Zertifikaten an Sectigo ab.	Alle verbleibenden Kunden mit öffentlichen Entrust-Zertifikaten	Vollständige Migration zu Sectigo für alle Vertragsverlängerungen	Entrust TLS-Zertifikatsinformationszentrum
15. März 2026	Das CA/B-Forum verkürzt die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate auf 200 Tage.	Alle Organisationen, die öffentlich zugängliche TLS-Zertifikate verwenden	Stellen Sie auf einen halbjährlichen Erneuerungszyklus um und evaluieren Sie die Automatisierung.	CA/B Forum Ballot SC-081v3 (via Sectigo)
15. März 2027	Die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate sinkt auf 100 Tage.	Alle Organisationen, die öffentlich zugängliche TLS-Zertifikate verwenden	Umstellung auf einen 3-monatigen Erneuerungsrhythmus	CA/B Forum Ballot SC-081v3 (via Sectigo)
15. März 2029	Die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate sinkt auf 47 Tage.	Alle Organisationen, die öffentlich zugängliche TLS-Zertifikate verwenden	Vollständige Automatisierung der Zertifikatsausstellung und -verlängerung	CA/B Forum Ballot SC-081v3 (via Sectigo)

Antwort von Akamai für Unternehmenskunden

Nach Googles Entscheidung veröffentlichte Akamai spezifische Empfehlungen für Kunden, die von Entrust ausgestellte Zertifikate verwenden . Akamai unterstützte die von Entrust ausgestellten Edge-Zertifikate auf seinem Secure CDN bis zu deren Ablaufdatum, empfahl jedoch, diese proaktiv zu ersetzen, um Unterbrechungen für Chrome-Clients zu vermeiden. Für Ursprungsverbindungen entfernte Akamai die Root- Zertifikate von Entrust und AffirmTrust bis zum 1. März 2025 aus seinem Truststore. Kunden, die die betroffenen Zertifikate bis zu diesem Datum nicht ersetzt hatten, riskierten Unterbrechungen des sicheren Datenverkehrs zu ihrer Ursprungsinfrastruktur.

Warum Browser Zertifizierungsstellen misstrauen

Die Rolle der Wirtschaftsprüfer und der Compliance

Zertifizierungsstellen (CAs) schaffen Vertrauen im Internet, indem sie Zertifikate ausstellen, die verschlüsselte Verbindungen zwischen Browsern und Websites ermöglichen. Um dieses Vertrauen zu erhalten, müssen CAs die strengen Branchenstandards der Baseline Requirements des CA/Browser (CA/B) Forums einhalten . Diese Standards umfassen:

• Validierungsprozesse: Ordnungsgemäße Validierung von Zertifikatsanfragen zur Bestätigung der Authentizität der anfragenden Entität.
• Betriebssicherheit: Robuste Sicherheitsmaßnahmen schützen die Infrastruktur der Zertifizierungsstelle und verhindern die unbefugte Ausstellung von Zertifikaten.
• Einhaltung der Protokolle: Einhaltung etablierter Protokolle für die Ausstellung, Verwaltung und Sperrung von Zertifikaten.

Prüfungen und Rechenschaftspflicht

Zertifizierungsstellen (CAs) werden durch regelmäßige, von unabhängigen Dritten durchgeführte Audits zur Rechenschaft gezogen. Diese Audits überprüfen die Einhaltung der Basisanforderungen des CA/B-Forums. Die Nichteinhaltung dieser Standards kann dazu führen, dass Browser den Zertifikaten einer CA vollständig misstrauen.

Der Entscheidungsprozess bei CA Misstrauen

Wenn ein Browser wie Google Chrome oder Mozilla Firefox beschließt, einer Zertifizierungsstelle (CA) nicht mehr zu vertrauen, durchläuft der Prozess typischerweise vier Phasen:

• Beweiserhebung: Untersuchung der Ausstellungsprozesse der Zertifizierungsstelle, der operativen Sicherheit und der Einhaltung von Branchenstandards anhand von Transparenzprotokollen, Foren und öffentlichen Bekanntmachungen.
• Bewertung anhand von Standards: Bewertung der Beweise anhand der Basisanforderungen des CA/B-Forums, um die Konformität festzustellen.
• Öffentliche Bekanntgabe und Reaktion: Die Ergebnisse werden der zuständigen Behörde und der Öffentlichkeit mitgeteilt, um der Behörde die Möglichkeit zu geben, zu reagieren und Korrekturmaßnahmen darzulegen.
• Endgültige Entscheidung: Abhängig von der Antwort der Zertifizierungsstelle und der Schwere der Probleme kann der Browser mit Misstrauen fortfahren, wenn die Antwort als unzureichend erachtet wird.

Die Auswirkungen von Misstrauen auf Unternehmen

Wird einer Zertifizierungsstelle das Vertrauen entzogen, werden alle von ihr ausgestellten Zertifikate vom betroffenen Browser nicht mehr als gültig anerkannt. Die praktischen Konsequenzen sind erheblich:

• Sicherheitswarnungen: Websites, die Zertifikate von der nicht vertrauenswürdigen Zertifizierungsstelle verwenden, zeigen Browserwarnungen an, die das Vertrauen der Benutzer untergraben und echte Sicherheitslücken aufdecken können.
• Compliance-Risiken: Organisationen, die es versäumen, nicht mehr vertrauenswürdige Zertifikate zu ersetzen, riskieren Verstöße gegen regulatorische Bestimmungen und Beanstandungen bei Audits.
• Betriebsstörungen: Der Austausch von Zertifikaten in großem Umfang kann zu Betriebsunterbrechungen, erhöhten Betriebskosten und einem erheblichen Personalaufwand führen.

Der detaillierte Mechanismus des CA-Misstrauens

1. Schadensbericht: Der Prozess beginnt mit der Erkennung und Meldung von Compliance-Vorfällen, die häufig von Sicherheitsforschern, anderen Zertifizierungsstellen oder automatisierten Überwachungssystemen aufgedeckt werden.
2. Erste Überprüfung: Das CA / B-Forum Oder das zuständige Team des Browser-Root-Stores führt eine erste Überprüfung durch. Schwerwiegende Vorfälle lösen eine gründlichere Untersuchung aus.
3. Ermittlung: Die Untersuchung befasst sich mit den Ausgabepraktiken der Zertifizierungsstelle, ihren Prüfberichten und ihrer allgemeinen Sicherheitslage.
4. Offenlegung: Die Ergebnisse werden veröffentlicht, und die zuständige Behörde erhält die Möglichkeit, darauf zu reagieren und Korrekturmaßnahmen darzulegen.
5. Bewertung der Antwort: Das Root-Store-Team des Browsers prüft, ob die Reaktion und die Korrekturmaßnahmen der Zertifizierungsstelle angemessen sind.
6. Misstrauensentscheidung: Falls die Antwort unzureichend ist, geht der Browser von Misstrauen aus und aktualisiert seinen Stammspeicher, um das Vertrauen in die Zertifizierungsstelle aufzuheben. Stammzertifikate.
7. Auswirkungen auf Zertifikate: Alle von der nicht vertrauenswürdigen Zertifizierungsstelle ausgestellten Zertifikate werden in diesem Browser ungültig, und betroffene Organisationen müssen sie durch Zertifikate einer vertrauenswürdigen Zertifizierungsstelle ersetzen.

Historischer Präzedenzfall: Das Symantec-Misstrauen

Das Misstrauen gegenüber Entrust erinnert an den Fall Symantec aus dem Jahr 2018. Google deckte mehrere Fälle unzulässiger Zertifikatsausstellung durch Symantec auf, was zu einer schrittweisen Aufhebung des Vertrauens in Symantec-Zertifikate in den gängigen Browsern führte. Dieser Prozess endete schließlich damit, dass Symantec sein Zertifizierungsstellengeschäft an DigiCert verkaufte – ein ähnliches Ergebnis erzielte Entrust sechs Jahre später mit dem Verkauf an Sectigo.

Das Gesamtbild: Kürzere Gültigkeitsdauern von Zertifikaten erhöhen den Druck.

Das Misstrauen gegenüber Entrust ist kein Einzelfall. Es ist ein Indiz für einen breiteren Trend hin zu kürzeren Zertifikatsgültigkeitsdauern und weniger Akzeptanz für die manuelle Zertifikatsverwaltung. Eine DigiCert Trust Pulse Survey vom 2. Juli 2025 ergab, dass 45 % der Unternehmen im vergangenen Jahr dienstbezogene Ausfälle im Zusammenhang mit Zertifikaten verzeichneten, und 37.5 % dieser Ausfälle ließen sich direkt auf abgelaufene Zertifikate zurückführen. Die manuelle Zertifikatsverfolgung stößt bereits bei der heutigen maximalen Gültigkeitsdauer von 398 Tagen an ihre Grenzen.

Diese Herausforderung wird sich in Kürze noch verschärfen. Am 11. April 2025 verabschiedete das CA/B Forum die Abstimmung SC-081v3 , eine von Sectigo unterstützte Maßnahme, die die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate schrittweise von 398 Tagen auf 200 Tage am 15. März 2026, auf 100 Tage am 15. März 2027 und schließlich auf 47 Tage am 15. März 2029 reduziert. Jeder Erneuerungszyklus, der bisher einmal jährlich stattfand, muss bis 2029 etwa alle sechs Wochen erfolgen. Ein Vertrauensverlust seitens der Zertifizierungsstelle (CA) unter diesen Bedingungen ließe Unternehmen kaum Spielraum für manuelle Reaktionen. Genau deshalb hat sich die Zertifikatsautomatisierung von einer praktischen Funktion zu einer zwingenden Notwendigkeit entwickelt.

Auswirkungen auf das Unternehmen nach Rolle und Frist

Die Reaktion auf ein Misstrauensereignis einer Zertifizierungsstelle und die Vorbereitung auf kürzere Zertifikatslaufzeiten betreffen mehrere Teams. Diese Matrix zeigt, welche Änderungen für jede Gruppe gelten und welche Maßnahmen zu ergreifen sind.

Team	Was das für Sie bedeutet	Sofortmaßnahme	Frist für die Nachverfolgung
PKI-/Zertifikatsteam	Besitzt direkt alle verbleibenden, von Entrust ausgestellten Zertifikate und die schrumpfende Gültigkeitsdauer	Prüfen Sie alle noch in Produktion befindlichen Entrust-Zertifikate und bestätigen Sie die Ersatz-CA.	Sofort, dann bis zum 15. März 2026 für eine Gültigkeit von 200 Tagen.
Sicherheitsteam	Verantwortlich für die Risikobewertung von Änderungen des Vertrauensverhältnisses in Kalifornien und den Notfallplan für zukünftige Vertrauensbrüche	Fügen Sie dem Notfallplan Szenarien für CA-Misstrauen und Zertifikatsablauf hinzu.	Laufend
Plattform-/Infrastrukturteam	Betreibt die Server, Load Balancer und CDNs, auf denen Zertifikate bereitgestellt werden.	Stellen Sie sicher, dass Automatisierungsprotokolle wie ACME, SCEP oder EST an jedem Zertifikatskontaktpunkt aktiviert sind.	Vor dem 15. März 2026
Compliance-Team	Die Zertifizierungsgovernance für Rahmenwerke wie PCI DSS, HIPAA und DORA muss nachgewiesen werden.	Dokumentieren Sie die CA-Migration und bewahren Sie Nachweise über den Zertifikatsaustausch auf.	Ausgerichtet auf den jeweiligen Prüfungszyklus des Rahmenwerks

Checkliste zur Vorbereitung auf den Zertifikatslebenszyklus

• Erstellen Sie eine Liste aller Zertifikate, die noch von Entrust oder einer anderen nicht vertrauenswürdigen Zertifizierungsstelle ausgestellt wurden.
• Prüfen Sie, welche internen Systeme direkt auf Entrust-Root-Zertifikate zugreifen, anstatt die gesamte Zertifikatskette zu validieren.
• Testen Sie automatisierte Registrierungsprotokolle, einschließlich ACME, SCEP und EST, anhand Ihrer Ersatz-CA.
• Legen Sie Ablaufbenachrichtigungen 30, 14 und 7 Tage vor dem Ablaufdatum eines Zertifikats fest.
• Dokumentieren Sie die Migration als Nachweis der Konformität für PCI DSS-, HIPAA- oder DORA-Audits.
• Überprüfen Sie die Abhängigkeiten von Anbietern und SaaS-Lösungen, die intern möglicherweise noch auf Entrust-Roots verweisen.

Migrations-Roadmap: Was ist als Nächstes zu tun?

1. Führen Sie eine vollständige Zertifikatserkennung Durchsucht öffentliche und private Zertifizierungsstellen, um alle noch von Entrust ausgestellten Zertifikate zu finden.
2. Priorisieren Sie den Ersatz von kundennahen und umsatzkritischen Bereichen.
3. Wählen Sie eine Ersatz-CA (Sectigo stellt jetzt das ehemalige öffentliche Zertifikatsvolumen von Entrust direkt aus) und bestätigen Sie die Unterstützung des Automatisierungsprotokolls.
4. Automatisierte Neuausstellung und Verlängerung von Dokumenten über ACME, SCEP oder EST anstelle manueller Anfragen.
5. Erweitern Sie die gleiche Automatisierung auf Zertifikate, die sich der 200-Tage-Grenze nähern, dann auf 100-Tage-Grenze usw. Gültigkeit 47 Tage Meilensteine.
6. Überprüfen Sie die Notfallwiederherstellungs- und Vorfallsreaktionspläne erneut anhand eines simulierten CA-Vertrauensereignisses.

Überlegungen zu Multi-Cloud- und Hybrid-PKI

Organisationen, die Zertifikate über AWS, Azure, Google Cloud und lokale PKI-Systeme hinweg betreiben, stehen vor einer komplexeren Herausforderung. Jede Umgebung verfügt in der Regel über einen eigenen Zertifikatsspeicher, eigene Tools zur Zertifikatserneuerung und eigene Beziehungen zu Zertifizierungsstellen (CAs). Ein CA-Vertrauensverlust oder eine Verkürzung der Gültigkeitsdauer betrifft all diese Bereiche gleichzeitig, jedoch selten zeitgleich. Die zentrale Ermittlung und Automatisierung aller Cloud- und lokalen CAs – anstatt jede Umgebung separat zu verwalten – verhindert, dass ein Ereignis wie der Entrust-Vertrauensverlust in einer hybriden Umgebung zu einem mehrwöchigen Krisenmanagement führt. Der Aufbau dieser Krypto-Agilität ist gleichzeitig die Grundlage für die Migration nach der Quantencomputer-Ära, die dem gleichen Prinzip der sinkenden Lebensdauer folgt.

Wie Verschlüsselungsberatung helfen kann

Encryption Consulting unterstützt Unternehmen dabei, Änderungen bei Zertifizierungsstellen, wie beispielsweise das Misstrauen gegenüber Entrust, frühzeitig zu erkennen und zu beheben, bevor diese zu Notfällen führen. CertSecure Manager bietet PKI- und Sicherheitsteams ein zentrales Dashboard, um alle Zertifikate öffentlicher und privater Zertifizierungsstellen sowie Cloud-Umgebungen zu ermitteln, Erneuerungen über ACME, SCEP und EST zu automatisieren und Richtlinien durchzusetzen, sodass kein Zertifikat von einer einzelnen Zertifizierungsstelle abhängig ist.

Für Teams, die vor einer Migration vollständige Transparenz über ihre kryptografische Infrastruktur benötigen, erstellt CBOM Secure eine kontinuierlich aktualisierte kryptografische Stückliste ( CBOM ) aller Zertifikate, Algorithmen und Schlüssel im gesamten Netzwerk, abgestimmt auf die entsprechenden Compliance-Rahmenwerke. Da das Misstrauen von Zertifizierungsstellen und die sinkende Gültigkeitsdauer von Zertifikaten beides Symptome des gleichen Trends hin zu mehr Agilität in der Kryptografie sind, unterstützen unser PQC Center of Excellence und unsere PQC-Readiness -Beratung Teams bei der Entwicklung einer Roadmap, die sowohl die aktuellen Risiken von Zertifizierungsstellen als auch den Übergang zur Post-Quanten-Technologie abdeckt.

Fazit

Das Misstrauen von Mozilla und Google gegenüber Entrust und der letztendliche Ausstieg von Entrust aus dem Geschäft mit öffentlichen Zertifikaten verdeutlichen, wie schnell Verstöße gegen die strikten Compliance-Vorgaben den Ruf einer Zertifizierungsstelle (CA) zerstören können. Organisationen, die auf digitale Zertifikate angewiesen sind, müssen wachsam bleiben und sich schnell an Veränderungen im CA-Umfeld anpassen können. Dies bedeutet, von der manuellen Nachverfolgung auf ein automatisiertes, kontinuierlich verifiziertes Zertifikatslebenszyklusmanagement umzusteigen, insbesondere da der Gültigkeitsplan des CA/B Forums alle Organisationen dazu drängt, bis 2029 47-Tage-Zertifikate zu verwenden.

Das Verständnis dafür, wie und warum Vertrauensverlust gegenüber Zertifizierungsstellen entsteht, und der Aufbau der Krypto-Agilität, um darauf ohne Unterbrechung reagieren zu können, unterscheidet Organisationen, die ein solches Vertrauensverlustereignis als routinemäßige Wartungsaufgabe behandeln, von solchen, die es als Notfall betrachten.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus Firefox' Artikel „Mozilla folgt Google im Misstrauen gegenüber den TLS-Zertifikaten von Entrust“?

Die wichtigste Erkenntnis ist, dass das Vertrauen in Zertifizierungsstellen schnell schwinden kann, sobald eine CA genügend Compliance-Verstöße akkumuliert. Mozilla und Google entfernten Entrust Ende 2024 aus ihren Root-Zertifikatsspeichern, und Entrust verkaufte schließlich 2025 sein gesamtes Geschäft mit öffentlichen Zertifikaten an Sectigo. Unternehmen, die von einer einzigen CA abhängig waren, mussten unter Zeitdruck migrieren – genau das Szenario, das die automatisierte Verwaltung des Zertifikatslebenszyklus verhindern soll.

Warum ist das für das Zertifikatslebenszyklusmanagement in Unternehmen von Bedeutung?

Ein Entrust-Ereignis einer Zertifizierungsstelle (CA) führt dazu, dass jedes Zertifikat dieser CA – unabhängig vom ursprünglichen Ablaufdatum – nur noch begrenzt gültig ist. Unternehmen, die Zertifikate manuell verwalten, entdecken Entrust-abhängige Zertifikate oft erst spät, nämlich im Rahmen der Reaktion auf Sicherheitsvorfälle, anstatt bereits in der Planungsphase. Die automatisierte Lebenszyklusverwaltung führt einen aktuellen Bestand und kann die Massenausstellung von Zertifikaten auslösen, sobald sich der Vertrauensstatus einer CA ändert. Dadurch wird der Aufwand vermieden, der bei der manuellen Nachverfolgung entsteht.

Welche Teams sind für die Umsetzung dieser Vorgaben verantwortlich?

Die PKI- und Zertifikatsteams sind für die technische Migration der betroffenen Zertifikate verantwortlich. Die Sicherheitsteams führen die Risikobewertung durch und planen die Reaktion auf Sicherheitsvorfälle im Zusammenhang mit Änderungen der CA-Vertrauensstellung. Die Plattform- und Infrastrukturteams betreiben die Server, Load Balancer und CDNs, auf denen die Zertifikate bereitgestellt werden, und müssen die Unterstützung der Automatisierung sicherstellen. Die Compliance-Teams dokumentieren die Migration als Nachweis für Frameworks wie PCI DSS, HIPAA und DORA.

Welche Risiken erhöhen sich, wenn dieses Thema manuell behandelt wird?

Die manuelle Zertifikatsverwaltung erhöht das Risiko, ein von Entrust abhängiges Zertifikat zu übersehen, bis es zu einer Browser-Sicherheitswarnung oder einem Ausfall kommt. Laut der DigiCert Trust Pulse Survey vom Juli 2025 verzeichneten 45 % der Unternehmen im vergangenen Jahr Ausfallzeiten im Zusammenhang mit Zertifikaten, wobei 37.5 % dieser Vorfälle durch abgelaufene Zertifikate verursacht wurden. Die manuelle Nachverfolgung stößt zudem an ihre Grenzen, da die maximale Gültigkeitsdauer von Zertifikaten auf etwa 47 Tage sinkt.

Wie kann Automatisierung das Risiko von Zertifikatsausfällen verringern?

Automatisierungsprotokolle wie ACME, SCEP und EST ermöglichen es einer Plattform für das Zertifikatslebenszyklusmanagement, ein bevorstehendes Ablaufdatum oder eine Änderung der Zertifizierungsstellenvertrauenswürdigkeit zu erkennen und das Zertifikat ohne manuelle Anfrage neu auszustellen. Dadurch werden menschliche Verzögerungen, die den meisten zertifikatsbedingten Ausfällen zugrunde liegen, beseitigt und ein gleichbleibender Erneuerungsrhythmus gewährleistet, selbst wenn die Gültigkeitsdauer von derzeit 398 Tagen auf 47 Tage bis März 2029 sinkt.

Welche Kennzahlen sollten die Teams nach der Implementierung verfolgen?

Verfolgen Sie den Anteil der Zertifikate mit automatischer bzw. manueller Erneuerung, die Anzahl der Zertifikate, deren Ablauf innerhalb von 30 Tagen bevorsteht, die durchschnittliche Zeit bis zur Neuausstellung nach einem Wechsel der Zertifizierungsstelle sowie die Anzahl der Zertifikate, die noch einer einzelnen Zertifizierungsstelle zugeordnet sind. Compliance-Teams sollten außerdem die Auditbereitschaft überwachen, beispielsweise wie schnell ein vollständiges Zertifikatsverzeichnis auf Anfrage erstellt werden kann.

Wie hängt das mit der 47-tägigen TLS-Zertifikatsbereitschaft zusammen?

Das Misstrauen gegenüber Entrust und die Umstellung des CA/B-Forums auf eine 47-tägige Zertifikatsgültigkeit sind beides Symptome desselben Wandels: Die Web-PKI verschärft die Vertrauensanforderungen und verkürzt den Zeitraum, in dem eine nicht konforme CA-Beziehung Schaden anrichten kann. Organisationen, die sich auf 47-Tage-Zertifikate vorbereiten , und solche, die sich von einem CA-Misstrauensfall erholen, benötigen dieselbe Funktionalität: die vollständige Automatisierung von Zertifikatserkennung, -ausstellung und -erneuerung.

Wie sollte dies in Multi-Cloud- oder Hybrid-PKI-Umgebungen gehandhabt werden?

Multi-Cloud- und Hybridumgebungen sollten die Zertifikatserkennung und -automatisierung zentralisieren, anstatt jeden Cloud-Anbieter oder jede lokale Zertifizierungsstelle separat zu verwalten. Ein Vertrauensverlust einer Zertifizierungsstelle oder eine Änderung der Gültigkeitsdauer betrifft alle Umgebungen gleichzeitig, doch jede Cloud-Plattform verfügt über eigene Tools und einen eigenen Erneuerungszeitraum. Eine einheitliche Plattform für das Zertifikatslebenszyklusmanagement, die AWS, Azure, Google Cloud und lokale PKI umfasst, verhindert, dass eine einzelne Umgebung zum blinden Fleck wird.