TLS-Zertifikatsverwaltung im Jahr 2026: 7 Probleme und wie man sie behebt

Die Verwaltung von TLS -Zertifikaten umfasst den gesamten Prozess der Ermittlung, Ausstellung, Erneuerung, Überwachung und des Widerrufs von TLS/SSL-Zertifikaten, die die Websites, APIs und internen Dienste eines Unternehmens schützen. Da die Gültigkeitsdauer von Zertifikaten auf etwa 47 Tage sinkt, ist eine manuelle Verwaltung nicht mehr praktikabel. Automatisierte Erneuerung, vollständige Transparenz der Zertifikatskette und klare Zuständigkeiten entwickeln sich von bewährten Verfahren zu betrieblichen Notwendigkeiten.

Im April 2025 verabschiedete das CA /Browser Forum die Abstimmung SC-081v3 , eine schrittweise Reduzierung der maximalen Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate von 398 auf nur noch 47 Tage. Die erste Reduzierung ist bereits in Kraft getreten: Die maximale Gültigkeitsdauer sank am 15. März 2026 auf 200 Tage, am 15. März 2027 auf 100 Tage und erreicht am 15. März 2029 47 Tage. Für Teams, die Zertifikatserneuerungen noch immer über Tabellenkalkulationen, E-Mail-Erinnerungen und manuelle Tickets abwickeln, ist dies keine ferne Richtlinienänderung, sondern eine sich langsam entwickelnde operative Krise.

Phase	Datum des Inkrafttretens	Maximale TLS-Gültigkeit	Ungefähre Verlängerungen pro Jahr
vorheriger Ausgangswert	Bis zum 14. März 2026	398 Tage	~1
Phase 1 (aktuell)	März 15 2026	200 Tage	~2
Phase 2	März 15 2027	100 Tage	~4
Phase 3	März 15 2029	47 Tage	~8

Quelle: CA/Browser Forum Ballot SC-081v3 (angenommen im April 2025). Die Wiederverwendungszeiträume für Domain Control Validation (DCV) verkürzen sich parallel und erreichen bis März 2029 nur noch 10 Tage, sodass selbst die Validierungsdaten hinter jedem Zertifikat nahezu kontinuierlich aktualisiert werden müssen.

Ein schwerwiegender, ungeplanter Zertifikatsausfall kann, wenn man die Folgeausfälle in nachgelagerten Systemen und den Aufwand für die Wiederherstellung berücksichtigt, Kosten in Millionenhöhe verursachen. Laut der DigiCert Trust Pulse Survey (2. Juli 2025) erlebten 45 % der Unternehmen im vergangenen Jahr Serviceausfälle aufgrund von Zertifikatsproblemen. Der Ablauf von Zertifikaten zählt dabei zu den drei größten Herausforderungen für CISOs im Zertifikatsmanagement. Abgelaufene und falsch verwaltete Zertifikate gehören weiterhin zu den am besten vermeidbaren Ursachen für Serviceunterbrechungen und lassen sich mit den richtigen Prozessen und Tools am einfachsten beheben.

Dieser Blogbeitrag erläutert die sieben häufigsten Ursachen für Zertifikatsfehler in realen Unternehmensumgebungen und gibt konkrete Hinweise, wie jedes einzelne Problem gelöst werden kann, bevor die 47-Tage-Frist zum Standard wird.

Kurzantwort: Was ist TLS-Zertifikatsverwaltung und warum ist 2026 alles anders?

Die Verwaltung von TLS-Zertifikaten umfasst den gesamten Prozess der Ermittlung, Ausstellung, Erneuerung, Überwachung und des Widerrufs von TLS/SSL-Zertifikaten für die Websites, APIs und internen Dienste eines Unternehmens. Ab 2026 ist die Situation anders, da die schrittweise Gültigkeitsreduzierung des CA/Browser Forums (Abstimmung SC-081v3, April 2025) die maximale Gültigkeitsdauer bereits auf 200 Tage verkürzt hat. Die ab März 2029 geltende Gültigkeitsdauer von 47 Tagen macht die manuelle Verwaltung im Unternehmensmaßstab betrieblich nicht mehr praktikabel.

Wichtige Erkenntnisse

• Der CA/Browser Forum-Abstimmungsantrag SC-081v3 (April 2025) reduziert die maximale Gültigkeitsdauer von TLS-Zertifikaten in drei Phasen: 200 Tage ab dem 15. März 2026; 100 Tage ab dem 15. März 2027; 47 Tage ab dem 15. März 2029. Parallel dazu verkürzen sich die DCV-Wiederverwendungszeiträume bis März 2029 auf 10 Tage, was bedeutet, dass Validierungsdaten nahezu kontinuierlich zusammen mit den Zertifikaten selbst aktualisiert werden müssen.
• Laut der DigiCert Trust Pulse-Umfrage (2. Juli 2025) erlebten 45 % der Unternehmen im vergangenen Jahr Serviceausfälle aufgrund von Zertifikatsproblemen. Bei einem 47-tägigen Zyklus beträgt das Zeitfenster zwischen einer versäumten Verlängerung und einem Produktionsausfall weniger als sieben Wochen. Dies verkürzt die ohnehin schon knappe Zeit, die manuelle Prozesse bieten.
• Die sieben in diesem Leitfaden beschriebenen Probleme sind nicht neu. Neu ist jedoch, dass kürzere Lebensdauern den Puffer beseitigen, der sie bisher überlebbar machte. Unvollständige Bestandsaufnahme, manuelle Erneuerung, fehlende Kettenüberwachung, ungeschützte private Schlüssel, fehlende benannte Eigentümer, inkonsistente Profile und ein fehlender PQC-Bereitschaftsplan bergen bei höheren Erneuerungsfrequenzen jeweils ein kumulatives Risiko.
• Das NIST finalisierte FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) am 13. August 2024. Jede heute neu aufgebaute oder modernisierte TLS-Zertifikatsverwaltungsarchitektur muss Kryptoagilität für die Einführung von Post-Quanten-Algorithmen beinhalten, da die heute ausgestellten Zertifikate auch zum Zeitpunkt der PQC-Migrationsfristen noch gültig sein werden.
• Am 21. September 2026 werden im Rahmen des Cryptographic Module Validation Program (CMVP) des NIST alle FIPS-140-2-Zertifikate in die Liste der historischen Zertifikate aufgenommen. Ab diesem Datum qualifizieren sich nur noch FIPS-140-3-Module für neue Beschaffungen der US-Bundesregierung. Die Planung von HSM-Upgrades wird somit zu einer kurzfristigen und nicht zu einer zukünftigen Aufgabe.

