Die Auswirkungen von Googles Vorgehen gegen Entrust und was es für Sie bedeutet

Kurz gesagt: Google Chrome vertraut seit dem 11. November 2024 keinen neuen Entrust-TLS-Zertifikaten mehr, nachdem jahrelang Verstöße gegen die Richtlinien dokumentiert wurden. Zertifikate, die vor diesem Datum ausgestellt wurden, bleiben bis zu ihrem Ablaufdatum gültig. Organisationen, die weiterhin Entrust-Zertifikate verwenden, benötigen jedoch einen Migrationsplan mit automatisierter Zertifikatsverwaltung , um Browserwarnungen und Ausfälle zu vermeiden.

Fast ein Jahrzehnt lang fungierte Entrust als eine der vertrauenswürdigen Stammzertifizierungsstellen im Chrome-Root-Programm. Dies änderte sich im Juni 2024, als das Chrome-Sicherheitsteam von Google bekannt gab, das Vertrauen in Entrusts Fähigkeit verloren zu haben, die Richtlinien des Chrome-Root-Programms und die CA/Browser-Forum-Basisanforderungen zu erfüllen. Die Entscheidung betraf alle Organisationen, die von Entrust ausgestellte öffentliche TLS-Zertifikate verwendeten, und schuf einen Präzedenzfall, den Google, Apple und Mozilla seither auch auf andere Zertifizierungsstellen angewendet haben. 

Executive Summary

Google Chrome hat am 11. November 2024 nach jahrelangen dokumentierten Verstößen gegen die Compliance-Vorgaben die Vertrauenswürdigkeit neuer Entrust-TLS-Zertifikate eingestellt. Apple und Mozilla folgten im selben Monat mit eigenen Stichtagen. Entrust hat sein Geschäft mit öffentlichen Zertifikaten inzwischen an Sectigo verkauft. Das gleiche Vorgehen wurde 2025 gegen Chunghwa Telecom und Netlock wiederholt und deckt sich mit der vom CA/Browser Forum beschlossenen schrittweisen Reduzierung der maximalen TLS-Gültigkeit auf 47 Tage bis März 2029. Dieser Leitfaden führt PKI-, Sicherheits-, Plattform- und Compliance-Teams durch den Zeitplan der Richtlinie, die Auswirkungen je nach Rolle und Frist, eine Checkliste zur Vorbereitung und einen Migrationsfahrplan, sodass ein zukünftiges Vertrauensverlustereignis oder eine Gültigkeitsumstellung zu einer routinemäßigen Aktualisierung und nicht zu einer Notfallübung wird.

Wichtige Erkenntnisse

• Chrome vertraute neuen Entrust TLS-Zertifikaten mit SCTs, die nach dem 11. November 2024 datiert waren, nicht mehr; Apple und Mozilla führten später im selben Monat ihre eigenen Stichtage ein.
• Entrust hat sein öffentliches Zertifikatsgeschäft inzwischen an Sectigo verkauft, aber bereits unter der alten Entrust-Root-Zertifizierungsstelle ausgestellte Zertifikate sind nicht automatisch vor dem Misstrauen geschützt.
• Das gleiche Durchsetzungsmuster wiederholte sich im August 2025, als Google Chunghwa Telecom und Netlock wegen ähnlicher Verstöße gegen die Compliance-Vorschriften das Vertrauen entzog. Dies zeigt, dass es sich um ein wiederkehrendes Risiko und nicht um einen Einzelfall handelt.
• Die manuelle Zertifikatsverfolgung ist nachweislich ein Risiko: Laut der DigiCert Trust Pulse Survey vom Juli 2025 hatten 45 % der Unternehmen im vergangenen Jahr Ausfallzeiten aufgrund von Zertifikaten, und 37.5 % konnten die Ausfälle konkret auf abgelaufene Zertifikate zurückführen.
• Das Misstrauen gegenüber Entrust und die schrittweise Umstellung des CA/Browser Forums auf eine maximale Zertifikatsgültigkeitsdauer von 47 Tagen bis März 2029 deuten beide auf die gleiche Lösung hin: automatisierte Zertifikatserkennung, -ausstellung und -erneuerung anstelle der manuellen Nachverfolgung in Tabellenkalkulationen.

Was Googles Entscheidung gegen Entrust bedeutet

