Googles 90-Tage-Zertifikate: Schneller und effektiver Übergang zu 90-Tage-TLS/SSL-Zertifikaten

Kurz gesagt: Öffentliche TLS/SSL-Zertifikate sind nicht auf 90 Tage begrenzt. Gemäß der Abstimmung SC-081v3 des CA/Browser Forums sinkt die maximale Gültigkeitsdauer von Zertifikaten im März 2026 auf 200 Tage, im März 2027 auf 100 Tage und im März 2029 auf 47 Tage. Organisationen, die weiterhin Jahres- oder 398-Tage-Zertifikate ausstellen, benötigen vor dem ersten Stichtag ein automatisiertes Zertifikatslebenszyklusmanagement.

Als Google erstmals eine Gültigkeitsdauerbegrenzung von 90 Tagen für öffentliche TLS/SSL -Zertifikate ins Gespräch brachte, wurde dies weithin als kommender Branchenstandard gehandelt. Dieser konkrete Vorschlag wurde jedoch nie verbindlich. Stattdessen verabschiedete das CA/Browser Forum den Wahlvorschlag SC-081v3, der eine schrittweise, mehrjährige Reduzierung vorsieht, die bis 2029 bei 47 Tagen enden soll – kein abrupter Sprung auf 90 Tage. Jeder Zertifikatsverwaltungsplan, der weiterhin auf „90 Tagen“ basiert, plant gegen eine nicht existierende Frist.

Wichtige Erkenntnisse

• Die 90-Tage-Frist ist überholt: Die CA/Browser Forum Ballot SC-081v3 (angekündigt von Sectigo am 14. April 2025) ersetzte jeden einzelnen 90-Tage-Vorschlag durch einen gestaffelten Zeitplan.

• Drei Fristen, nicht nur eine: Die maximale Gültigkeitsdauer öffentlicher TLS/SSL-Zertifikate sinkt im März 2026 auf 200 Tage, im März 2027 auf 100 Tage und im März 2029 auf 47 Tage.

• Die manuelle Erneuerung stößt bereits nach diesen Abständen an ihre Grenzen: Laut der DigiCert Trust Pulse Survey vom 2. Juli 2025 berichteten 45 % der Unternehmen über Ausfallzeiten im Zusammenhang mit Zertifikaten, und 37.5 % führten die Ausfälle direkt auf abgelaufene Zertifikate zurück.

• Die Nachverfolgung mittels Tabellenkalkulationen wird 47-Tage-Zyklen nicht überstehen: Bei etwa 7-8 Verlängerungen pro Zertifikat und Jahr vervielfacht die manuelle Nachverfolgung den Arbeitsaufwand, der bereits heute zu Ausfällen führt.

• Automatisierung ist der praktische Weg: Eine Certificate Lifecycle Management (CLM)-Plattform wie CertSecure Manager ist für die meisten Unternehmen die Lösung, um jeden Termin ohne Hektik in letzter Minute einzuhalten.

Von Googles 90-Tage-Vorschlag bis zum verbindlichen Zeitplan des CA/B-Forums

Google brachte die Idee einer maximalen Gültigkeitsdauer von 90 Tagen für öffentliche TLS-Zertifikate ins Spiel. Dies geschah im Rahmen seiner langjährigen Bemühungen um kürzere Zertifikatslebensdauern und eine stärkere Automatisierung im gesamten PKI-Ökosystem des Webs. Der Vorschlag löste eine rege Debatte aus: Kürzere Gültigkeitsdauern verringern zwar die potenziellen Folgen eines kompromittierten Schlüssels, erhöhen aber gleichzeitig den operativen Aufwand für alle Organisationen, die Zertifikate noch manuell ausstellen und erneuern.

Diese Debatte wurde durch das Abstimmungsverfahren des CA/Browser-Forums und nicht durch den Vorschlag eines einzelnen Browserherstellers beigelegt. Die Abstimmung SC-081v3 wurde angenommen und am 14. April 2025 von Sectigo bekannt gegeben. Sie sieht eine schrittweise Reduzierung anstelle eines abrupten Wechsels auf 90 oder 47 Tage vor. Daraus ergibt sich ein Zeitplan, den jede öffentlich vertrauenswürdige Zertifizierungsstelle und jeder vertrauende Browser einhalten muss: 200 Tage ab März 2026, 100 Tage ab März 2027 und 47 Tage ab März 2029.