Für wen ist TLS-Zertifikatsmanagement im Jahr 2026 relevant?

Die 47-tägige Zertifikatserneuerungspflicht stellt eine funktionsübergreifende operative Umstellung dar. Jede der unten aufgeführten Rollen ist direkt davon betroffen, ob die Zertifikatsmanagement-Infrastruktur des Unternehmens vor Ablauf der jeweiligen Frist auf den neuen Erneuerungsrhythmus skalieren kann.

Funktion / Rolle (Role) *	Warum es wichtig ist	Aktionselement
PKI-Administratoren	Eigenverantwortliche Zertifikatserkennung, Bestandsverwaltung, CA-Integration und ACME/EST-Registrierungskonfiguration; verantwortlich dafür, dass keine Zertifikate in den nicht verwalteten Bereich gelangen.	Erstellen oder aktualisieren Sie ein vollständiges Zertifikatsinventar mithilfe von CBOM Secure; ACME- oder EST-Clients auf allen TLS-fähigen Systemen konfigurieren; alle CA-Ausstellungsprotokolle integrieren in CertSecure Manager für einheitliche Bestandsverwaltung und automatisierte Verlängerung
Sicherheitsarchitekten	Eigene Zertifikatsprofilrichtlinie (Algorithmen, Schlüssellängen, Gültigkeitsdauern, SAN-Anforderungen), HSM-Schlüsselschutzstandards und Krypto-Agilitätsarchitektur; verantwortlich für die Sicherstellung, dass die Zertifikatsverwaltungsinfrastruktur Post-Quanten-Algorithmen ohne Pipeline-Neugestaltung unterstützen kann	Definition und Durchsetzung von Zertifikatsprofilrichtlinien über eine CLM-Richtlinien-Engine; Evaluierung des HSM-Upgrades auf FIPS 140-3 Level 3 vor der CMVP-Frist im September 2026; beginnen PQC-Bereitschaftsbewertung
Plattform-/DevOps-Teams	Eigene ACME-Clientkonfiguration auf TLS-basierten Systemen, Zertifikatsbereitstellungspipelines sowie die Integration der Zertifikatserneuerung in Service Mesh und API-Gateway; am wahrscheinlichsten treten Ausfälle aufgrund von Ablauf auf, wenn die automatische Registrierung nicht vor Verkürzung der Gültigkeitsdauer konfiguriert ist.	Prüfen Sie alle TLS-Endpunkte auf ACME-Clientkonfiguration; bestätigen Sie, dass die automatische Erneuerung vollständig getestet wird, einschließlich Bereitstellung und Service-Neustart; integrieren Sie die Zertifikatserneuerung in CI/CD-Pipelines für containerisierte und Cloud-native Workloads.
Compliance-Teams	Es muss nachgewiesen werden, dass die Zertifikatserneuerungszyklen, der Schlüsselschutz, die Algorithmenstandards und die Protokollierung von Audits den Anforderungen von PCI DSS, HIPAA, DORA, NIS2 und den jeweils geltenden regulatorischen Bestimmungen entsprechen; die Überwachung der Protokolle zur Zertifikatstransparenz wird zunehmend als Kontrollmaßnahme zur Einhaltung der Vorschriften gefordert.	Die vierteljährliche Prüfung sollte die Vollständigkeit des Zertifikatsbestands, das Ablaufdatum von Zwischenzertifikaten und die Abdeckung der automatischen Verlängerung umfassen; es sollte sichergestellt werden, dass der HSM-Schlüsselschutz für regulierte Umgebungen FIPS 140-3 Level 3 erfüllt; die Zertifikatsprofilrichtlinie sollte als formale Compliance-Kontrolle dokumentiert werden.
CISOS	Sie tragen die Verantwortung für das Risiko von Ausfällen aufgrund ablaufender Zertifikate und für die Einhaltung der Zeitpläne nach der Umstellung auf Quantenmigration. 45 % der Unternehmen verzeichneten im vergangenen Jahr (DigiCert Trust Pulse Survey, 2. Juli 2025) im Rahmen des bisherigen jährlichen Erneuerungszyklus Ausfallzeiten aufgrund von Zertifikatsablauf. Bei einer Frist von 47 Tagen sind die Auswirkungen versäumter Erneuerungen größer und treten häufiger auf.	Beauftragen Sie eine Bewertung des Zertifikatslebenszyklusmanagements (CLM), um bestehende Automatisierungslücken zu quantifizieren; fordern Sie, dass der Zertifikatsstatus in die Sicherheitsberichterstattung des Unternehmens aufgenommen wird; finanzieren Sie CLM-Tools und HSM-Infrastruktur vor jeder Frist des CA/B-Forums.

Die 7 Probleme: Problem, Auswirkungen auf das Geschäft, Lösung und Verantwortlicher

Nutzen Sie diese Tabelle als Checkliste für die Durchführung der jeweiligen Maßnahmen vor den Fristen der Zertifizierungsstellen/Browserforen. Jede Zeile ordnet einen der sieben häufigsten Fehler im TLS-Zertifikatmanagement seinen Auswirkungen auf das Geschäft im 47-Tage-Rhythmus, der erforderlichen Lösung und dem zuständigen Team zu.