Zertifizierungsstellen wie Entrust garantieren die Identität einer Website, bevor ein Browser ihrer verschlüsselten Verbindung vertraut. Browser erweitern dieses Vertrauen über Root-Programme, und jedes Root-Programm kann es widerrufen, wenn eine Zertifizierungsstelle ihren Verpflichtungen nicht nachkommt. Googles Vorgehen gegen Entrust war genau das: ein Widerruf des Vertrauens auf Root-Programm-Ebene, keine vorübergehende Warnung.

Warum Google Entrust misstraute

Googles öffentliche Begründung stützte sich auf ein Muster und nicht auf einen einzelnen Vorfall. Entrust war seit 2018 Gegenstand mehrerer öffentlich bekannt gewordener Compliance-Vorfälle, darunter verzögerte Widerrufe und wiederholte Nichterfüllung der CA/Browser Forum-Basisanforderungen. Mozillas eigene Vorfallsdokumentation wies eine ähnliche Historie auf. Wenn eine Zertifizierungsstelle wiederholt Korrekturen zusagt, aber keine messbaren Fortschritte erzielt, verlieren Browser-Root-Programme das Vertrauen in ihre Ausstellungspraxis. Google kam zu dem Schluss, dass Entrust diese Grenze überschritten hatte.

Was ist seit November 2024 geschehen?

Entrust-TLS-Zertifikate mit einem Signed Certificate Timestamp (SCT) nach dem 11. November 2024 verloren das Vertrauen von Chrome. Apple führte dieselbe Einschränkung ab dem 15. November 2024 ein, Mozilla ab dem 30. November 2024. Zertifikate, die vor diesen Stichtagen ausgestellt wurden, funktionierten bis zu ihrem Ablaufdatum weiter. Dies milderte zwar die unmittelbaren Auswirkungen, erzeugte aber gleichzeitig ein falsches Sicherheitsgefühl bei Teams, die annahmen, das Problem betreffe nur Neukäufe. Entrust verkaufte daraufhin sein Geschäft mit der öffentlichen Zertifikatsausstellung an Sectigo und integrierte seinen Kundenstamm in eine andere Zertifizierungsstelle unter anderen Betriebsbedingungen.

Google hat Entrust nicht als Einzelfall betrachtet. Im August 2025 wandte Chrome 139 dieselbe Vorgehensweise auch bei Chunghwa Telecom und Netlock an und begründete dies erneut mit anhaltenden Verstößen gegen die Compliance-Vorgaben und fehlenden messbaren Verbesserungen. Die Botschaft an alle, die sich auf eine öffentliche Zertifizierungsstelle verlassen, ist dieselbe: Das Vertrauen in den Root-Store ist bedingt und kann mit einer Frist von etwa vier bis fünf Monaten widerrufen werden.

Offizielle Richtlinienquellen und Gültigkeitsdaten

Alle in diesem Artikel genannten Fristen basieren auf einer Primärquelle. Nutzen Sie die untenstehende Tabelle als Referenz und überprüfen Sie die Quelle direkt, bevor Sie eine Migrationsentscheidung treffen, da Browser-Root-Programme und Abstimmungen von Zertifizierungsstellen/Browser-Foren geändert werden können.

Warum dies für das Zertifikatslebenszyklusmanagement in Unternehmen wichtig ist

Ein Vertrauensverlust oder eine Verkürzung der Gültigkeitsdauer wird erst dann zu einem geschäftlichen Problem, wenn die Zertifikatsverwaltung davon abhängt, dass sich jemand an das Ablaufdatum erinnert. So arbeiten die meisten Organisationen noch immer, und die Daten belegen die damit verbundenen Kosten.

Die Kosten der manuellen Zertifikatsverwaltung

Die am 2. Juli 2025 veröffentlichte Trust Pulse Survey von DigiCert befragte Unternehmen zu ihrem Umgang mit digitalen Zertifikaten und fand heraus, dass manuelle Prozesse, nicht die Zertifikate selbst, die Hauptursache für Fehler sind. 45 % der Befragten hatten im Vorjahr aufgrund eines Zertifikatsproblems Serviceausfälle erlebt, und 37.5 % führten diese Ausfälle konkret auf ein abgelaufenes Zertifikat zurück – eine der am besten vermeidbaren Fehlerquellen im gesamten Zertifikatslebenszyklus. Wenn die zugrunde liegende Zertifizierungsstelle (CA) ebenfalls als vertrauenswürdig eingestuft wird, wie im Fall von Entrust, muss jedes manuell erfasste Zertifikat dieser CA innerhalb kürzester Zeit ersetzt werden. Genau dieses Szenario verursacht Ausfallkosten im sechsstelligen Bereich. Die Zertifikatserkennung ist der erste Schritt, um diese Lücke zu schließen, denn was nicht erfasst ist, kann nicht ersetzt werden.

