CertSecure Manager 3.3 ist da – und kommt genau dann, wenn Sie ihn am dringendsten brauchen. 

CertSecure Manager 3.3 ist die Version von Encryption Consulting für das Zertifikatslebenszyklusmanagement, die für die schrittweise Reduzierung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate auf 47 Tage bis 2029 durch das CA/Browser Forum entwickelt wurde. Sie bietet ein Zertifikatsrisikoprofil, Massenwiderruf und Eigentumsübertragung, automatische Erneuerung, neue CA- und Vault-Integrationen sowie eine erweiterte Erkennung, sodass Zertifikatsteams die Erneuerungsfrequenz etwa achtmal so hoch wie heute ohne manuelle Engpässe gestalten können.

Wer sich in den letzten zwölf Monaten auch nur ansatzweise mit dem Thema Zertifikatsverwaltung auseinandergesetzt hat, weiß bereits, dass sich die Rahmenbedingungen grundlegend ändern. Die Gültigkeitsdauer öffentlicher TLS-Zertifikate, die über ein Jahrzehnt lang die Grundlage für die Funktionsweise des Internets bildeten, wird drastisch verkürzt. Die Zeiten, in denen man ein Zertifikat einmal jährlich erneuern und sich dann keine weiteren Gedanken mehr darum machen musste, sind endgültig vorbei. 

CertSecure Manager v3.3 ist unsere Version für diese neue Realität. Sie enthält gezielte Änderungen, die Ihrem Team helfen sollen, in einer Welt, in der Zertifikate alle paar Wochen statt alle 13 Monate ablaufen, nicht nur zu bestehen, sondern idealerweise auch erfolgreich zu sein. Wir zeigen Ihnen, was sich geändert hat, welche Auswirkungen dies auf Ihre Abläufe hat und warum wir die einzelnen Komponenten so entwickelt haben.

CertSecure Manager v3.3 wurde für eine zentrale Branchenrealität entwickelt: Die Gültigkeitsdauer von TLS-Zertifikaten sinkt in den nächsten drei Jahren von 398 auf 47 Tage, und die manuelle Zertifikatsverwaltung ist mit diesem Tempo nicht mehr praktikabel. Die Version enthält 18 neue Funktionen und Verbesserungen, die auf die kürzeren Erneuerungszyklen abgestimmt sind.

Zu den wichtigsten Neuerungen gehören ein Zertifikatsrisikoprofil , das jedes Zertifikat in Ihrem Bestand bewertet, die vollständige Visualisierung der Vertrauenskette, die Möglichkeit zum Massenwiderruf und zur Massenübertragung von Zertifikatsinhaberschaften, die automatische Erneuerung auf allen Webserver-Agenten, native Integrationen von Google Public CA und ServiceNow, erweiterte Unterstützung für Azure Key Vault einschließlich Regierungsmandanten, die Erkennung von AWS- und IIS-CCS sowie ein Ansible-ACME-Automatisierungspfad. Wenn Sie TLS-Zertifikate in größerem Umfang verwenden, ist diese Version bestens für die zukünftigen Anforderungen gerüstet.

Wichtige Erkenntnisse

• CertSecure Manager 3.3 wurde für die stufenweise Reduzierung der Gültigkeit von TLS-Zertifikaten durch das CA/Browser Forum entwickelt: 200 Tage (März 2026), 100 Tage (März 2027) und 47 Tage (März 2029).
• Die Version enthält 18 Funktionen und Verbesserungen, darunter ein Zertifikatsrisikoprofil, die vollständige Visualisierung der Vertrauenskette, Massenwiderruf, Massenübertragung des Eigentums, automatische Erneuerung über alle Webserver-Agenten hinweg und ein neuer Ansible ACME-Automatisierungspfad.
• Die Trust Pulse Survey von DigiCert ergab, dass 45 % der Unternehmen im vergangenen Jahr Ausfallzeiten im Zusammenhang mit Zertifikaten erlebten, und 37.5 % führten einen Ausfall auf ein abgelaufenes Zertifikat zurück – genau den Fehlermodus, den diese Version verhindern soll.
• Für Kunden, die bereits eine aktuelle Version nutzen, ist das Upgrade ein planmäßiger, risikoarmer Prozess; neue Anwender sollten jetzt damit beginnen, da der 100-Tage-Meilenstein im März 2027 erreicht wird.
• Die Teams für PKI, Sicherheit, Plattform und Compliance haben jeweils eine eigene Aufgabe; die untenstehende Verantwortlichkeits-/Aufgabenmatrix und die Tabelle der Voraussetzungen für die jeweilige Aufgabe zeigen genau, was und wer dafür zuständig ist.

Direkt zu: Zusammenfassung | Checkliste zur Vorbereitung | Voraussetzungen | Upgrade-Schritte | Tabelle „Voraussetzungen und Maßnahmen“ | Vorher/Nachher | Anleitung zum Rollback | Erfolgskennzahlen | Verantwortlichkeits-/Maßnahmenmatrix | Nächste Schritte | FAQ

Zusammenfassung für die Teams PKI, Sicherheit, Plattform und Compliance

Wenn Sie eine dieser Funktionen leiten, finden Sie hier die Entscheidung, die diese Version unterstützt, und die Kurzanleitung dazu.

• PKI-Teams: Voraussetzungen bestätigen, Upgrade auf Version 3.3 planen und Bewertung des Zertifikatsrisikoprofils nach der Inbetriebnahme validieren.
• Sicherheitsteams: Nutzen Sie das neue Zertifikatsrisikoprofil, um Zertifikate mit hohem und sehr hohem Risiko zu finden, bevor sie einen Zwischenfall verursachen.
• Plattform-/DevOps-Teams: Wir setzen auf Zero-Touch-Erneuerung und den Ansible ACME-Automatisierungspfad, um die Erneuerungshäufigkeit zu erhöhen, ohne zusätzlichen manuellen Aufwand zu betreiben.
• Compliance-Teams: Die Verwendung von Risikoprofilberichten und Aufzeichnungen über Massenübertragungen von Eigentumsrechten dient als revisionssicherer Nachweis dafür, wie das Zertifikatsrisiko gemanagt wird.

Kurzcheckliste zur Einsatzbereitschaft

Nutzen Sie diese Checkliste, um zu beurteilen, ob Sie tatsächlich bereit für das Upgrade sind und nicht nur wissen, dass die neue Version existiert.