Inhalte und Leitlinien, die sich weiterhin auf „Googles 90-Tage-Zertifikate“ konzentrieren, beschreiben einen Vorschlag, der längst überholt ist. Maßgeblich ist die Abstimmung des CA/B-Forums, und Unternehmen sollten mit einer Gültigkeitsdauer von 47 Tagen planen, die über etwa drei Jahre schrittweise eingeführt wird.

Offizielle Richtlinienquellen und Gültigkeitsdaten

Gültigkeitszeitraum des TLS-Zertifikats: 200 → 100 → 47 Tage

Jeder der folgenden Schritte ist für alle öffentlich vertrauenswürdigen Zertifizierungsstellen verbindlich und wird von allen gängigen Browsern durchgesetzt. Nutzen Sie diese Tabelle, um Ihre Erneuerungsintervalle, die Automatisierung und die Prüfnachweise mit den tatsächlichen Fristen abzustimmen.

Hinweis zur Implementierung: Überprüfen Sie vor jedem Erneuerungszyklus die Gültigkeitsdaten dieser Tabelle anhand des aktuellen Abstimmungstextes des CA/B Forums, da die Gültigkeits- und Wiederverwendungszeiträume weiteren Abstimmungen unterliegen und daher erneut geprüft werden sollten und nicht als statisch angenommen werden dürfen.

Warum kürzere Zertifikatslebenszyklen für das Zertifikatslebenszyklusmanagement in Unternehmen wichtig sind

Kürzere Gültigkeitsdauern sind eine direkte Reaktion auf ein bestehendes Problem von Unternehmen und schaffen kein neues. Die DigiCert Trust Pulse Survey vom Juli 2025 ergab, dass 45 % der Organisationen über zertifikatsbedingte Ausfallzeiten berichteten und 37.5 % einen Ausfall direkt auf ein abgelaufenes Zertifikat zurückführten. Diese Zahlen beschreiben die aktuelle Situation mit 398-Tage-Zertifikaten. Die Umstellung auf 47-Tage-Zertifikate behebt diese grundlegende Lücke nicht allein; sie beseitigt die Möglichkeit, Zertifikate manuell zu verwalten und damit durchzukommen.

Vorteile von Zertifikaten mit kürzerer Gültigkeitsdauer

• Verbesserte Sicherheit

  Wird ein privater Schlüssel kompromittiert, verringert eine kürzere Gültigkeitsdauer das Zeitfenster, in dem ein Angreifer ihn nutzen kann. Schnelleres Ablaufdatum und obligatorische Schlüsselrotation begrenzen den Schaden, selbst wenn eine Kompromittierung eine Zeit lang unentdeckt bleibt.

• Stärkere Compliance-Haltung

  Durch die häufige, erzwungene Erneuerung bleiben die kryptografischen Parameter stets auf dem neuesten Stand der sich ständig weiterentwickelnden Anforderungen des CA/B Forums, wodurch die Wahrscheinlichkeit sinkt, dass bei einer Prüfung ein Zertifikat festgestellt wird, das gemäß einer veralteten Richtlinie ausgestellt wurde.

• Schnellere Anpassungsfähigkeit

  Organisationen sind nicht an langfristige Zertifikatsverpflichtungen gebunden, sodass eine neue Algorithmusanforderung oder der Widerruf einer Zertifizierungsstelle nicht dazu führt, dass Zertifikate ein Jahr oder länger ungenutzt bleiben.

• Unteres Missbrauchsfenster

  Ein gestohlenes oder falsch ausgestelltes Zertifikat hat eine kürzere Gültigkeitsdauer, bevor es von selbst abläuft, zusätzlich zu etwaigen Widerrufsmaßnahmen.

• Straffere Schlüsselverwaltung

  Häufigere Verlängerungen erfordern einen häufigeren Schlüsselwechsel, was eine der effektivsten, wenn auch unglamourösesten Kontrollmaßnahmen im Schlüsselmanagement darstellt.

• Einfacheres langfristiges CLM

  Sobald die Automatisierung eingerichtet ist, sind kurzlebige Zertifikate tatsächlich einfacher zu handhaben als langlebige: Ausstellung, Verlängerung und Widerruf erfolgen alle im gleichen, vorhersehbaren, automatisierten Rhythmus.