Aufgabenstellung:	Geschäftliche Auswirkungen nach 47 Tagen	Empfohlene Lösung	Eigentümer
Unvollständiges Zertifikatsinventar	Schattenzertifikate, die außerhalb des offiziellen Verfahrens ausgestellt wurden, verfallen ohne Vorwarnung; sie werden beim ersten Durchlauf typischerweise um ein Drittel oder mehr unterschätzt; jedes unentdeckte Zertifikat stellt einen potenziellen Ausfall dar.	Kombinieren Sie aktives Netzwerk-Scanning mit der Integration von CA-Ausstellungsprotokollen in CertSecure Manager;; verwenden CBOM Secure für umgebungsübergreifende kryptografische Inventarisierung einschließlich Cloud-nativer und privater PKI-CA-Quellen	PKI-Administrator
Manuelle Zertifikatserneuerung	Bei einer Gültigkeitsdauer von 47 Tagen bleiben nach einem zweiwöchigen Erneuerungs- und Wiederherstellungspuffer nur noch etwa 33 nutzbare Tage übrig; die manuelle, ticketbasierte Erneuerung ist nicht auf acht Zyklen pro Jahr und Zertifikat über Tausende von Endpunkten skalierbar.	ACME- oder EST-Clients auf allen TLS-fähigen Systemen bereitstellen; Erneuerung über CertSecure Manager automatisieren; sicherstellen, dass die Erneuerungsauslöser die CA-spezifischen Ausstellungsfristen berücksichtigen (EV-CAs benötigen möglicherweise 10-20 Werktage).	PKI-Administrator-/Plattformteam
Überwachung der Blattkette	Zwischenzertifikate (Gültigkeit 2–5 Jahre) verfallen stillschweigend; sobald ein Zertifikat abläuft, verlieren alle darunterliegenden Zertifikate gleichzeitig ihre Gültigkeit, unabhängig davon, wie kürzlich diese verlängert wurden.	Konfigurieren Sie die Überwachung der gesamten Vertrauenskette einschließlich Zwischenzertifizierungsstellen und Stammzertifizierungsstellen; legen Sie 90-Tage-Warnungen für jede Zwischenzertifizierungsstelle oder Stammzertifizierungsstelle in einem aktiven Vertrauenspfad fest; verwenden Sie die Kettenüberwachung von CertSecure Manager für alle CA-Quellen.	PKI-Administrator
Private Schlüssel nicht hardwaregeschützt	Ein erneuertes Zertifikat bietet keinen Sicherheitsvorteil, wenn der private Schlüssel kompromittiert ist; softwaregespeicherte Schlüssel sind anfällig für Extraktion; FIPS 140-2 HSMs werden am 21. September 2026 in die NIST CMVP Historical List aufgenommen.	Speichern Sie alle privaten Schlüssel hochrangiger Zertifikate in FIPS 140-3 Level 3 HSMs; erweitern Sie die HSM-Anforderungen vertraglich auf alle Drittanbieter, die Zertifikate in Ihrem Auftrag verwalten; bewerten HSM-as-a-Service für HSMs mit aktualisierbarer Algorithmus-Firmware für PQC-Bereitschaft	Sicherheitsarchitekt / PKI-Administrator
Kein benannter Zertifikatsinhaber	Fehlt ein benannter Eigentümer, wird die Erneuerung entweder ganz verpasst oder von zwei Teams, die nichts voneinander wissen, doppelt durchgeführt; Abweichungen zwischen Staging- und Produktionsumgebung führen dazu, dass Produktionszertifikate ablaufen, während Staging-Zertifikate erneuert werden; dies ist der häufigste Indikator für wiederkehrende Zertifikatsausfälle.	Weisen Sie jedem Zertifikat im CLM-Inventar einen benannten Eigentümer und ein Backup zu; konfigurieren Sie automatische Erneuerungs-Workflows, die zu festgelegten Vorlaufzeiten an diesen Eigentümer weitergeleitet werden; behandeln Sie Staging- und Produktionsumgebungen als unabhängige, nachverfolgbare Assets im CertSecure Manager.	PKI-Administrator-/Anwendungsteam
Inkonsistente Zertifikatsprofile	Die zunehmende Verbreitung von Algorithmen und Profilen (RSA-2048 vs. RSA-4096 vs. ECDSA, Single- vs. Multi-SAN, interne vs. externe Zertifizierungsstellen) führt dazu, dass die Migration nach der Quantenintegration Monate dauert; die Workflows zur Zertifikatsausstellung werden zunehmend für die unautorisierte Ausstellung missbraucht.	Erzwingen Sie Zertifikatsprofile bei der Ausstellung durch eine CLM-Richtlinien-Engine, die Schlüssellänge, Signaturalgorithmus, SAN-Konfiguration und Gültigkeitsdauer validiert, bevor eine Anfrage die Zertifizierungsstelle erreicht; verwenden CertSecure Manager Profildurchsetzung über alle CA-Quellen hinweg	Sicherheitsarchitekt / PKI-Administrator
Kein PQC-Bereitschaftsplan	Heute ausgestellte RSA-2048-Zertifikate könnten innerhalb des Gültigkeitszeitraums eines Quantencomputers liegen, der sie knacken kann; der NIST-Entwurf IR 8547 sieht vor, RSA-2048 für neue föderale Systeme nach 2030 als veraltet zu kennzeichnen; eine erzwungene Migration unter Druck ist der teuerste Weg, diese Umstellung vorzunehmen.	Integrieren Sie Krypto-Agilität in die Architektur der Zertifikatsausstellung, sodass Algorithmen ausgetauscht werden können, ohne die Pipeline neu aufbauen zu müssen; kennzeichnen Sie alle Zertifikate im CLM-Inventar nach Algorithmus; beginnen Sie mit der PQC-Bereitschaftsplanung über die PQC-Bereitschaftsbewertung und der PQC Kompetenzzentrum	Sicherheitsarchitekt / CISO

1. Wissen Sie, wie viele Zertifikate Sie besitzen?

Die meisten Unternehmen unterschätzen den Umfang ihres TLS-Zertifikatmanagements bei der ersten Bestandsaufnahme, üblicherweise um ein Drittel oder mehr. Dieses Muster ist in PKI- Systemen (Public Key Infrastructure) von Unternehmen immer wieder zu beobachten. Die Zertifikate, die Teams in Tabellenkalkulationen oder ITSM-Tickets (IT Service Management) erfassen, bilden selten das vollständige Bild ab.

Zertifikate werden auf Webservern, Load Balancern, API-Gateways, internen Microservices, IoT-Endpunkten und Entwicklungsumgebungen verwendet, die einmal eingerichtet und dann vergessen werden. Jedes dieser Systeme hat eine eigene Erneuerungsstelle und reagiert unterschiedlich auf Fehler.

Die Lösung besteht in der Kombination von aktivem Netzwerk-Scanning mit der Integration in Ihre CA-Ausstellungsprotokolle. CAs protokollieren jedes von ihnen ausgestellte Zertifikat. Der Abgleich dieser Liste mit den Ergebnissen Ihrer Scanner deckt Schattenzertifikate auf, die außerhalb des regulären Prozesses ausgestellt und in keinem Nachverfolgungssystem erfasst wurden. Für vollständige kryptografische Transparenz über alle CA-Quellen hinweg, einschließlich Cloud-nativer und privater PKI-Umgebungen, erstellt CBOM Secure eine kryptografische Stückliste. Diese zeigt Zertifikatsherkunft, Algorithmenabdeckung und CA-Quelldaten in Cloud-, On-Premises- und Hybridumgebungen an.