• Ich habe Ihre aktuelle CertSecure Manager-Version bestätigt und die Versionshinweise zu Version 3.3 gelesen.
• Es wurde ermittelt, welche CA-Konnektoren, Tresore und Webserver-Agenten von diesem Upgrade betroffen sind.
• Wir haben ein Wartungsfenster eingeplant und, im Falle von HA-Bereitstellungen, die Reihenfolge der Knoten-Upgrades mit Ihrem Encryption Consulting-Kundenbetreuungsteam bestätigt.
• Ich habe Ihre aktuelle CertSecure Manager-Konfiguration, Datenbank und benutzerdefinierten Automatisierungsskripte gesichert.
• Die Bewertungskriterien für das Zertifikatsrisikoprofil (Schlüssellänge, Signaturalgorithmus, Gültigkeitsdauer) wurden überprüft, sodass die Ergebnisse nach dem Upgrade keine Überraschung darstellen.

Voraussetzungen vor der Implementierung

• Eine unterstützte, aktuelle Version von CertSecure Manager; Ihr Account-Team kann die minimale Basisversion für ein direktes Upgrade auf 3.3 bestätigen.
• Administrativer Zugriff auf CertSecure Manager und auf jede verbundene Zertifizierungsstelle, jeden Tresor oder jedes Registrierungsziel, das Sie im Rahmen der neuen Funktionen einbinden möchten, einschließlich Google Public CA, Azure Key Vault, AWS und ServiceNow.
• Ein Änderungs- oder Wartungsfenster, da das Upgrade einen Neustart des Dienstes auf den Manager-Knoten und, bei HA-Umgebungen, sequenzielle Knoten-Upgrades beinhaltet.
• Ein aktuelles, getestetes Backup der CertSecure Manager-Datenbank und -Konfiguration, das unmittelbar vor dem Upgrade erstellt wurde.
• Für den Ansible ACME-Automatisierungspfad sind ein vorhandener Ansible-Steuerungsknoten und Kenntnisse eines ACME-fähigen Ansible-Moduls erforderlich, wie z. B. community.crypto.acme_certificate.
• Für die ServiceNow-Integration wird eine bestehende ServiceNow-Instanz mit Berechtigungen zur Installation von Store-Apps benötigt.

Schrittweiser Upgrade-Workflow

Dies ist der allgemeine Arbeitsablauf für das Upgrade auf CertSecure Manager 3.3. Ihr Encryption Consulting-Kundenbetreuungsteam wird Ihnen die umgebungsspezifischen Details bestätigen, insbesondere bei HA-Bereitstellungen.

1. Lesen Sie die Versionshinweise und diese Anleitung sorgfältig durch. und bestätigen, dass die oben genannten Voraussetzungen erfüllt sind.
2. Benachrichtigen Sie die betroffenen Teams und planen Sie das Wartungsfenster ein. einschließlich der HA-Knotensequenzierungsanleitung Ihres Account-Teams, falls zutreffend.
3. Sichern Sie die aktuelle Konfiguration, die Datenbank und alle benutzerdefinierten Automatisierungsskripte.
4. Installieren Sie das 3.3-Upgrade. Wir folgen dem umgebungsspezifischen Pfad, den Ihr Account-Team vorgibt, sei es Single-Node- oder sequenzielle HA.
5. Überprüfen Sie das Upgrade: Prüfen Sie, ob die Version von CertSecure Manager angezeigt wird, ob die Spalte „Certificate Risk Profile score“ in der Inventar- und Zertifikatssuche erscheint und ob CA-Pinging und die neue Registerkarte „Metriken“ ausgefüllt sind.
6. Automatisierung wieder aktivieren oder erweitern: Richten Sie Webserver-Agenten auf automatische Erneuerung ein, verbinden Sie alle neuen Zertifizierungsstellen oder Tresore, die Sie verwenden möchten, und aktualisieren Sie Ansible-Playbooks auf das ACME-Modul, wenn Sie diesen Weg wählen.
7. Rollback-Bereitschaft bestätigen vor dem Schließen des Wartungsfensters.
8. Überwachen Sie den ersten automatisierten Verlängerungszyklus Nach dem Upgrade sollten Sie die unten aufgeführten Erfolgskennzahlen als Ausgangswert erfassen.

Beispielkonfiguration: Deklarieren des Zertifikatsstatus mit Ansible

Der Ansible ACME-Automatisierungspfad in Version 3.3 ermöglicht es Ihnen, den gewünschten Status eines Zertifikats in Ihrer Ansible-Konfiguration festzulegen, anstatt es manuell auszustellen und zu erneuern. Das folgende Beispiel veranschaulicht das allgemeine Vorgehen mit Ansible. community.crypto.acme_certificate Modul; konsultieren Sie die Dokumentation von CertSecure Manager für die genauen Aufgabenparameter, die Ihre Umgebung benötigt.

- name: Ensure TLS certificate is issued and current
  community.crypto.acme_certificate:
    account_key_src: /etc/pki/acme/account.key
    csr: /etc/pki/tls/csr/www.example.com.csr
    dest: /etc/pki/tls/certs/www.example.com.crt
    acme_directory: https://acme-v02.api.letsencrypt.org/directory
    acme_version: 2
    terms_agreed: true
    challenge: dns-01

Durch die Ausführung im Rahmen eines geplanten Playbooks wird sichergestellt, dass das bereitgestellte Zertifikat automatisch mit dem deklarierten Status übereinstimmt. Dieses Muster sollten Teams, die Ansible bereits in großem Umfang einsetzen, auch auf ihre von CertSecure verwalteten Zertifikate ausweiten.

Tabelle der Voraussetzungen für die Umsetzung

Voraussetzung	Warum es wichtig ist	Action	Eigentümer
Aktuelle CertSecure Manager-Basisversion	3.3 Upgrades von einer unterstützten, kürzlich erschienenen Version; das Überspringen von Versionen kann die Migration erschweren.	Bitte bestätigen Sie die aktuelle Version mit Ihrem Account-Team, bevor Sie einen Termin vereinbaren.	PKI-Team
Administratorzugriff auf verbundene Zertifizierungsstellen und Tresore	Neue Integrationen (Google Public CA, Azure Key Vault Government, AWS, ServiceNow) erfordern Anmeldeinformationen zur Konfiguration.	Anmeldeinformationen vor dem Wartungsfenster sammeln oder bestätigen.	PKI-Team / Plattformteam
Wartungsfenster und HA-Sequenzplan	Das Upgrade umfasst einen Neustart des Dienstes und, für Hochverfügbarkeit, sequenzielle Knotenaktualisierungen.	Legen Sie das Zeitfenster fest und bestätigen Sie die Reihenfolge mit Ihrem Account-Team.	Plattform-Team
Sicherung vor dem Upgrade	Stellt die Umgebung wieder her, falls die Überprüfung nach dem Upgrade fehlschlägt.	Erstellen und testen Sie eine Sicherungskopie der Konfiguration, der Datenbank und der benutzerdefinierten Skripte.	PKI-Team
Ansible-Steuerungsknoten (bei Verwendung der ACME-Automatisierung)	Erforderlich, um das Beispielmuster community.crypto.acme_certificate auszuführen	Vor dem Pilotprojekt die Verfügbarkeit der Ansible-Tools und den Zugriff prüfen	Plattform-/DevOps-Team
ServiceNow-Instanz (falls die App übernommen wird)	Erforderlich ist die Installation der CertSecure Certificate Management App aus dem ServiceNow Store.	Berechtigungen für die App-Installation im Store bestätigen	Plattformteam / ITSM-Team