Der übergeordnete Trend: Die Gültigkeitsdauer von Zertifikaten schrumpft branchenweit.

Das Misstrauen gegenüber Entrust und die Reduzierung der Zertifikatsgültigkeitsdauer durch das CA/Browser Forum sind zwei Symptome desselben Wandels: Die Branche toleriert keine langlebigen, nur unzureichend überwachten Zertifikate mehr. Am 11. April 2025 verabschiedete das CA/Browser Forum die Abstimmung SC-081v3, die später von Sectigo zusammengefasst wurde und die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate in drei Phasen von 398 auf 47 Tage verkürzte.

Die 47-tägige Anleitung von Encryption Consulting zur Zertifikatsvorbereitung geht diesen Zeitplan Schritt für Schritt durch, aber die Kurzfassung ist die gleiche Schlussfolgerung, auf die das Misstrauen gegenüber Entrust bereits hingewiesen hat: Das Zertifikatslebenszyklusmanagement muss automatisiert erfolgen, nicht durch Kalendererinnerungen.

Auswirkungen nach Rolle und Frist

Das Misstrauen gegenüber Entrust und der 47-Tage-Zeitplan wirken sich unterschiedlich aus, je nachdem, welches Team für die Reaktion zuständig ist. Die folgende Tabelle stellt die Verantwortlichkeiten klar dar, sodass keine Lücke zwischen den Teams entsteht.

Checkliste zur Vorbereitung und Migrationsfahrplan

Kurzcheckliste zur Einsatzbereitschaft

• Prüfen Sie, welche Zertifizierungsstellen Ihr aktuelles Zertifikatsinventar ausstellen, und kennzeichnen Sie alle Zertifikate, die noch mit einer nicht vertrauenswürdigen oder kürzlich verkauften Stammzertifizierungsstelle verknüpft sind.
• Identifizieren Sie alle Zertifikate mit einer Gültigkeitsdauer von mehr als 200 Tagen; diese müssen unabhängig von ihrem Ablaufdatum vor dem Stichtag im März 2026 ersetzt werden.
• Prüfen Sie, ob Ihre Zertifikatslebenszyklusmanagement-Plattform oder Ihr Prozess die automatisierte Ausstellung und Verlängerung auf ACME-Basis unterstützt.
• Stellen Sie sicher, dass die privaten Schlüssel bei jeder Erneuerung rotieren und nicht für mehrere neu ausgestellte Zertifikate wiederverwendet werden.
• Die Bestätigung der Domänenkontrollvalidierung kann innerhalb der sich verkleinernden Wiederverwendungsfenster von 200, dann 100 und schließlich 10 Tagen wiederholt werden.
• Für jedes Zertifikat muss die Eigentumsberechtigung dokumentiert werden, damit die Verantwortung für die Erneuerung nicht automatisch demjenigen obliegt, der die Ablaufwarnung zufällig bemerkt.

Migrationsfahrplan

1. Entdecken Sie: Führen Sie eine vollständige Zertifikatserkennung über alle öffentlichen und internen Systeme hinweg durch, um ein aktuelles Inventar zu erstellen, einschließlich Zertifikaten von Zertifizierungsstellen, die Sie nicht mehr aktiv nutzen.
2. Priorisieren: Ordnen Sie die Zertifikate nach ihrer geschäftlichen Kritikalität und danach, wie nahe die ausstellende Zertifizierungsstelle einer Gültigkeits- oder Vertrauensänderung steht, beginnend mit allen Zertifikaten, die mit Entrust oder einer anderen kürzlich als nicht vertrauenswürdig eingestuften Stammzertifizierungsstelle verbunden sind.
3. Controller: Setzen Sie die ACME-basierte Ausstellung und Erneuerung zunächst für die Zertifikatsgruppen mit dem höchsten Volumen und dem höchsten Risiko ein, anstatt einen vollständigen Umstieg auf einmal zu versuchen.
4. Bestätigen: Bevor Sie sich im Produktivbetrieb auf automatisierte Erneuerungen verlassen, vergewissern Sie sich, dass diese tatsächlich abgeschlossen werden und die Schlüssel rotieren, und zwar nicht nur terminiert.
5. Monitor: Verfolgen Sie den Status von Zertifikaten und bevorstehende Änderungen im CA-/Browser-Forum oder im Browser-Root-Programm fortlaufend, damit die nächste Richtlinienänderung nicht überraschend kommt.