Risiken der manuellen Zertifikatsverwaltung bei kürzeren Lebenszyklen

Ein abgelaufenes Zertifikat verursacht heute die gleichen Fehler wie eh und je; kürzere Zyklen bedeuten lediglich, dass dies häufiger vorkommt, es sei denn, die Erneuerung erfolgt automatisiert.

• Datenverstöße

  Wenn ein SSL-Zertifikat abläuft, bricht auch die von ihm geschützte sichere Verbindung zusammen, und Angreifer können alle zuvor verschlüsselten Daten während der Übertragung abfangen.

• Dienstunterbrechung

  Abgelaufene Zertifikate legen Websites und Dienste lahm. Browserwarnungen schrecken Nutzer ab, noch bevor sie die Inhalte sehen, was sich direkt auf Umsatz und Supportanfragen auswirkt.

• Suchmaschinenstrafen

  Abgelaufene SSL-Zertifikate können die Sichtbarkeit in Suchmaschinen beeinträchtigen, da große Suchmaschinen Websites ohne gültiges HTTPS aktiv herabstufen.

• Reputationsschaden

  Ein durch etwas so Vermeidbares wie ein abgelaufenes Zertifikat verursachter Ausfall untergräbt das Kundenvertrauen auf eine Weise, deren Wiederherstellung weitaus länger dauert als die Verlängerung selbst.

Zertifikatsautomatisierung: Reduzierung des Ausfallrisikos

Die Automatisierung zielt direkt auf die 37.5 % Ausfallquote aufgrund abgelaufener Zertifikate ab, die in der DigiCert-Umfrage ermittelt wurde. Sie beseitigt die beiden häufigsten Ursachen für Zertifikatsausfälle: menschliches Vergessen eines Datums und einen zu langsamen Erneuerungsprozess, der nicht vor Ablauf der Gültigkeit abgeschlossen werden kann.

1. Zeit- und Kostenersparnis

   Die Automatisierung von Zertifikaten beseitigt manuelle Übergaben zwischen Systemen und entlastet so IT- und Sicherheitsteams, sodass diese sich auf wertschöpfendere Aufgaben konzentrieren können, anstatt Erneuerungstermine im Auge zu behalten.

2. Weniger menschliche Fehler

   Eine einzige manuelle Fehlkonfiguration oder eine versäumte Verlängerung kann zu einem Ausfall führen. Die Automatisierung wendet jedes Mal und bei jeder Zertifikatsanzahl denselben validierten Prozess an.

3. Keine Verlängerungen in letzter Minute

   Bei einer Gültigkeitsdauer von 47 Tagen ist die Strategie „Nächste Woche verlängern“ nicht praktikabel. Die automatische Verlängerung wird in jedem Zyklus weit vor Ablauf der Gültigkeit ausgelöst, ohne dass sich jemand daran erinnern muss.

4. Stärkere Sicherheitslage

   Automatische und termingerechte Zertifikatserneuerungen schließen genau die Lücke (abgelaufene oder ungültig gewordene Zertifikate), die sowohl in der DigiCert-Umfrage als auch in der Risikoliste dieses Artikels als Hauptursache für zertifikatsbezogene Vorfälle genannt wird.

Auswirkungen nach Rolle und Datum: Wer muss handeln und wann?

Der 47-Tage-Zeitplan betrifft mehr als nur das Team, das auf „Verlängern“ klickt. Nutzen Sie diese Matrix, um die Zuständigkeiten vor dem Stichtag im März 2026 zu klären, nicht danach.

PKI- und Sicherheitsteams

Die PKI- und Sicherheitsteams sind für die Richtlinienentscheidungen verantwortlich: Gültigkeitsdauer, Schlüssellängen, SLAs für den Zertifikatswiderruf und die Zulassung von Zertifizierungsstellen. Im Rahmen des gestaffelten Zeitplans sollten diese Teams die Zertifikatsermittlung als oberste Priorität und nicht als nachträgliche Überlegung behandeln, da die Erneuerung von Zertifikaten, deren Existenz unbekannt ist, nicht automatisiert werden kann.

Plattform- und DevOps-Teams