Schattenzertifikate laufen überproportional häufig unbemerkt ab, eben weil sie von keinem Team überwacht werden. Die Schließung dieser Bestandslücke ist die Voraussetzung für jede weitere Verbesserung im TLS-Zertifikatsmanagement.

2. Erneuern Sie Ihre Zertifikate immer noch manuell?

Ein 398-Tage-Zertifikat bot den Erneuerungsteams eine Laufzeit von etwa 13 Monaten. Ein 47-Tage-Zertifikat lässt nach Abzug eines zweiwöchigen Erneuerungs- und Wiederherstellungspuffers noch etwa 33 nutzbare Tage übrig. In großen Unternehmen, wo Tausende von Zertifikaten rollierend erneuert werden, führt eine manuelle Erneuerung statistisch gesehen zwangsläufig zu Ausfällen.

Das ACME -Protokoll (Automated Certificate Management Environment) eliminiert den menschlichen Eingriff im Erneuerungsprozess vollständig. Ein Client auf dem Zielsystem generiert eine neue Zertifikatsignierungsanforderung ( CSR ), führt die Domänenvalidierung bei der Zertifizierungsstelle durch und installiert das ausgestellte Zertifikat – alles ohne Ticket oder E-Mail-Verlauf.

Interne PKI-Umgebungen benötigen dasselbe Automatisierungsmodell, typischerweise über eine Enterprise-PKI-Services-Schicht, die ACME- oder EST- Endpunkte (Enrollment over Secure Transport) für interne Zertifikatsnutzer bereitstellt. Für Organisationen, die eine vollständig verwaltete CA-Schicht evaluieren, bietet PKI as a Service native ACME- und EST-Unterstützung mit integrierter automatisierter Ausstellung und Verlängerung. Die vom CA/Browser Forum festgelegte maximale Gültigkeitsdauer von 47 Tagen gilt nur für öffentlich vertrauenswürdige TLS-Zertifikate; Organisationen, die eine private PKI betreiben, können längere Gültigkeitsdauern beibehalten, selbst wenn sie dieselben Automatisierungsprinzipien anwenden.

Die Automatisierung gewährleistet zudem die Profilkonsistenz. Bei jeder Verlängerung kann eine validierte Zertifikatvorlage angewendet werden, wodurch verhindert wird, dass sich veraltete Algorithmen und falsch konfigurierte alternative Subjektnamen im gesamten Netzwerk ansammeln.

3. Überwachen Sie die vollständige Zertifikatsvertrauenskette?

Jedes von einem Server vorgelegte TLS-Zertifikat verweist auf ein Zwischenzertifikat, welches wiederum auf ein von Browsern und Betriebssystemen als vertrauenswürdig eingestuftes Stammzertifikat verweist. Die Erneuerung des Endbenutzerzertifikats erneuert nicht das Zwischenzertifikat.

Zwischenzertifikate haben in der Regel eine Gültigkeitsdauer von zwei bis fünf Jahren. Läuft ein solches Zertifikat ab, verlieren alle darunterliegenden Zertifikate gleichzeitig ihre Gültigkeit, unabhängig davon, wie lange diese Zertifikate zuletzt erneuert wurden. Dies ist eine der häufigsten Ursachen für großflächige Ausfälle mehrerer Dienste.

Die Überwachung der Gültigkeit von Zwischenzertifikaten ist in der Praxis deutlich seltener als die Überwachung von Endzertifikaten allein. Ein effektives TLS-Zertifikatsmanagement verfolgt die gesamte Zertifikatskette und löst 90 Tage nach Ablauf der Gültigkeit eines Zwischen- oder Stammzertifikats in einem aktiven Vertrauenspfad Warnmeldungen aus. CertSecure Manager bietet Kettenüberwachung über alle Zertifizierungsstellen hinweg und zeigt den Ablauf von Zwischen- und Stammzertifikaten zusammen mit dem Ablauf von Endzertifikaten in einem einzigen, einheitlichen Verzeichnis an.

4. Sind die privaten Schlüssel auf Hardwareebene geschützt?

Ein erneuertes Zertifikat bietet keinen Sicherheitsvorteil, wenn der zugehörige private Schlüssel kompromittiert wurde. HSM -Geräte (Hardware-Sicherheitsmodule) generieren und speichern private Schlüssel in manipulationssicherer Hardware, wodurch die Schlüsselextraktion gegen Softwareangriffe resistent wird.

In regulierten Umgebungen ist die Beschaffungsgrundlage ein HSM, das gemäß FIPS 140-3 Level 3 validiert ist . Dieses System erzwingt identitätsbasierte Authentifizierung und löscht Schlüsselmaterial bei Manipulationserkennung. Dieses Zeitfenster für die Einhaltung der Vorschriften schließt sich nun: Am 21. September 2026 werden im Rahmen des Cryptographic Module Validation Program (CMVP) des NIST alle FIPS 140-2-Zertifikate in die Liste der historischen Zertifikate aufgenommen. Danach qualifizieren sich nur noch FIPS 140-3-Module für neue Beschaffungen der US-Bundesregierung.

In einer ausgereiften TLS-Zertifikatsverwaltungsarchitektur verlässt der private Schlüssel für jedes hochwertige Zertifikat niemals das HSM. Signiervorgänge finden innerhalb des Geräts statt, und das Schlüsselmaterial wird der Anwendungsschicht niemals zugänglich gemacht.

Ein erheblicher Anteil von Zertifikatsvorfällen entsteht in Anbieterumgebungen, in denen HSM-Anforderungen vertraglich nicht durchgesetzt werden. Unternehmen sollten die wichtigsten Schutzstandards auf alle Drittanbieter ausweiten, die Zertifikate in ihrem Auftrag verwalten.

Da die Branche den Übergang zur Post-Quanten-Kryptographie vollzieht , vermeidet die Auswahl von HSMs mit aktualisierbarer Algorithmus-Firmware nun einen Hardware-Aktualisierungszyklus, wenn neue Standards finalisiert werden.

5. Ist auf jedes Zertifikat ein namentlich genannter Inhaber eingetragen?

Das gravierendste Problem im TLS-Zertifikatmanagement ist nicht ein Mangel an Tools, sondern eine fehlende Zuständigkeit. Wenn kein benanntes Team für die Erneuerung eines bestimmten Systems zuständig ist, wird diese entweder komplett übersehen oder von zwei Teams, die nichts voneinander wissen, doppelt durchgeführt.