Eine detaillierte Anleitung, wie diese Migration in der Praxis aussieht, finden Sie im folgenden Video. Dort wird erklärt, wie Sie einen Wechsel zu einer neuen Zertifizierungsstelle planen und durchführen.

Wie Automatisierung das Risiko von Zertifikatsausfällen reduziert

Die meisten Zertifikatsausfälle werden nicht durch Angriffe verursacht. Sie entstehen vielmehr dadurch, dass ein Zertifikat abläuft, ohne dass dies ausreichend beachtet wurde. Automatisiertes Zertifikatslebenszyklusmanagement beseitigt diese Fehlerquelle, indem die Erneuerung an einen Workflow und nicht an den Kalender einer Person gekoppelt wird. CertSecure Manager erkennt Zertifikate in Cloud-, On-Premises- und Hybridumgebungen, stellt sie aus und erneuert sie über direkte CA-Integrationen und ACME und erzwingt die Rotation des privaten Schlüssels in jedem Zyklus. So wird ein sich verkürzendes Gültigkeitsfenster zu einer planbaren Angelegenheit anstatt zu einem wiederkehrenden Notfall.

Zu verfolgende Kennzahlen nach der Implementierung

• Prozentsatz der Zertifikate unter aktiver automatisierter Verwaltung im Vergleich zur manuellen Nachverfolgung
• Anzahl der Vorfälle oder Beinaheunfälle im Zusammenhang mit Zertifizierungen pro Quartal, Tendenz gegen Null
• Durchschnittliche Zeitspanne zwischen der Entdeckung eines neuen Zertifikats und dessen vollständiger Klassifizierung im Inventar
• Erfolgsquote der Erneuerung beim ersten automatisierten Versuch ohne manuelle Intervention
• Zeitaufwand für den Austausch aller Zertifikate, die mit einer einzelnen nicht vertrauenswürdigen oder kompromittierten Zertifizierungsstelle verbunden sind, gemessen ab dem ersten Tag

Überlegungen zu Multi-Cloud- und Hybrid-PKI

Änderungen des Vertrauens in Zertifizierungsstellen und kürzere Gültigkeitsdauern sind in Multi-Cloud- und Hybridumgebungen schwerer zu bewältigen, da Zertifikate von verschiedenen Zertifizierungsstellen in AWS, Azure, GCP und der lokalen PKI ausgestellt werden – oft ohne gemeinsames Inventar. Ein Vertrauensverlust wie der von Entrust kennt keine Umgebungsgrenzen: Ein von Entrust ausgestelltes Zertifikat, das einen internen Load Balancer schützt, ist genauso gefährdet wie eines, das eine öffentlich zugängliche Website schützt. Die zentrale Ermittlung und Ausstellung von Zertifikaten für alle Umgebungen, anstatt die nativen Zertifikatstools jeder Cloud isoliert zu verwalten, ermöglicht es, innerhalb von Tagen statt Monaten auf einen Vertrauensverlust oder eine Gültigkeitsänderung zu reagieren. PKI-as-a-Service bietet Hybrid- und Multi-Cloud-Organisationen eine zentrale Steuerungsebene für Ausstellung und Richtlinien, sodass eine Änderung auf Zertifizierungsstellenebene in einer Umgebung nicht den gesamten Prozess in allen anderen Umgebungen neu aufbauen muss.

Was macht man als nächstes

Das Misstrauen gegenüber Entrust, der 47-Tage-Zertifikatszyklus und die allgemeine Entwicklung hin zu Post-Quanten-Kryptographie sind keine voneinander unabhängigen Projekte, die um dasselbe Budget konkurrieren. Sie alle basieren auf derselben Grundlage: einem präzisen und kontinuierlich aktualisierten Verzeichnis aller Zertifikate und kryptografischen Assets in Ihrer Umgebung. PKI-, Sicherheits-, Plattform- und Compliance-Teams, die dieses Verzeichnis einmalig erstellen und aktuell halten, können das nächste Misstrauen gegenüber einer Zertifizierungsstelle oder eine Gültigkeitsänderung als Routine-Update und nicht als Notfallmaßnahme bewältigen.