DevOps- Teams verbrauchen in den meisten Unternehmen den größten Anteil an Zertifikaten, insbesondere in CI/CD -Pipelines. Die API-gesteuerte Ausstellung über Protokolle wie ACME, EST oder SCEP ermöglicht die automatische Bereitstellung von Zertifikaten während des Deployments, anstatt über eine Ticketwarteschlange, die mit den 47-tägigen Verlängerungen nicht Schritt halten kann.

Compliance-Teams

Compliance-Teams benötigen ein aktuelles Zertifikatsverzeichnis und Nachweise über Zertifikatserneuerungen, die zwischen den Audits stets aktuell sind – keine erst kurz vor dem Audit erstellte Tabelle. Eine CLM-Plattform, die Berichte auf Abruf generiert, verwandelt die mehrwöchige Auditvorbereitung in eine Abfrage von Echtzeitdaten.

Checkliste zur Vorbereitung und Migrationsfahrplan

Kurzcheckliste zur Einsatzbereitschaft

• Erstellen Sie ein vollständiges Zertifikatsinventar, einschließlich selbstsignierter Zertifikate und Schattenzertifikate außerhalb der verwalteten Zertifizierungsstelle.

• Stellen Sie sicher, dass jedes Zertifikat einen namentlich genannten Inhaber hat und nicht nur einen technischen Ansprechpartner, der noch aus der Bereitstellungsphase stammt.

• Vor März 2026 soll eine CLM-Plattform ausgewählt und getestet werden, die zur Ausgabe von ACME-, EST- und SCEP-Zertifikaten fähig ist.

• Die Automatisierung der Erneuerung sollte so eingestellt werden, dass sie mit genügend Vorlaufzeit ausgelöst wird, um einen fehlgeschlagenen ersten Versuch zu überstehen.

• Die aktuellen Gültigkeitszeiträume und Compliance-Rahmenbedingungen sollten so erfasst werden, dass die Prüfungsnachweise vor dem 100-Tage-Schritt vorliegen.

• Bestätigen Sie, dass CI/CD- und DevOps-Pipelines Zertifikate über die API anfordern und nicht manuell übermitteln.

Migrationsfahrplan

Eine CLM-Einführung, die die 47-Tage-Frist ohne Hektik einhält, folgt im Allgemeinen der gleichen Abfolge:

1. Inventar

   Erstellen Sie ein vollständiges Verzeichnis aller Zertifikate in der Umgebung, einschließlich derer, die derzeit niemandem gehören. Dies ist der Schritt, der bei den meisten verzögerten Migrationen ausgelassen wird.

2. Zertifikatsermittlung

   Führen Sie aktive und passive Erkennungsmaßnahmen durch, um versteckte und selbstsignierte Zertifikate aufzudecken, die nie einen formellen Ausstellungsprozess durchlaufen haben; diese sind häufig die Ursache für unerwartete Ausfälle.

3. Überwachung und Berichterstattung

   Führen Sie eine kontinuierliche Überwachung ein, damit Anomalien bei der Ausstellung oder Verlängerung sofort erkannt werden und nicht erst dann entdeckt werden, wenn ein Dienst ausfällt.

4. Automation

   Automatisieren Sie die Erneuerung vollständig. Bei einem 47-Tage-Zyklus ist die manuelle Nachverfolgung der Zertifikatsinhaber über Tage oder Wochen pro Zertifikat aus betrieblichen Gründen nicht mehr möglich.

5. Arbeitsabläufe und Richtlinien

   Die Durchsetzung der Richtlinien sollte zentralisiert werden, sodass jede neue Zertifikatsanforderung vor ihrer Ausstellung anhand der genehmigten Gültigkeitszeiträume, Schlüssellängen und ausstellenden Zertifizierungsstellen validiert wird.

6. DevOps-Integration

   Verbinden Sie die CLM-Plattform über eine API mit den CI/CD-Tools, sodass Zertifikate automatisch im Rahmen der Bereitstellung bereitgestellt werden und so dem Tempo kürzerer Gültigkeitsdauern gerecht werden.

CertSecure Manager: Automatisierung des Zertifikatslebenszyklusmanagements für die 47-Tage-Ära