Vorher und Nachher: ​​Die Umstellung des operativen Arbeitsablaufs

Aufgabe	Vorher (Manuelle Vorgehensweise)	Nachher (mit CertSecure Manager 3.3)
Verlängerungsausführung	Manuelle Neuausstellung und erneute Bereitstellung pro Zertifikat, nachverfolgt in Tabellenkalkulationen oder Kalendererinnerungen.	Die automatische Verlängerung erfolgt von der CA-Registrierung über die Lieferung und Installation bis hin zur Service-Aktualisierung – ganz ohne menschliches Eingreifen.
Risikotransparenz	Ad-hoc-Erkennungsskripte und manuelle Tabellenkalkulationsprüfung zur Auffindung schwacher Schlüssel oder langlebiger Zertifikate	Das Zertifikatsrisikoprofil bewertet jedes Zertifikat automatisch; Filterung nach „Schwerwiegend“ in Sekundenschnelle
Massenwiderruf oder -bereinigung	Zertifikate wurden einzeln widerrufen und neu vergeben	Massenwiderruf und Massenübertragung von Eigentumsrechten verarbeiten viele Zertifikate in einem einzigen Vorgang.
Fehlerbehebung in der Kette	Fehlende Zwischenprodukte in den CA-Portalen manuell aufspüren	Vollständige Visualisierung der Vertrauenskette und Download der Kette aus der Zertifikatsdetailansicht
CA und Infrastrukturgesundheit	Erst nach Anmeldefehlern oder einem Systemausfall entdeckt	CA-Ping und die Registerkarte „Metriken“ zeigen proaktiv den Zustand von CA und dem Automatisierungsagenten an.

Rollback-Anleitung

Da das Upgrade eine Konfigurations- und Datenbankmigration beinhaltet, planen Sie den Rollback vor Beginn der Aktualisierung und nicht erst, wenn etwas schiefgeht.

• Die Sicherung vor dem Upgrade, die Konfiguration, die Datenbank und die benutzerdefinierten Skripte sollten zugänglich sein und auf Wiederherstellbarkeit getestet werden, nicht nur erfasst.
• Bei HA-Bereitstellungen sollten Sie mit Ihrem Account-Team abklären, welche Knotensequenzierung ein sicheres Rollback auf die vorherige Version ermöglicht, falls die Verifizierung fehlschlägt.
• Vermeiden Sie die Aktivierung neuer Automatisierungspfade, wie z. B. des Ansible ACME-Moduls oder neuer CA-Konnektoren, bis Sie sich vergewissert haben, dass das Core-Upgrade stabil ist, damit ein Rollback nicht auch die neu eingerichtete Automatisierung rückgängig machen muss.
• Falls die Verifizierung nach dem Upgrade fehlschlägt, stellen Sie die Daten aus der Sicherung vor dem Upgrade wieder her und kontaktieren Sie Ihr Encryption Consulting-Kundenbetreuungsteam, bevor Sie es erneut versuchen.

Häufige Fehler und wie man sie vermeidet

• Das Backup vor dem Upgrade wird übersprungen: Der häufigste Grund, warum ein schwieriges Upgrade unwiederbringlich verloren geht: Sichern Sie immer zuerst die Konfiguration, die Datenbank und die benutzerdefinierten Skripte.
• Aktualisierung von HA-Knoten außerhalb der vorgegebenen Reihenfolge: Die vom Account-Team vorgegebene Reihenfolge anwenden, anstatt die Knoten in beliebiger Reihenfolge zu aktualisieren.
• Unter der Annahme, dass die bestehende Automatisierung unverändert bleibt: Manche Agenten und CA-Konnektoren müssen in der neuen Benutzeroberfläche möglicherweise neu verbunden werden, selbst wenn die Anmeldeinformationen unverändert sind; überprüfen Sie dies lieber, als es anzunehmen.
• Die Ergebnisse des neuen Zertifikatsrisikoprofils werden ignoriert: Ein plötzlicher Anstieg der Anzahl schwerwiegender oder hochriskanter Zertifikate direkt nach einem Upgrade deutet in der Regel auf Zertifikate mit bereits schwachen Schlüsseln oder Algorithmen hin und nicht auf einen Fehler; untersuchen Sie dies, bevor Sie es verwerfen.
• Den Ansible ACME-Pfad nicht zuerst in einer Nicht-Produktionsumgebung testen: Bevor ein neuer Automatisierungspfad in die Produktionserneuerung eingebunden wird, sollte er anhand eines kleinen, repräsentativen Zertifikatssatzes validiert werden.

Erfolgskennzahlen, die nach der Implementierung verfolgt werden sollten

• Prozentsatz der Zertifikate, die gemäß dem Zertifikatsrisikoprofil als sicher oder mit niedrigem Risiko eingestuft werden, im Vergleich zu Zertifikaten mit hohem Risiko oder schwerwiegenden Risiken, monatlich erfasst.
• Der Anteil der per Zero-Touch-Automatisierung abgeschlossenen Verlängerungen im Vergleich zu manuellen Eingriffen ist entscheidend, da dieses Verhältnis darüber entscheidet, ob der 47-Tage-Rhythmus aufrechterhalten werden kann.
• Zeitersparnis beim Massenwiderruf und der Neuzuweisung der Inhaberschaft für eine definierte Anzahl von Zertifikaten im Vergleich zum vorherigen Verfahren, bei dem jedes Zertifikat einzeln widerrufen wurde.
• Anzahl der ausfallbezogenen Tickets oder Vorfälle im Zusammenhang mit Zertifikaten pro Quartal im Vergleich zu Ihrem Ausgangswert vor dem Upgrade.
• Zeitspanne von einer CA-Abstimmung oder einer Richtlinienänderung bis zur vollständigen Bestandsübersicht der betroffenen Zertifikate, unter Verwendung von CA-Pinging und der erweiterten Erkennung in 3.3.

Eigentümer- und Aktionsmatrix des Teams