Die Forschung zu operationellen Risiken zeigt immer wieder, dass nicht zugeordnete Prozesse zu den stärksten Indikatoren für wiederkehrende Vorfälle zählen. Das Zertifikatsmanagement ist ein zentraler Bereich, in dem Sicherheits-, Netzwerk- und Anwendungsteams eng zusammenarbeiten. Alle drei gehen möglicherweise davon aus, dass jeweils eines der anderen verantwortlich ist, und keines wird aktiv, bis ein Ausfall das Gegenteil beweist.

Die Lösung besteht darin, jedem Zertifikat im Bestand einen benannten Eigentümer und einen benannten Backup-Eigentümer zuzuweisen. Diese Daten werden im Zertifikatsverwaltungssystem gespeichert, anstatt im Gedächtnis einer einzelnen Person oder in einem gemeinsamen Posteingang. Erneuerungsprozesse werden automatisch und innerhalb festgelegter Fristen an diesen Eigentümer weitergeleitet.

Ein damit zusammenhängender Fehler ist die Abweichung zwischen Staging- und Produktionsumgebung. Ein in der Staging-Umgebung erneuertes Zertifikat wird in der Produktionsumgebung nicht automatisch erneuert. Tools zur Zertifikatsverwaltung sollten diese als unabhängig voneinander verwaltete Assets behandeln und nicht als dasselbe Zertifikat in unterschiedlichen Kontexten.

6. Sind die Zertifikatsprofile im gesamten Portfolio einheitlich?

Wenn einzelne Teams die Zertifikatskonfiguration unabhängig voneinander verwalten, entsteht eine heterogene Zertifikatslandschaft, deren Verwaltung kostspielig wird. Einige Zertifikate verwenden RSA-2048, andere RSA-4096, wieder andere ECDSA. Manche verfügen über ein einziges SAN, andere über Dutzende. Einige werden von internen Zertifizierungsstellen ausgestellt, andere von externen Zertifizierungsstellen mit unterschiedlichen Validierungsanforderungen.

Diese Inkonsistenz ist kein oberflächliches Problem. Sie erhöht die Kosten kryptografischer Migrationen unmittelbar . Wenn ein veralteter Algorithmus in Tausenden von Zertifikaten ersetzt werden muss, können Organisationen mit festgelegten Profilen diese Migration innerhalb weniger Tage durchführen. Organisationen ohne diese Profile benötigen Monate. Für vollständige Transparenz der Algorithmen in allen Umgebungen erstellt CBOM Secure die kryptografische Stückliste, die eine profilbasierte Migration überschaubar macht und nicht zu einem aufwendigen Ermittlungsprojekt werden lässt.

Die Prozesse zur Zertifikatsausstellung stellen ein zunehmend ausgenutztes Angriffsziel dar – die unautorisierte Ausstellung von Zertifikaten kann genauso schädlich sein wie die Kompromittierung eines privaten Schlüssels. Die Durchsetzung von Profilen zum Zeitpunkt der Ausstellung mithilfe einer Richtlinien-Engine verringert die Angriffsfläche im Anfrageprozess.

Der CertSecure Manager von Encryption Consulting validiert Schlüssellänge, Signaturalgorithmus, SAN-Konfiguration und Gültigkeitsdauer, bevor eine Anfrage die Zertifizierungsstelle erreicht. Diese Richtlinienebene sorgt für eine konsistente und nicht chaotische TLS-Zertifikatsverwaltung im großen Maßstab.

7. Ist Ihre Organisation auf den Übergang nach dem Quantenzeitalter vorbereitet?

Heute ausgestellte Zertifikate mit RSA-2048 könnten innerhalb des Gültigkeitszeitraums eines funktionsfähigen Quantencomputers liegen, der diesen Schlüssel knacken kann. Der Übergang zur Post-Quanten-Kryptographie ist nicht erst ab 2035 relevant, sondern betrifft jedes Zertifikat, das heute ausgestellt wird und in drei bis fünf Jahren noch als vertrauenswürdig gelten soll. Der NIST-Entwurf IR 8547 empfiehlt, RSA-2048 und andere 112-Bit-Sicherheitsalgorithmen für neue Systeme der Bundesregierung nach 2030 nicht mehr zu verwenden und alle quantenanfälligen Public-Key-Algorithmen nach 2035 zu verbieten.

Das NIST finalisierte am 13. August 2024 seine ersten Post-Quanten-Kryptographiestandards: FIPS 203 (ML-KEM, für Schlüsselkapselung, abgeleitet von CRYSTALS-Kyber), FIPS 204 (ML-DSA, für digitale Signaturen, abgeleitet von CRYSTALS-Dilithium) und FIPS 205 (SLH-DSA, ein zustandsloses, Hash-basiertes Signaturverfahren, abgeleitet von SPHINCS+). Ein vierter Standard, FIPS 206 (FN-DSA, abgeleitet von FALCON), durchläuft derzeit den NIST-Standardisierungsprozess; die Finalisierung wird Ende 2026 oder 2027 erwartet.

Zertifikatsausstellungssysteme müssen diese neuen Algorithmen künftig unterstützen. Organisationen, die Krypto-Agilität in ihre TLS-Zertifikatsverwaltungsarchitektur integriert haben – also die Möglichkeit, Algorithmen auszutauschen, ohne die Ausstellungskette neu aufbauen zu müssen –, können schnell reagieren. Beginnen Sie Ihre PQC-Bereitschaftsplanung mit der PQC-Bereitschaftsanalyse und nutzen Sie die Ressourcen des PQC Center of Excellence.

Organisationen, die US-amerikanische nationale Sicherheitssysteme unterstützen, stehen vor einem strengeren Mandat: Die CNSA 2.0- Suite der NSA spezifiziert ML-KEM-1024 und ML-DSA-87, deren Einführung bereits im Gange ist; kategoriespezifische Fristen für die ausschließliche Nutzung laufen von 2030 für Netzwerkgeräte und Firmware-Signierung bis 2033 für Betriebssysteme und Cloud-Dienste, wobei die vollständige Migration aller nationalen Sicherheitssysteme bis 2035 gemäß NSM-10 erforderlich ist.

Die Auswahl von HSMs mit aktualisierbarer Algorithmusunterstützung, die Pflege sauberer Zertifikatsbestände mit Algorithmus-Tagging über CBOM Secure und die Durchsetzung von Profilrichtlinien über eine zentrale Plattform sind die drei Voraussetzungen für eine überschaubare Post-Quanten-Kryptographie-Migration.