CertSecure Manager deckt das gesamte Zertifikatslebenszyklusmanagement ab (Erkennung, Inventarisierung, Ausstellung, Bereitstellung, Verlängerung, Widerruf und Berichterstellung) und nutzt dafür Automatisierung statt manueller Prozesse. Integrierte Warnmeldungen weisen frühzeitig auf bevorstehende Ablaufdaten hin, sodass Sie rechtzeitig reagieren können. Die Berichtsfunktion erfüllt die Anforderungen von NIST , HIPAA , DSGVO und dem CA/B Forum, ohne dass vor jedem Audit manuell Nachweise gesammelt werden müssen.

Organisationen, die CertSecure Manager verwenden, sind in der Lage, jeden Schritt des gestaffelten Zeitplans (200 Tage, dann 100, dann 47) mit demselben automatisierten Prozess zu durchlaufen, anstatt die Zertifikatsverwaltung jedes Mal neu zu gestalten, wenn sich die Anforderungen des CA/B Forums ändern.

Verknüpfung von Zertifikatsautomatisierung mit Krypto-Agilität und PQC-Bereitschaft

Die Automatisierung von Zertifikaten ist nicht nur eine Reaktion auf kürzere Gültigkeitsdauern; sie ist die operative Grundlage, auf der die Migration nach der Quantenmigration beruht. Eine Organisation, die Zertifikate automatisch erneuern, neu ausstellen und rotieren kann, verfügt bereits über die Basis für kryptografische Agilität: die Fähigkeit, kryptografische Primitive schnell und sicher an veränderte Standards anzupassen.

Diese Verbindung ist für Teams, die bereits Post-Quanten-Kryptographie- Termine im Blick haben, von direkter Bedeutung. Die PQC-Readiness -Programme und die CBOM Secure- Plattform von Encryption Consulting bauen auf der oben beschriebenen Ermittlungs- und Inventarisierungsarbeit auf: Ein vollständiges, aktuelles Zertifikatsinventar bildet auch die Grundlage für eine kryptografische Stückliste (CBOM). Teams, die das Zertifikatslebenszyklusmanagement bereits automatisiert haben, beginnen bei der Planung der PQC-Migration nicht bei null.

Für einen detaillierteren Einblick in die Umwandlung dieses Inventars in ein handlungsfähiges, kontinuierlich gepflegtes Aufzeichnungssystem, sehen Sie sich an, wie eine kryptografische Stückliste Inventar in Informationen verwandelt.

Was macht man als nächstes

• PKI-Teams: Die Zertifikatserkennung und -inventarisierung abschließen und bestätigen, dass jedes Zertifikat einen benannten Inhaber hat, und zwar bis März 2026.

• Sicherheitsteams: Legen Sie Gültigkeit, Schlüssellänge und Widerrufsrichtlinie jetzt fest, damit dies nicht später unter Zeitdruck ad hoc erfolgen muss.

• Plattformteams: Verlagern Sie Zertifikatsanforderungen in CI/CD-Pipelines auf eine API-gesteuerte Ausstellung vor dem 100-Tage-Schritt.

• Compliance-Teams: Stellen Sie sicher, dass die CLM-Berichtsprozesse mit Ihren bestehenden Audit-Rahmenwerken kompatibel sind, und zwar rechtzeitig vor dem 47-Tage-Schritt, da eine manuelle Beweiserhebung dann nicht mehr praktikabel ist.

Fazit

Die Zertifizierungsbranche führt die Gültigkeitsdauer von 90 Tagen nicht auf Googles Vorschlag hin ein. Vielmehr erfolgt die Umstellung auf 200, dann 100 und schließlich 47 Tage, weil das CA/Browser Forum einen verbindlichen Zeitplan beschlossen hat. Dieser Unterschied ist wichtig, da sich der Zeitrahmen, die Fristen und die Compliance-Verpflichtungen von dem unterscheiden, was der Begriff „90-Tage-Zertifikat“ nach wie vor beschreibt.

Organisationen, die dies als einmalige Änderung der Erneuerungshäufigkeit betrachten, werden in jedem Schritt Schwierigkeiten haben. Organisationen, die es hingegen als Anstoß nehmen, das Zertifikatslebenszyklusmanagement endlich zu automatisieren und die damit verbundene Krypto-Agilität aufzubauen, werden im März 2026, März 2027 und März 2029 auf derselben Plattform agieren können, ohne ihren Ansatz dreimal grundlegend überarbeiten zu müssen.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus Googles Artikel „90-Tage-Zertifikate: Schneller und effektiver Übergang zu 90-Tage-TLS/SSL-Zertifikaten“?