Team	Verantwortung	Schlüsselaktion
PKI-Team	Besitzt das Upgrade selbst und das zugehörige Zertifikatsinventar.	Prüfen Sie die Voraussetzungen, planen Sie das Upgrade und überprüfen Sie die Bewertung des Zertifikatsrisikoprofils nach dem Upgrade.
Sicherheits Team	Verantwortlich für die Interpretation der Ergebnisse des Risikoprofils und die Bestätigung, dass keine zertifikatsabhängigen Workflow-Unterbrechungen auftreten.	Überprüfen Sie die Zertifikate für schwere und hohe Risiken innerhalb des ersten Verlängerungszyklus und stellen Sie sicher, dass die Massenwiderrufs-Runbooks aktuell sind.
Plattform-/DevOps-Team	Besitzt die Verdrahtungsautomatisierung, einschließlich Ansible ACME, Zero-Touch-Agenten und CI/CD, in der aktualisierten Umgebung	Validieren Sie das Ansible ACME-Beispiel anhand eines Nicht-Produktionszertifikatsatzes vor der Produktionseinführung.
Compliance-/Audit-Team	Besitzt Nachweise dafür, dass Zertifikatsrisiko und Eigentumsverhältnisse nachverfolgt und aktuell sind.	Nutzen Sie Risikoprofilberichte und Aufzeichnungen über Massenübertragungen von Eigentumsrechten als revisionssichere Nachweise in jedem Zyklus.

Was macht man als nächstes

• PKI-Teams: Prüfen Sie die Voraussetzungen und planen Sie das Upgrade auf Version 3.3 in diesem Quartal ein, falls Sie dies noch nicht getan haben.
• Sicherheitsteams: Wir planen, die Ergebnisse des Zertifikatsrisikoprofils innerhalb der ersten Woche nach dem Upgrade zu überprüfen.
• Plattformteams: Den Ansible ACME-Automatisierungspfad sollten Sie zunächst an einem nicht produktionsreifen Zertifikatssatz erproben, bevor Sie ihn breitflächig einsetzen.
• Compliance-Teams: Bitte bestätigen Sie, dass Ihr nächstes Audit Risikoprofil- und Eigentumsübertragungsaufzeichnungen als Nachweise vorlegen kann.

Die 47-Tage-Verschiebung

Am 11. April 2025 verabschiedete das CA/Browser Forum, der Branchenverband, der die Regeln für alle großen Browser und Zertifizierungsstellen festlegt, den Vorschlag SC-081v3. Dieser war ursprünglich von Apple eingebracht und von Sectigo, Google Chrome und Mozilla unterstützt worden. Die Abstimmung ergab 29 Ja-Stimmen, 0 Nein-Stimmen und fünf Enthaltungen. Alle vier großen Browserhersteller (Apple, Google, Microsoft und Mozilla) stimmten dafür, ebenso wie 25 Zertifizierungsstellen , darunter DigiCert, Sectigo, GlobalSign, GoDaddy und Amazon. Fünf Zertifizierungsstellen enthielten sich der Stimme und äußerten Bedenken hinsichtlich der operativen Umsetzung.

Die Abstimmung sieht eine schrittweise Verkürzung der Gültigkeitsdauer von TLS-Zertifikaten von derzeit maximal 398 Tagen auf nur noch 47 Tage bis zum Jahr 2029 vor. Der Zeitplan sieht wie folgt aus: 

• März 15, 2026: Die maximale Lebensdauer des TLS-Zertifikats sinkt auf 200 Tage, ebenso wie die Wiederverwendung der Domänenkontrollvalidierung auf 200 Tage.
• März 15, 2027: Die maximale Lebensdauer sinkt auf 100 Tage, die Wiederverwendbarkeit des DCV sinkt ebenfalls auf 100 Tage.
• März 15, 2029: Die maximale Lebensdauer sinkt auf 47 Tage, und die Wiederverwendungsdauer des DCV verkürzt sich auf nur noch 10 Tage.

Wir haben den ersten Meilenstein bereits überschritten. Die 200-Tage-Frist gilt ab sofort. 

Warum genau 47? Das entspricht einem 31-Tage-Monat, plus einem halben 30-Tage-Monat, plus einem Tag Puffer. Genug, um einen vernünftigen monatlichen Verlängerungsrhythmus zu gewährleisten, ohne dass die Betreiber keine Gewinnspanne mehr haben.

Was das konkret für Ihr Team bedeutet

Die Mathematik dahinter bereitet vielen schlaflose Nächte. Eine Organisation, die 1,000 Zertifikate verwaltet, muss im Rahmen des 47-Tage-Modells mit rund 7,766 Verlängerungsvorgängen pro Jahr rechnen. Das sind etwa 21 pro Tag – eine Verachtfachung gegenüber der heutigen Verlängerungshäufigkeit. 

Laut der am 2. Juli 2025 veröffentlichten DigiCert Trust Pulse Survey gaben 45 % der Unternehmen an, im vergangenen Jahr aufgrund von Zertifikatsproblemen Ausfallzeiten erlebt zu haben. 37.5 % dieser Unternehmen konnten einen Ausfall konkret auf ein abgelaufenes Zertifikat zurückführen. Eine achtfache Erhöhung der Erneuerungshäufigkeit vervielfacht die Wahrscheinlichkeit für diesen Fehler, sofern die Erneuerung nicht vollständig automatisiert erfolgt.

Der Zeitplan für diese achtfache Erhöhung stammt aus dem Wahlvorschlag SC-081v3 des CA/Browser Forums , der am 11. April 2025 verabschiedet wurde: maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate von derzeit 398 Tagen auf 200 Tage im März 2026, 100 Tage im März 2027 und 47 Tage bis März 2029.

Tabellenkalkulationen, Kalendererinnerungen, „Bob kümmert sich darum.“ Nichts davon ist skalierbar. Das CA/Browser-Forum hat diesbezüglich keinen Hehl gemacht: Die Unannehmlichkeiten sind beabsichtigt, denn in der Branche herrscht Einigkeit darüber, dass Automatisierung für die Sicherheit des Internets unerlässlich ist. 47-Tage-TLS-Zertifikate unterstreichen diese Notwendigkeit.

Es gibt drei wesentliche Gründe für die Verkürzung. 