Die Verschlüsselungsschicht , die Ihre Daten während der Übertragung schützt, ist nur so stark wie die zugrunde liegenden Zertifikats- und Schlüsselverwaltungsverfahren. Unternehmen, die diese Planung aufschieben, werden unter Zeitdruck gezwungen sein, ihre Daten umzustellen.

Was immer wieder schiefgeht: Muster in realen Implementierungen

In Unternehmensumgebungen treten unabhängig von Branche und Unternehmensgröße immer wieder dieselben Fehlermuster auf. Alarmmüdigkeit ist das erste. Wenn für Tausende von Zertifikaten Benachrichtigungen über deren Ablauf in 90, 60, 30 und 14 Tagen eingehen, beginnen die Teams, diese zu unterdrücken. Die hohe Anzahl an Benachrichtigungen führt dazu, dass die Mitarbeiter die Signale ignorieren und echte Notfälle übersehen werden.

Eine weitere Fehlerquelle ist die Fehlberechnung der Bearbeitungszeit. Externe Zertifizierungsstellen mit erweiterten Validierungsanforderungen benötigen unter Umständen 10 bis 20 Werktage für die Ausstellung eines Zertifikats. Ein Verlängerungsantrag, der 30 Tage vor Ablauf eines 47-tägigen Zertifikats gestellt wird, kann daher möglicherweise nicht mehr rechtzeitig vor dessen Ablauf bearbeitet werden. Automatisierte Systeme müssen die spezifischen Ausstellungsfristen der Zertifizierungsstellen in ihren Verlängerungsauslösern berücksichtigen.

Ein drittes Muster besteht darin, die Verwaltung von TLS-Zertifikaten als Aufgabe des IT-Betriebs anstatt als Sicherheitsmaßnahme zu behandeln. Fehlerhafte Zertifikatsverwaltung ist ein anerkannter Faktor für Sicherheitslücken und Dienstausfälle im Zusammenhang mit Verschlüsselung. Wird der Status von Zertifikaten nicht an die Sicherheitsleitung gemeldet, spiegelt sich diese Vernachlässigung in der Priorität wider, die dem Thema im Unternehmen beigemessen wird.

Welche Sicherheitskontrollen muss die Zertifikatsautomatisierung umfassen?

Die Automatisierung reduziert zwar menschliche Fehler im Erneuerungsprozess, schafft aber neue Angriffsflächen. Der ACME-Client, die CA-API-Zugangsdaten und die Zertifikatsbereitstellungspipeline werden zu Zielen für Angreifer, die gefälschte Zertifikate in Ihrem Namensraum ausstellen wollen.

Die von automatisierten TLS-Zertifikatverwaltungssystemen zur Authentifizierung gegenüber Zertifizierungsstellen verwendeten Anmeldeinformationen müssen regelmäßig ausgetauscht und in einem HSM oder einem Geheimnisspeicher, nicht in Konfigurationsdateien, gespeichert werden. Kompromittierte Anmeldeinformationen einer Zertifizierungsstelle ermöglichen die Ausstellung von Zertifikaten in Ihrer Domäne.

Die Protokolle der Zertifikatstransparenz (CTR) bieten einen Erkennungsmechanismus, der von Unternehmen häufig nicht ausreichend genutzt wird. Alle öffentlich vertrauenswürdigen Zertifikate werden bei ihrer Ausstellung öffentlich protokolliert. Die Überwachung der CTR-Protokolle auf unerwartete Ausstellungen in Ihrer Domäne deckt unautorisierte Zertifikate innerhalb von Stunden, nicht Wochen, auf.

Für Organisationen, die eine unabhängige Bewertung ihrer aktuellen Situation benötigen, bietet Tailored Advisory Services Architekturüberprüfungen und Implementierungsfahrpläne an, die auf den Zeitplan des CA/Browser Forums abgestimmt sind.

Warum das 47-Tage-Fenster die entscheidende Funktion ist

Die sieben oben genannten Probleme sind nicht neu. Sie treten heutzutage in nahezu jedem Unternehmen mit Zertifikaten auf. Neu ist jedoch, dass die 47-tägige Gültigkeitsdauer den Puffer beseitigt, der sie bisher überlebbar machte. Zwischen einer verpassten Benachrichtigung und dem Ablauf eines Zertifikats bleibt nicht mehr genügend Zeit, um ein Ticket zu erstellen, einen Genehmiger zu finden und eine manuelle Verlängerung durchzuführen.

Die Organisationen, die die fortlaufenden Fristen des CA/Browser Forums ohne Unterbrechung bewältigen können, bauen jetzt ihre Infrastruktur für das TLS-Zertifikatsmanagement auf: vollständige Bestandsaufnahme, automatisierte Erneuerung, erzwungene Profile, Kettenüberwachung, Hardware-Schlüsselschutz, klare Eigentumsverhältnisse und Krypto-Agilität.

Wer wartet, wird unter operativem Druck zu einer erzwungenen Modernisierung gezwungen sein, was die teuerste Art ist, Infrastrukturänderungen vorzunehmen.

Um zu besprechen, wie Ihre Organisation im Hinblick auf die Frist 2029 dasteht, kontaktieren Sie Encryption Consulting für eine Bewertung des Zertifikatslebenszyklusmanagements.

Wie Verschlüsselungsberatung helfen kann

Encryption Consulting unterstützt Unternehmen dabei, die oben beschriebenen Sicherheitslücken zu schließen, bevor verkürzte Gültigkeitsdauern zu Ausfällen führen. Unsere Plattform für das Zertifikatslebenszyklusmanagement, CertSecure Manager , erkennt Zertifikate im gesamten Netzwerk, automatisiert die Erneuerung über ACME und EST, setzt Zertifikatsprofile bei der Ausstellung durch und überwacht die gesamte Vertrauenskette, einschließlich Zwischen- und Stammzertifikaten, mit proaktiven, vom Inhaber gesteuerten Benachrichtigungen.

Für kryptografische Transparenz in allen Umgebungen erstellt CBOM Secure die kryptografische Stückliste, die Schattenzertifikate, veraltete Algorithmen und CA-Quelldaten in Cloud-, On-Premises- und Hybridumgebungen aufdeckt – und PKI-Teams so das vollständige Inventar zur Verfügung stellt, das Voraussetzung für jede Verbesserung in diesem Leitfaden ist.