Teams, die noch nicht begonnen haben, sollten die Zertifikatsermittlung als nächsten unmittelbaren Schritt betrachten, noch vor PQC-Bereitschafts- oder Krypto-Agilitätsinitiativen , die ein bereits vorhandenes Inventar voraussetzen. Das PQC Center of Excellence von Encryption Consulting und CBOM Secure nutzen beide dieselbe Ermittlungsebene. Die Maßnahmen zur Reaktion auf das Misstrauen von Entrust fließen daher direkt in die für den 47-Tage-Zeitplan und die Post-Quantum-Migration erforderlichen Arbeiten ein. Um genauer zu verstehen, wie aus diesem Inventar eine kontinuierliche Fähigkeit und nicht nur ein einmaliges Projekt wird, siehe „Wie eine kryptografische Stückliste Inventar in Wissen umwandelt“.

Wie Verschlüsselungsberatung helfen kann

Die Reaktion auf ein Misstrauensereignis einer Zertifizierungsstelle oder eine verkürzte Gültigkeitsdauer beginnt unabhängig von der auslösenden Richtlinienänderung mit derselben Erkennungsebene. Unsere CertSecure Manager- Plattform erkennt und inventarisiert Zertifikate in Cloud-, On-Premises- und Hybridumgebungen und automatisiert anschließend deren Ausstellung und Verlängerung. So wird ein Misstrauensereignis bei der Stammzertifizierungsstelle oder eine verkürzte Gültigkeitsdauer zu einer planbaren Angelegenheit und nicht zu einem Notfall. Für Unternehmen, die Zertifikate in AWS, Azure, GCP und On-Premises-PKI verwalten, bietet PKI-as-a-Service eine zentrale Steuerungsebene für diese Erkennung und Ausstellung. Dieses Inventar fließt auch direkt in langfristige Projekte ein: Unser PQC Center of Excellence und unsere PQC-Readiness -Assessments basieren auf derselben Erkennungsmethode, und CBOM Secure erstellt daraus eine vollständige Stückliste für Kryptografie. Erfahren Sie, wie CBOM Inventar in wertvolle Erkenntnisse umwandelt und wie Zertifikatsautomatisierung, PQC-Readiness und CBOM miteinander verbunden sind.

Fazit

Googles Misstrauen gegenüber Entrust hatte eigentlich nichts mit Entrust selbst zu tun. Es ging vielmehr darum zu demonstrieren, dass das Vertrauen in den Root-Speicher aktiv durchgesetzt wird und es sich nicht um eine Zertifizierungsstelle handelt, die einmalig erworben und unbegrenzt behalten wird. Dasselbe Prinzip gilt nun auch für die Gültigkeitsdauer von Zertifikaten: Die vom CA/Browser Forum beschlossene maximale Gültigkeitsdauer von 47 Tagen setzt voraus, dass Organisationen Zertifikate in einem Rhythmus ausstellen und rotieren können, der manuell nicht realisierbar ist.

Ob die nächste Störung nun darin besteht, dass eine weitere Zertifizierungsstelle das Vertrauen verliert, eine Gültigkeitsdaueränderung ansteht oder ein Post-Quanten-Algorithmus migriert wird – die Organisationen, die diese Krise unbeschadet überstehen, sind diejenigen, die bereits genau wissen, welche Zertifikate sie besitzen, wem sie gehören und wie diese Zertifikate ersetzt werden, ohne dass es jemand bemerkt.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus dem Artikel „Die Auswirkungen von Googles Vorgehen gegen Entrust und was bedeutet das für Sie?“?

Google Chrome vertraut seit dem 11. November 2024 keinen neuen Entrust-TLS-Zertifikaten mehr, nachdem jahrelang Verstöße gegen die Compliance-Vorgaben dokumentiert wurden. Zertifikate, die vor diesem Datum ausgestellt wurden, blieben bis zu ihrem Ablaufdatum gültig. Die zugrundeliegende Erkenntnis ist jedoch allgemein gültig: Das Vertrauen in den Root-Speicher von Browsern ist bedingt und kann widerrufen werden. Unternehmen benötigen daher eine kontinuierliche Zertifikatsprüfung und automatische Erneuerung, anstatt sich dauerhaft auf die Reputation einer einzelnen Zertifizierungsstelle zu verlassen.

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

Die manuelle Zertifikatsverfolgung macht jede Änderung des Vertrauensstatus einer Zertifizierungsstelle zu einem Notfall. Laut der DigiCert Trust Pulse Survey vom Juli 2025 hatten 45 % der Unternehmen im vergangenen Jahr Ausfallzeiten aufgrund von Zertifikaten, wobei 37.5 % davon auf abgelaufene Zertifikate zurückzuführen waren. Wenn einer vertrauenswürdigen Zertifizierungsstelle wie Entrust das Vertrauen entzogen wird, muss jedes Zertifikat dieser Zertifizierungsstelle innerhalb kürzester Zeit ersetzt werden. Deshalb ist ein automatisiertes Lebenszyklusmanagement wichtiger denn je.

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