• Begrenzung des Explosionsradius: Sollten Sie jetzt aufgefordert werden, ein privater Schlüssel Wird ein Zertifikat kompromittiert, ermöglicht ein 398-Tage-Zertifikat dem Angreifer über ein Jahr lang den Missbrauch. Ein 47-Tage-Zertifikat hingegen nur wenige Wochen.
• Umgehung der fehlerhaften Widerrufsfunktion: Der Wahlzettel enthält eine ausführliche Argumentation, dass das Zertifikatswiderrufssystem verwendet wird CRLs und OCSP ist unzuverlässig, da Browser diese Funktionen oft ignorieren. Kurze Gültigkeitsdauern sind ein ehrlicherer Mechanismus als ein Widerruf, der den Zugriff nicht tatsächlich widerruft.
• Krypto-Agilität für das Quantenzeitalter: Kürzere Lebensdauern erschweren es Angreifern, Taktiken nach dem Motto „Erfassen und später entschlüsseln“ umzusetzen, und beschleunigen bei Bedarf den Übergang zu neuen kryptografischen Algorithmen. NIST Die ersten Post-Quanten-Standards (ML-KEM, ML-DSA, SLH-DSA) wurden 2024 finalisiert und öffentlich Zertifizierungsstellen Die Ausgabe wird bereits in einer Pilotphase getestet. Migration deaktiviert RSA und ECDSA ist nicht länger fern. Eine Flotte von Zertifikaten, die bereits alle sechs Wochen erneuert wird, passt sich schneller an als eine, die alle dreizehn Monate erneuert wird.

CertSecure Manager 3.3 wurde unter Berücksichtigung all dieser drei Gegebenheiten entwickelt. Im Folgenden erfahren Sie, wie sich das in der Version auswirkt.

Erkenne das Risiko, bevor es dich sieht.

Wenn Sie Zertifikate achtmal häufiger erneuern müssen, benötigen Sie ein Dashboard, das Ihnen anzeigt, welche Zertifikate problematisch sind, bevor es zu Vorfällen kommt. Drei Änderungen in Version 3.3 ermöglichen genau das. 

Zertifikatsrisikoprofil 

 Jedes Zertifikat in Ihrem Bestand wird nun automatisch anhand eines Risikoprofils bewertet. Die Bewertung wird als Spalte in Ihren Bestandslisten und als Filter in der Zertifikatssuche angezeigt. Die Bewertung berücksichtigt drei Faktoren, die in der Vergangenheit die größten Probleme bei der Zertifikatsverwaltung verursacht haben:

• Tastenlänge: Kennzeichnung schwacher RSA-Schlüssel, veralteter ECDSA-Kurven und aller Werte unterhalb der aktuellen Branchenstandards.
• Signaturalgorithmus: Aufdecken von SHA1-Überbleibseln, schwachen Hashes und allem, was die nächste Abschaffungswelle nicht überstehen wird.
• Gültigkeitszeitraum: Wichtiger denn je, da die Branche den 398-Tage-über-200-über-100-über-47-Tage-Abstieg durchläuft.

Zertifikate werden in vier Stufen eingeteilt: Sicher, Niedriges Risiko, Hohes Risiko und Schwerwiegend. Durch Filtern, Sortieren und Berichten dieser Stufen können Sie beispielsweise die Frage „Zeig mir alle Zertifikate der Stufe ‚Schwerwiegend‘ im Produktivbetrieb“ stellen und erhalten innerhalb von Sekunden eine Antwort – anstatt erst ein Analyseskript und eine Excel-Tabelle auszuwerten. Dies liefert Ihnen außerdem die nötigen Informationen, wenn ein Auditor nach Ihrem Umgang mit kryptografischen Risiken fragt.

Visualisierung der Zertifikatsvertrauenskette 

Wenn ein TLS-Handshake fehlschlägt, liegt die Ursache oft an einem eher unspektakulären Problem in der Zertifikatskette: ein fehlendes Zwischenzertifikat, eine falsche Reihenfolge in der Kette oder ein veraltetes Stammzertifikat. CertSecure visualisiert nun die vollständige Vertrauenskette für jedes verwaltete Zertifikat direkt in der Zertifikatsdetailansicht.

Root- und Zwischenzertifikate sind direkt im Browser zugänglich, wobei jedes Kettenelement anklickbar ist, sodass Sie die Metadaten einsehen können, ohne den Bildschirm zu verlassen. Für Zertifikate von Drittanbietern unterstützt das System das Erstellen und Herunterladen der vollständigen Zertifikatskette. Dadurch entfällt die Suche nach Zwischenzertifikaten auf verschiedenen CA-Portalen, wenn Sie eine neue Anwendung bereitstellen müssen.

CA-Pinging und Systemmetriken

Zwei oft übersehene Funktionen runden die Transparenz ab. Eine neue CA-Ping-Funktion auf der CA-Verwaltungsseite ermöglicht die Überwachung, ob jede verbundene Zertifizierungsstelle erreichbar und funktionsfähig ist. Dies ist sowohl für die Diagnose fehlgeschlagener Registrierungen als auch für die proaktive Erkennung von CA-Ausfällen nützlich, bevor diese von den Benutzern bemerkt werden.

Der neue Tab „Metriken“ in den Einstellungen bietet Ihnen Echtzeit-Überwachung von CPU, Festplatte und RAM für jede CertSecure-Komponente: Automatisierungsagenten, CA-Konnektoren und Manager-Knoten gleichermaßen. Sie können Maschinen zur Ansicht hinzufügen oder entfernen, um sich auf die für Ihre Umgebung relevanten Aspekte zu konzentrieren. Wenn die Automatisierung das Rückgrat Ihrer Erneuerungsstrategie bildet, ist der einwandfreie Zustand dieser Infrastruktur unerlässlich. 

Überstehen Sie den Erneuerungszyklus mit Massenproduktion

Zwei lang ersehnte Funktionen werden in Version 3.3 eingeführt und dürften zusammen für die meisten Teams den größten Produktivitätsgewinn am ersten Tag bedeuten. 

Massenwiderruf

Sie können nun mehrere Zertifikate gleichzeitig in einem einzigen Vorgang widerrufen. Die Anwendungsfälle liegen auf der Hand, wenn Sie schon einmal damit zu tun hatten. 

• Wichtige Kompromissereignisse: Wenn ein HSM Wenn der Schlüsselspeicher kompromittiert wird, müssen Sie die Zertifikate schnell und umfassend widerrufen, nicht nur ein Zertifikat nach dem anderen.
• CA-Misstrauensereignisse: Wenn eine Zertifizierungsstelle aus einem Stammzertifikatspeicher entfernt wird (das kommt vor, fragen Sie jeden, der DigiNotar, Symantec oder eines der vielen neueren Beispiele miterlebt hat), müssen Sie die betroffenen Zertifikate sofort löschen.
• Routinemäßige Reinigung: Veraltete Testzertifikate, eingestellte Dienste, veraltete Umgebungen. Entziehen Sie diese gesammelt und machen Sie weiter.

Massenhafte Eigentumsübertragung