Für internes Vertrauen entwerfen und betreiben unsere Enterprise PKI Services gehärtete CA-Hierarchien mit HSM-gestütztem Schlüsselschutz gemäß FIPS 140-3 . Unsere Beratungsteams integrieren Krypto-Agilität und Post-Quanten-Kryptographie in Ihre Architektur, sodass Sie die FIPS 203-, FIPS 204- und FIPS 205-Algorithmen ohne Umstrukturierung Ihrer Ausgabeprozesse implementieren können. Für Organisationen, die einen Managed-CA-Ansatz evaluieren, bietet PKI as a Service native ACME- und EST-Unterstützung mit von Anfang an integriertem automatisiertem Lebenszyklusmanagement.

Mit unseren maßgeschneiderten Beratungsleistungen bieten wir unabhängige Lagebeurteilungen, Architekturprüfungen und Implementierungsfahrpläne, die auf den Zeitplan des CA/Browser Forums abgestimmt sind, sodass Ihr Wechsel zu 47-Tage-Zertifikaten geplant und nicht erzwungen wird.

Fazit

Die Umstellung auf 47-Tage-TLS-Zertifikate ist keine Zukunftsvision. Es handelt sich um einen geplanten, mehrstufigen Prozess, der bereits im Gange ist. Die maximale Gültigkeitsdauer beträgt aktuell 200 Tage und sinkt weiter. Die sieben in diesem Artikel beschriebenen Probleme sind dieselben, die seit Jahren zu Zertifikatsausfällen führen. Neu ist lediglich, dass die kürzeren Gültigkeitsdauern den manuellen Sicherheitspuffer beseitigen, der die Wiederherstellung bisher ermöglichte.

Organisationen, die jetzt handeln – indem sie ein vollständiges Inventar aufbauen, die Verlängerung automatisieren, Profile durchsetzen, die gesamte Blockchain überwachen, Schlüssel in FIPS 140-3-zertifizierter Hardware schützen, klare Eigentumsverhältnisse zuweisen und auf Kryptoagilität setzen – werden jede Frist problemlos einhalten können. Wer zögert, wird sich einer erzwungenen, unter hohem Zeitdruck stehenden Modernisierung gegenübersehen, die sich nach dem Zeitplan der Branche richtet. Die Aufgaben sind bekannt und die Fristen öffentlich; die einzige Variable ist, ob Sie vor oder nach dem nächsten Ablaufdatum beginnen, das einen Dienst lahmlegt.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus „TLS-Zertifikatsverwaltung im Jahr 2026: 7 Probleme und wie man sie behebt“?

Die sieben in diesem Artikel beschriebenen Fehler im TLS-Zertifikatsmanagement traten in Unternehmensumgebungen schon immer auf. Die Abstimmung des CA/Browser Forums (SC-081v3, April 2025) beseitigt jedoch den Puffer, der sie bisher überbrückbar machte. Da die maximale Gültigkeitsdauer von TLS-Zertifikaten nun 200 Tage beträgt und bis März 2029 auf 47 Tage sinkt, reicht die Zeitspanne zwischen einer verpassten Verlängerungsbenachrichtigung und dem Ablauf des Zertifikats nicht mehr aus, um einen manuellen Prozess abzuschließen. Unternehmen müssen daher vor jedem Stichtag ein vollständiges Zertifikatsinventar, eine automatisierte Verlängerung, verbindliche Zertifikatsprofile, eine vollständige Überwachung der Zertifikatskette, Hardware-Schlüsselschutz, eindeutige Eigentumsverhältnisse und Krypto-Agilität implementieren.

Warum ist die Verwaltung von TLS-Zertifikaten für PKI-Teams in Unternehmen wichtig?

Enterprise-PKI-Teams sind direkt für die Zertifikatsinfrastruktur verantwortlich, die bis 2029 auf etwa acht Erneuerungszyklen pro Jahr und Zertifikat skaliert werden muss. Laut der DigiCert Trust Pulse Survey (2. Juli 2025) verzeichneten 45 % der Unternehmen im vergangenen Jahr Serviceausfälle aufgrund von Zertifikatsproblemen. PKI-Teams, die Ausstellung, Erneuerung und Überwachung nicht vor Ablauf der 47-Tage-Frist automatisiert haben, sehen sich mit jedem Erneuerungszyklus einem steigenden Ausfallrisiko ausgesetzt, da das Zertifikatsvolumen zunimmt und die Gültigkeitsdauer gleichzeitig abnimmt.

Welche Risiken erhöhen sich, wenn die Verwaltung von TLS-Zertifikaten manuell erfolgt?

Die manuelle Verwaltung von TLS-Zertifikaten erhöht das Risiko von: Ausfällen aufgrund ablaufender Zertifikate, da das Erneuerungsfenster für ticketbasierte Prozesse im 47-Tage-Rhythmus zu kurz ist; der Verbreitung von Schattenzertifikaten, bei denen außerhalb des formalen Prozesses ausgestellte Zertifikate ohne Benachrichtigung ablaufen; dem Ablauf von Zwischenzertifikaten, der dazu führt, dass alle darunter liegenden Endzertifikate gleichzeitig als nicht vertrauenswürdig gelten; Zuständigkeitslücken, wenn kein benanntes Team für die Erneuerung verantwortlich ist; und der unkontrollierten Ausbreitung von Algorithmen, die die Migration zur Post-Quanten-Kryptographie Monate statt Tage dauern lässt.

Welche Teams sollten für die Verwaltung der TLS-Zertifikate zuständig sein?

PKI-Administratoren sind verantwortlich für die Zertifikatserkennung, die Bestandsverwaltung, die CA-Integration und die Konfiguration der ACME/EST-Registrierung. Sicherheitsarchitekten verantworten die Zertifikatsprofilrichtlinien, die HSM-Schlüsselschutzstandards und die Architektur für kryptografische Agilität. Plattform- und DevOps-Teams konfigurieren den ACME-Client auf TLS-basierten Systemen und verwalten die Zertifikatsbereitstellungspipelines. Compliance-Teams stellen die Prüfnachweise bereit, die belegen, dass Erneuerungsintervalle, Schlüsselschutz und Algorithmusstandards den regulatorischen Anforderungen entsprechen. CISOs bewerten das Risiko von Ausfällen durch Zertifikatsablauf und planen die Migration nach der Quantenmigration.

Wie hängt die TLS-Zertifikatsverwaltung mit der Zertifikatslebenszyklusverwaltung zusammen?