PKI-Teams sind für die Entscheidungen bezüglich Root-of-Trust und CA-Diversifizierung zuständig. Sicherheitsteams überprüfen die Rotation privater Schlüssel und überwachen ablaufende Zertifikate in allen Umgebungen. Plattform- und DevOps-Teams aktualisieren CI/CD-Pipelines, um kürzere Erneuerungszyklen durch ACME-Automatisierung zu ermöglichen. Compliance-Teams pflegen auditbereite Zertifikatsinventare und verfolgen fortlaufend Änderungen der Richtlinienquellen aus dem CA/Browser-Forum und Browser-Root-Programmen.

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

Die manuelle Bearbeitung erhöht das Risiko unbemerkter Ablaufdaten, doppelter oder verwaister Zertifikate, inkonsistenter Rotation privater Schlüssel und verzögerter Reaktionen auf ein Misstrauensereignis einer Zertifizierungsstelle. Da die Gültigkeitsdauer bis März 2029 auf etwa 47 Tage sinkt, ist die manuelle Überwachung aufgrund der erforderlichen Erneuerungshäufigkeit betrieblich nicht mehr durchführbar. Dies erhöht die Wahrscheinlichkeit eines Ausfalls aufgrund eines Zertifikats, das nicht aktiv überwacht wurde.

Wie kann Automatisierung das Risiko von Zertifikatsausfällen verringern?

Die Automatisierung verknüpft die Zertifikatserneuerung mit einem Workflow, anstatt dass sich eine Person an das Ablaufdatum erinnern muss. Plattformen wie CertSecure Manager erkennen Zertifikate in Cloud-, On-Premises- und Hybridumgebungen, stellen sie aus und erneuern sie über direkte CA-Integrationen und ACME und erzwingen die Rotation des privaten Schlüssels in jedem Zyklus. Dadurch wird die zentrale Fehlerquelle menschlichen Versagens beseitigt, die die meisten zertifikatsbezogenen Ausfälle verursacht.

Welche Kennzahlen sollten die Teams nach der Implementierung verfolgen?

Verfolgen Sie den Prozentsatz der Zertifikate, die unter aktiver automatisierter Verwaltung stehen, die Anzahl der zertifikatsbezogenen Vorfälle pro Quartal, die Erfolgsquote der automatischen Erneuerung beim ersten Versuch, die Zeit zwischen der Entdeckung eines neuen Zertifikats und dessen Klassifizierung im Inventar sowie die Zeit, die benötigt wird, um jedes Zertifikat zu ersetzen, das mit einer einzigen nicht vertrauenswürdigen oder kompromittierten Zertifizierungsstelle verbunden ist.

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

Das Misstrauen gegenüber Entrust und die 47-Tage-Zertifikatslaufzeit gehen beide auf dieselbe Branchenentwicklung zurück: kürzere Zertifikatsgültigkeitsdauern und strengere Verantwortlichkeit der Zertifizierungsstellen. Der Wahlvorschlag SC-081v3 des CA/Browser Forums sieht eine schrittweise Reduzierung der maximalen TLS-Gültigkeit auf 200 Tage bis März 2026, 100 Tage bis März 2027 und 47 Tage bis März 2029 vor. Dies erfordert dieselbe automatisierte Ausstellungs- und Erneuerungsinfrastruktur, die auch im Falle eines Misstrauens gegenüber einer Zertifizierungsstelle notwendig ist.

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

In Multi-Cloud- und Hybridumgebungen werden häufig Zertifikate von verschiedenen Zertifizierungsstellen (CAs) in AWS, Azure, GCP und der lokalen PKI ausgestellt, ohne dass ein gemeinsames Inventar geführt wird. Dadurch ist es schwieriger, ein Misstrauensereignis einer CA oder eine Gültigkeitsänderung nachzuverfolgen. Die Zentralisierung von Erkennung und Ausstellung über eine Plattform wie PKI-as-a-Service bietet diesen Umgebungen eine einheitliche Steuerungsebene. So muss eine Änderung auf CA-Ebene an einer Stelle nicht den gesamten Prozess an anderen Stellen neu aufbauen.