Die Inhaberschaft von Zertifikaten ändert sich ständig. Mitarbeiter verlassen das Unternehmen, Teams werden neu organisiert und Anwendungen neu zugewiesen. In Version 3.3 können Sie die Inhaberschaft vieler Zertifikate gleichzeitig übertragen. Das klingt zunächst unbedeutend, bis man zwei Tage damit verbringt, nach einer Umstrukturierung die E-Mail-Adresse des Inhabers in den einzelnen Zertifikatseinträgen zu aktualisieren. 

Beide Funktionen waren bereits in einer Welt mit 398 Tagen nützlich. In einer Welt mit 47 Tagen sind sie Standard. 

Automatisierung, die die Plattformen abdeckt, die die meisten Tools vergessen

Automatisierung funktioniert nur, wenn sie überall funktioniert. Bisher waren Automatisierungstools bei einfachen Zielen sehr leistungsstark, bei komplexen hingegen sehr schwach. CertSecure 3.3 schließt einige der am häufigsten geforderten Lücken.

Automatisierte Erneuerung für Citrix NetScaler, JBoss EAP und Wildfly

Die durchgängige Automatisierung der Zertifikatserneuerung ist nun auch für Citrix NetScaler, JBoss EAP und Wildfly verfügbar. Entscheidend ist, dass die Automatisierung den Abruf der Zertifikatskette als Teil des Erneuerungsprozesses übernimmt. So ruft der Agent die richtigen Zwischenzertifikate ab und fügt sie dem korrekten Keystore oder der richtigen Konfiguration hinzu, ohne dass Benutzer die Zertifikatsketten separat herunterladen und manuell zusammenfügen müssen. Dieses letzte Detail ist wichtiger als es zunächst scheint: Fehlkonfigurationen der Zertifikatskette gehören zu den häufigsten Ursachen für fehlgeschlagene Bereitstellungen. 

Automatische Erneuerung aller Webserver-Agenten

Alle CertSecure-Webserver-Erneuerungsagenten unterstützen jetzt die automatische Erneuerung. Das bedeutet, dass eine Zertifikatserneuerung von der CA-Registrierung über die Zustellung und Installation bis hin zum Neustart des Dienstes ohne menschliches Eingreifen abläuft. Dies ist das einzig nachhaltige Modell, wenn Sie alle sechs bis sieben Wochen erneuern.

Ansible-Zustandsverwaltung mit dem ACME-Modul

Für Umgebungen, die Infrastruktur als Code bevorzugen, bietet Version 3.3 einen neuen Automatisierungspfad mithilfe des Ansible ACME- Moduls. Sie legen den gewünschten Status Ihrer Zertifikate in Ihrer Ansible-Konfiguration fest, und das System kümmert sich um den Bezug und die Erneuerung von TLS-Zertifikaten von jeder ACME-kompatiblen Zertifizierungsstelle, sodass der tatsächliche Bereitstellungsstatus stets mit dem festgelegten übereinstimmt. Dies ist das ideale Vorgehen für Teams, die Ansible bereits in großem Umfang einsetzen.

Treffen Sie Zertifikate, wo immer sie leben

CertSecure 3.3 erweitert das Universum der Zertifizierungsstellen, Tresore und Systeme, die Sie nativ verwalten können.

Google Public CA Integration

Google Public CA ist jetzt eine erstklassige, integrierte Zertifizierungsstelle. Das vollständige Lebenszyklusmanagement (Ausstellung, Verlängerung, Widerruf, Inventarisierung) funktioniert für Google Public CA genauso wie für Ihre anderen Zertifizierungsstellen. Für Organisationen, die GCP- Dienste nutzen oder eine zusätzliche öffentliche Zertifizierungsstelle benötigen, schließt dies eine wichtige Integrationslücke.

ServiceNow-App, jetzt im Store erhältlich

Die CertSecure-App für Zertifikatsverwaltung in ServiceNow ist jetzt im offiziellen ServiceNow Store verfügbar. Das ist eine viel bedeutendere Neuerung, als es zunächst klingt: Die meisten Zertifikatsprozesse in Unternehmen laufen bereits über ITSM-Ticket-Systeme. Dank der Integration können Benutzer Zertifikate direkt in ihrem bestehenden ServiceNow-Workflow anfordern, registrieren, generieren und herunterladen, ohne ein neues Portal erlernen zu müssen. Das Ergebnis: weniger Aufwand, schnellere Bearbeitung und weniger unbearbeitete Tickets, weil jemand nicht wusste, welches Tool er öffnen sollte.

Azure Key Vault: Behörden-Mandanten und Ein-Klick-Upload

Die Unterstützung für Azure Key Vault wurde in zwei wichtigen Richtungen erweitert.

• Regierungsmieter werden nun unterstützt. mit vollständiger rollenbasierter Zugriffskontrolle (RBAC) für Zertifikats-Uploads. Dies ist entscheidend für regulierte Kunden und Kunden des öffentlichen Sektors, die Azure Government nutzen. 
• Hochladen mit einem Klick Ermöglicht das Hochladen von Zertifikaten in Azure Key Vault entweder bei der Registrierung oder für bereits registrierte Zertifikate. Was früher ein mehrstufiger manueller Vorgang war, ist jetzt per Knopfdruck erledigt. 

DigiCert: Benutzerdefinierte Gültigkeitszeiträume

DigiCert-Kunden können jetzt bei der Registrierung eine individuelle Gültigkeitsdauer festlegen. Eine kleine, aber häufig gewünschte Änderung, die besonders relevant ist, da die Branche die Laufzeiten ihrer Zertifikate schrittweise verkürzt. Die Entscheidung, ob die Verlängerung zum Einsatzzeitraum passt, wird dadurch differenzierter.  

Entdeckung ohne manuelle Suche

Was man nicht finden kann, kann man nicht verwalten. CertSecure 3.3 bietet zwei bemerkenswerte Erweiterungen. 

• AWS Cloud Discovery ist jetzt aktiviert. Zertifikate, die in AWS gespeichert sind, einschließlich ACMIAM-Systeme und Load Balancer können automatisch in den CertSecure-Bestand aufgenommen werden, anstatt separat erfasst zu werden. 
• IIS CCS Store Discovery wird nun unterstützt. In Windows-lastigen Umgebungen mit dem zentralen Zertifikatsspeicher von IIS können Zertifikate in CCS-Freigaben jetzt nativ inventarisiert werden. 