Die Verwaltung von TLS-Zertifikaten ist der operative Teilbereich des Zertifikatslebenszyklusmanagements (CLM) und konzentriert sich speziell auf die Ermittlung, Ausstellung, Verlängerung, Überwachung und den Widerruf von TLS/SSL-Zertifikaten. Eine CLM-Plattform wie CertSecure Manager bietet ein einheitliches Inventar, automatisierte Verlängerungsprozesse, die Durchsetzung von Zertifikatsprofilen, die vollständige Überwachung der Zertifikatskette und die vom Zertifikatsinhaber gesteuerte Benachrichtigung. Dies ermöglicht eine nachhaltige TLS-Zertifikatverwaltung im Unternehmensmaßstab. Ohne CLM kann selbst eine gut konzipierte ACME-Automatisierung (Advanced Certificate-Measurement Management) Schattenzertifikate übersehen, die nie in den Verlängerungsprozess aufgenommen wurden.

Wie sollten Organisationen den Erfolg im TLS-Zertifikatsmanagement messen?

Wichtige Kennzahlen: Prozentsatz der Zertifikate, die in automatisierte Erneuerungsprozesse eingebunden sind (Ziel: 100 % aller TLS-Zertifikate); Anzahl der Ausfälle aufgrund abgelaufener Zertifikate pro Quartal (Ziel: null); durchschnittliche Zeit vom Auslöser der Erneuerung bis zur Bereitstellung des erneuerten Zertifikats (Ziel: unter 1 Stunde, vollautomatisiert); Prozentsatz der CA- und Zwischenzertifikate, die zusammen mit den Endbenutzerzertifikaten überwacht werden (Ziel: 100 %); Prozentsatz der Zertifikate, deren benannter Eigentümer in der CLM-Plattform erfasst ist (Ziel: 100 %); und Prozentsatz der Zertifikate, die genehmigte Algorithmen verwenden (Ziel: 100 % Konformität mit dem vorgegebenen Zertifikatsprofil).

Was sollte im Rahmen der TLS-Zertifikatsverwaltung regelmäßig geprüft oder überwacht werden?

Überwachen Sie kontinuierlich: den Ablaufstatus aller registrierten Zertifikate, einschließlich Zwischen- und Stammzertifikate; die Erfolgs- und Fehlerraten der ACME-Erneuerung pro Domain; Warnmeldungen des Certificate Transparency Logs bei unerwarteten Zertifikatsausstellungen in Ihrer Domain; und den Status der CA-API-Anmeldeinformationenrotation. Führen Sie vierteljährliche Audits durch: vollständige Überprüfung des Zertifikatsbestands, um sicherzustellen, dass keine Schattenzertifikate außerhalb des verwalteten Bereichs vorhanden sind; Einhaltung der Zertifikatsprofile; Ablaufdaten von Zwischenzertifikaten mit einer Warnschwelle von 90 Tagen; und Überprüfung der PQC-Bereitschaft über das PQC Center of Excellence.

Wie wirkt sich die Verwaltung von TLS-Zertifikaten auf Cloud-, Hybrid- oder Multi-CA-PKI-Umgebungen aus?

In Cloud- und Hybridumgebungen werden TLS-Zertifikate von verschiedenen Quellen ausgestellt: öffentliche Zertifizierungsstellen (CAs) für externe Zertifikate, private PKI oder PKIaaS für interne Dienste und Cloud-native CAs für Cloud-Workloads. Multi-CA-Umgebungen benötigen ein CLM-Tool mit einheitlicher Bestandsübersicht über alle CA-Quellen hinweg. CBOM Secure bietet eine kryptografische Bestandsübersicht für alle CA-Quellen in Cloud-, On-Premises- und Hybridumgebungen und stellt sicher, dass Schattenzertifikate beliebiger CA-Quellen erfasst werden, bevor sie unbemerkt ablaufen.

Welche häufigen Fehler sollten Teams bei der Verwaltung von TLS-Zertifikaten vermeiden?

Die häufigsten Fehler: Überwachung nur der Endbenutzerzertifikate und nicht der Zwischen- oder Stammzertifikate (ein abgelaufenes Zwischenzertifikat führt dazu, dass alle darunter liegenden Endbenutzerzertifikate gleichzeitig als nicht vertrauenswürdig gelten); Behandlung von Staging- und Produktionszertifikaten als dasselbe Asset; Speicherung von CA-API-Zugangsdaten in Konfigurationsdateien anstatt in einem HSM oder einem Geheimnisspeicher; Nichtüberwachung der Certificate Transparency-Protokolle auf unautorisierte Ausstellungen; und Aufschieben der Planung der Post-Quanten-Kryptographie, bis regulatorische Fristen eine überstürzte Migration erzwingen.

Welche Voraussetzungen müssen für die Automatisierung der TLS-Zertifikatserneuerung erfüllt sein?

Voraussetzungen sind: ein vollständiges Zertifikatsinventar mit CBOM Secure oder CertSecure Manager zur Identifizierung aller Zertifikate, einschließlich Schattenzertifikate, die nicht im aktuellen Trackingsystem erfasst sind; ein benannter Eigentümer, der für jedes Zertifikat in der CLM-Plattform hinterlegt ist; ACME- oder EST-Client-Software, die auf allen TLS-basierten Systemen konfiguriert ist; CA-API-Zugangsdaten, die in einem HSM oder Secrets Vault gespeichert und regelmäßig rotiert werden; eine Zertifikatsprofilrichtlinie, die genehmigte Algorithmen, Schlüssellängen, Gültigkeitsdauern und SAN-Anforderungen definiert; und die Überwachung des Ablaufs von Zwischenzertifikaten, die parallel zur Überwachung von Endzertifikaten konfiguriert ist.

Was sollte vierteljährlich für die TLS-Zertifikatsverwaltung aktualisiert werden?

Vierteljährliche Aktualisierung: Vollständiger Scan des Zertifikatsinventars, der bestätigt, dass 100 % der TLS-Zertifikate in automatisierten Erneuerungsprozessen registriert sind; Prüfung der Zertifikatsprofilkonformität, die bestätigt, dass alle Zertifikate zugelassene Algorithmen verwenden; Überprüfung des Ablaufs von Zwischen- und Stammzertifikaten mit einer 90-Tage-Warnschwelle; Überprüfung der CA/Browser-Forum-Richtlinien auf neue DCV-Methodenänderungen oder Beschleunigungen des Gültigkeitszyklus; PQC-Bereitschaftsprüfung über das PQC Center of Excellence für die Migrationsplanung gemäß NIST FIPS 203, 204 und 205; und CBOM Secure -Kryptografieinventarlauf, der bestätigt, dass seit der letzten Überprüfung keine Schattenzertifikate oder veraltete Algorithmen in den Zertifikatsbestand gelangt sind.