Googles ursprünglicher 90-Tage-Vorschlag wurde durch die Abstimmung SC-081v3 des CA/Browser Forums ersetzt, die stattdessen einen gestaffelten Zeitplan vorsieht: Die maximale Gültigkeitsdauer öffentlicher TLS/SSL-Zertifikate sinkt auf 200 Tage im März 2026, 100 Tage im März 2027 und 47 Tage im März 2029. Die Planungen sollten sich an diesem Zeitplan orientieren und nicht an einer pauschalen Gültigkeitsdauer von 90 Tagen.

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

Kürzere Gültigkeitsdauern vervielfachen die Häufigkeit der Erneuerung jedes öffentlich zugänglichen Zertifikats. Unternehmen, die die Zertifikatsverwaltung manuell durchführen, werden feststellen, dass sich die Erneuerungshäufigkeit ab dem 200-Tage-Schritt etwa verdoppelt und bei jedem weiteren Schritt weiter ansteigt. Dadurch wird aus einer gelegentlichen Aufgabe ohne Automatisierung eine ständige operative Belastung.

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

PKI- und Zertifikatsteams sind für Inventarisierung, Erkennung und Richtlinien zuständig. Sicherheitsteams legen Gültigkeitsdauer, Schlüssellänge und Widerrufsregeln fest. Plattform- und DevOps-Teams integrieren die Zertifikatsausstellung in CI/CD-Pipelines. Compliance-Teams stellen sicher, dass die Erneuerung und das Inventarreporting während des gesamten Übergangs den bestehenden Audit-Frameworks entsprechen.

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

Laut der DigiCert Trust Pulse Survey vom Juli 2025 berichteten 45 % der Unternehmen über Ausfallzeiten im Zusammenhang mit Zertifikaten. 37.5 % dieser Ausfälle ließen sich direkt auf abgelaufene Zertifikate zurückführen, die aufgrund der heute längeren Gültigkeitsdauern nicht mehr gültig sind. Die manuelle Überwachung im 47-Tage-Rhythmus erhöht die Häufigkeit der gleichen Fehlerarten: Ausfälle, Datenverlust, Abstrafungen bei Suchmaschinen und Reputationsschäden.

Wie kann Automatisierung das Risiko von Zertifikatsausfällen verringern?

Die automatische Erneuerung beseitigt die beiden Hauptursachen für Zertifikatsausfälle: das Vergessen des Erneuerungsdatums und einen zu langsamen manuellen Prozess, der nicht rechtzeitig vor Ablauf der Gültigkeit abgeschlossen werden kann. Eine CLM-Plattform initiiert die Erneuerung nach einem festen Zeitplan mit ausreichend Vorlaufzeit, um einen fehlgeschlagenen ersten Versuch zu korrigieren – unabhängig von der Anzahl der Zertifikate.

Welche Kennzahlen sollten die Teams nach der Implementierung verfolgen?

Verfolgen Sie die Vollständigkeit des Zertifikatsbestands (einschließlich selbstsignierter und Schattenzertifikate), den Prozentsatz der Zertifikate mit automatischer Verlängerung, die Ausfallrate bei der Verlängerung, die durchschnittliche Zeit bis zur Neuausstellung nach einem Ausfall und die Anzahl der Zertifikate, die in jeder Phase des Zeitplans noch eine manuelle Bearbeitung erfordern.

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

Die 47-Tage-Frist, die ab März 2029 gilt, ist der letzte Schritt des in diesem Artikel beschriebenen Zeitplans des CA/B-Forums. Die für die 200-Tage- und 100-Tage-Schritte erforderlichen Ermittlungs-, Inventarisierungs- und Automatisierungsarbeiten bilden dieselbe Grundlage wie die für die 47-Tage-Zertifizierung notwendigen Schritte; es ist kein separates Projekt erforderlich.

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

Multi-Cloud- und Hybridumgebungen benötigen eine zentrale Zertifikatsverwaltungs- und CLM-Plattform, die alle Cloud-Anbieter und lokalen Zertifizierungsstellen abdeckt, anstatt die Verwaltung für jede Umgebung separat durchzuführen. Die Zertifikatserkennung muss alle Umgebungen umfassen, da Schattenzertifikate häufiger auftreten, wenn die Infrastruktur auf verschiedene Anbieter verteilt ist.