Sobald Zertifikate im Inventar erfasst sind, werden Drittanbieterzertifikate in einem eigenen Container unter „Inventar → CertSecure“ angezeigt und können über den Filter „Zertifikatstyp“ gefiltert werden. Sie können dieselben Operationen ausführen wie bei intern verwalteten Zertifikaten: Herunterladen, Zertifikatskette anzeigen, per E-Mail zustellen, Container wechseln. Dies schließt eine der häufig auftretenden Lücken im Zertifikatsmanagement. Konkret wird das Problem gelöst, Zertifikate von externen Zertifizierungsstellen in einer separaten Tabelle zu verwalten. 

Die Berichtsfunktion bietet nun auch einen neuen Vorlagenfilter für Inventar- und Ablaufberichte, mit dem Sie Ihr Inventar nach Zertifikatsvorlage filtern können. Dies ist besonders nützlich in Umgebungen mit vielen Vorlagen für unterschiedliche Zwecke, in denen Sie beispielsweise wissen möchten, welche Webserver-Vorlagenzertifikate in 30 Tagen ablaufen. 

Und falls Sie jemals zehn Minuten damit verbracht haben, in der Dokumentation nach einem bestimmten Abschnitt zu suchen, verfügt die UI-Dokumentation jetzt über eine integrierte Suchfunktion. 

Reibungslosere Einschreibungsmomente

Ein paar kleinere, aber wirklich nützliche Änderungen. 

PFX-Download mit Upload des privaten Schlüssels für die CSR-Registrierung. Bei der Registrierung über CSR können Sie Ihren privaten Schlüssel nun während des Registrierungsprozesses hochladen. CertSecure generiert daraufhin eine herunterladbare PFX-Datei. Für viele Zielplattformen, die PFX-Dateien benötigen, entfällt dadurch ein separater OpenSSL-Schritt auf Ihrem Laptop.

Die Zustellung von DigiCert-Zertifikaten per E-Mail wurde für einen bekannten Sonderfall korrigiert, und einige weitere Fehler im Registrierungsprozess wurden behoben. Auch das Verhalten der Option „Vorlage ignorieren“ wurde korrigiert.

Was kommt als nächstes

Ein kurzer Hinweis darauf, wohin die Reise geht, denn die Arbeit ist mit dieser Veröffentlichung noch nicht getan.

Die kontinuierliche Ausweitung der Automatisierung steht im Vordergrund. Da 100-Tage-Zertifikate ab März 2027 Standard sein werden, werden wir weitere Bereitstellungsziele und komplexere Orchestrierungsmuster hinzufügen. Falls eine Plattform in Ihrem Stack noch nicht automatisiert ist, teilen Sie uns dies bitte mit. Ihr Feedback beeinflusst unsere Roadmap.

Die zweite Voraussetzung ist die Bereitschaft für Post-Quanten-Kryptographie . Das Risikoprofil, die automatische Erneuerung und die Orchestrierungsgrundlage in Version 3.3 ermöglichen eine zukünftige Migration zu Post-Quanten-Kryptographie (PQC) . Wenn sich eine ganze Flotte automatisch erneuern lässt, wird der Algorithmuswechsel zu einer einfachen Konfigurationsänderung und nicht zu einem mehrquartalslangen Projekt. Explizite PQC-Funktionen befinden sich in der Entwicklung, und wir werden in zukünftigen Versionen weitere Informationen bereitstellen, sobald das öffentliche Zertifizierungsstellen-Ökosystem seine PQC-Ausstellungsverfahren standardisiert hat.

Die gleiche Automatisierungsgrundlage erstreckt sich über TLS-Zertifikate hinaus. Unsere CBOM Secure- Plattform nutzt dieselbe Zertifikatserkennung für Ihre gesamte kryptografische Infrastruktur, und unser Leitfaden „CBOM: Vom Inventar zur Intelligenz“ zeigt Ihnen, wie Sie dieses Inventar in ein kontinuierliches Programm umwandeln. Da die Zertifikatsautomatisierung in CertSecure Manager 3.3 CA-unabhängig ist, bietet Ihnen die von Ihnen geschaffene Grundlage für die automatische Erneuerung auch die nötige Flexibilität, um Algorithmen später ohne mehrjähriges Projekt zu wechseln. Unser 9-phasiger PQC-Readiness -Plan und unser PQC Center of Excellence unterstützen Sie bei der Planung dieses Übergangs im Rahmen dieses Upgrades.

Die Erweiterung der Erkennungsfunktionen ist die dritte Neuerung. AWS Cloud Discovery und IIS CCS werden in Version 3.3 in die Liste der Erkennungsfunktionen aufgenommen, aber es müssen noch weitere Cloud- und On-Premise-Zertifikatspeicher unterstützt werden. Wir arbeiten daran.

Wie man aufrüstet

CertSecure Manager v3.3 ist ab sofort verfügbar. Wenn Sie bereits eine aktuelle Version verwenden, ist das Upgrade unkompliziert. Ihr zuständiges Encryption Consulting-Team unterstützt Sie gerne bei umgebungsspezifischen Überlegungen und der optimalen Vorgehensweise für HA-Bereitstellungen. 

Wenn Sie CertSecure Manager noch nicht nutzen , sollten Sie den Zeitpunkt unbedingt überdenken. Die Umstellung von 200-Tage- auf 100-Tage-Zertifikate erfolgt im März 2027, also in weniger als einem Jahr. Unternehmen, die erst 2029 mit der Automatisierung beginnen, wenn 47-Tage-Zertifikate verpflichtend werden, stehen unter Druck. Unternehmen, die jetzt, während der 200- und 100-Tage-Phasen, eine funktionierende Automatisierungsgrundlage schaffen, verfügen 2029 über eine bereits einsatzbereite Infrastruktur.

Wenn eine der oben genannten Funktionen das Gefühl hat, ein Problem zu lösen, mit dem Sie schon länger zu kämpfen haben, wenden Sie sich an das Encryption Consulting Team, um eine Analyse Ihrer Umgebung zu erhalten.

Und wie immer vielen Dank an alle Kunden, die ein Ticket eingereicht, kritische Fragen gestellt oder darauf bestanden haben, dass die bestehende Umgehungslösung nicht akzeptabel ist. Die meisten Neuerungen in Version 3.3 gehen auf Ihr Engagement zurück.

Weiterführende Lektüre von Encryption Consulting

• Automatisierte DNS-Validierung mit CertSecure Manager: Persistente DCV- und DNS-Konnektoren umfasst die Automatisierung der Domainvalidierung im Rahmen desselben 47-tägigen Erneuerungszyklus.
• CBOM: Von der Bestandsaufnahme zur intelligenten Analyse umfasst die Umwandlung kryptografischer Erkennung in ein fortlaufendes Programm, das über Zertifikate hinausgeht.
• PQC Kompetenzzentrum behandelt auch, wie die Migration nach der Quantenmigration zusammen mit dieser Grundlage für die Zertifikatsautomatisierung geplant werden kann.

Häufig gestellte Fragen

Was ist die wichtigste Neuerung von CertSecure Manager 3.3 – und sie kommt genau dann, wenn Sie sie am dringendsten brauchen?

CertSecure Manager 3.3 wurde für die schrittweise Reduzierung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate auf 47 Tage bis 2029 durch das CA/Browser Forum entwickelt. Die Version bietet ein Zertifikatsrisikoprofil, Massensperrung und Eigentumsübertragung, automatische Erneuerung über alle Webserver-Agenten hinweg sowie einen Ansible ACME-Automatisierungspfad, sodass Zertifizierungsteams die Erneuerungsfrequenz etwa achtmal so hoch wie heute gestalten können, ohne manuelle Engpässe.

Warum ist das für das Zertifikatslebenszyklusmanagement in Unternehmen wichtig?

Die Trust Pulse-Umfrage von DigiCert ergab, dass 45 % der Unternehmen im vergangenen Jahr aufgrund von Zertifikatsproblemen Ausfälle verzeichneten und 37.5 % einen Ausfall direkt auf ein abgelaufenes Zertifikat zurückführen konnten. Da sich die Erneuerungshäufigkeit im Rahmen des 47-Tage-Zyklus etwa verachtfacht, erhöht jeder manuelle Schritt in diesem Prozess das Risiko eines solchen Ausfalls – genau das soll die automatische Zertifikatserneuerung verhindern.

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

Die PKI-Teams sind für die Planung des Upgrades und die anschließende Validierung der Zertifikatsrisikoprofile zuständig. Die Sicherheitsteams prüfen Zertifikate mit hohem und hohem Risiko und stellen sicher, dass die Runbooks für Massensperrungen aktuell sind. Die Plattform- und DevOps-Teams implementieren die automatische Zertifikatserneuerung und den Ansible ACME-Automatisierungspfad. Die Compliance-Teams nutzen Risikoprofile und Eigentumsübertragungsdatensätze als revisionssichere Nachweise.

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

Die manuelle Nachverfolgung von Zertifikaten bei etwa 21 Verlängerungen pro Tag – dem Umfang, den ein Bestand von 1,000 Zertifikaten innerhalb eines 47-tägigen Zyklus erreicht – erhöht das Risiko verpasster Verlängerungen und der dadurch verursachten Ausfälle erheblich. Manuelle Prozesse erschweren zudem die Erkennung schwacher Schlüssel, veralteter Algorithmen und langer Gültigkeitsdauern, bevor diese von einem Prüfer oder durch einen Vorfall aufgedeckt werden. Genau diese Schwachstellen soll das Zertifikatsrisikoprofil automatisch aufdecken.

Wie reduziert Automatisierung das Risiko von Zertifikatsausfällen?

Die automatische Zertifikatserneuerung (Zero-Touch Renewal) durchläuft den gesamten Prozess von der Registrierung bei der Zertifizierungsstelle über die Zustellung und Installation bis hin zum Neustart des Dienstes – ohne dass ein manueller Schritt übersehen oder verzögert werden kann. In Kombination mit dem Zertifikatsrisikoprofil werden schwache oder bald ablaufende Zertifikate automatisch gekennzeichnet, anstatt erst bei einem Ausfall eines Dienstes, der dieses Zertifikat bereits verwendet, entdeckt zu werden.

Welche Kennzahlen sollten Teams nach der Implementierung verfolgen?

Verfolgen Sie den Prozentsatz der Zertifikate, die als sicher oder mit niedrigem Risiko im Vergleich zu hohem Risiko oder schwerwiegend eingestuft werden, den Anteil der über Zero-Touch-Automatisierung abgeschlossenen Verlängerungen im Vergleich zu manuellen Eingriffen, die Zeit für den Massenwiderruf und die Neuzuweisung der Inhaberschaft für einen definierten Stapel sowie die Anzahl der ausfallbezogenen Zertifikatstickets pro Quartal im Vergleich zu Ihrem Ausgangswert vor dem Upgrade.

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

Der vom CA/Browser Forum am 11. April 2025 verabschiedete Antrag SC-081v3 sieht eine schrittweise Verlängerung der maximalen Gültigkeitsdauer öffentlicher TLS-Zertifikate vor: von derzeit 398 Tagen auf 200 Tage im März 2026, 100 Tage im März 2027 und 47 Tage bis März 2029. Dies entspricht einer etwa achtfachen Erhöhung der Erneuerungshäufigkeit. Die Funktionen für die automatische Erneuerung, die Massenverarbeitung und die Risikobewertung von CertSecure Manager 3.3 sind speziell darauf ausgelegt, diese Erhöhung ohne zusätzliches Personal zu bewältigen.

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

Wenden Sie dieselbe Risikoprofilbewertung, die automatische Erneuerung und die Erkennung konsistent in allen Zertifizierungsstellen-, Cloud- und On-Premises-Umgebungen an, anstatt eine zu automatisieren und eine andere manuell zu belassen. Die AWS Cloud Discovery, die IIS CCS Store Discovery, die Unterstützung für Azure Key Vault und die native Integration von Google Public CA in CertSecure Manager 3.3 wurden genau dafür entwickelt, diese heterogenen Umgebungen in einem einzigen Inventar zusammenzuführen.

Welche Voraussetzungen müssen vor der Implementierung erfüllt sein?

Sie benötigen eine unterstützte, aktuelle Version von CertSecure Manager, von der Sie das Upgrade durchführen möchten, administrative Zugriffsrechte auf alle verbundenen Zertifizierungsstellen und Tresore, die Sie in die neuen Funktionen einbeziehen möchten, ein geplantes Wartungsfenster mit bestätigter Knotensequenzierung für HA-Bereitstellungen sowie eine getestete Sicherung Ihrer aktuellen Konfiguration und Datenbank, die unmittelbar vor dem Upgrade erstellt wurde.

Welche Screenshots oder Konfigurationsbeispiele sollten enthalten sein?

Die Spalte „Zertifikatrisikoprofil“ in der Inventar- und Zertifikatssuche, die Visualisierung der Vertrauenskette in der Detailansicht eines Zertifikats, der neue Ping-Status auf der Seite „CA-Verwaltung“ und die Ansicht für CPU, Festplatte und RAM auf der Registerkarte „Metriken“ sind die vier UI-Ansichten, für die es sich lohnt, Screenshots für interne Rollout-Anleitungen anzufertigen. Das Ansible-ACME-Automatisierungsbeispiel in dieser Anleitung zeigt, wie der Zertifikatsstatus als Code deklariert wird.