Verbesserung der digitalen Zertifikatsverwaltung mit der Service Now-Integration von CertSecure

Kurz gesagt: Die ServiceNow-Integration von CertSecure Manager wandelt Zertifikatsablaufereignisse automatisch in RBAC-gesteuerte ServiceNow-Incident-Tickets um, und zwar 90, 60, 30 und 7 Tage vor Ablauf sowie zum Zeitpunkt des Ablaufs selbst, mit automatischer Eskalation als Ausweichmöglichkeit. So werden Zertifikatserneuerungen nachverfolgt, verwaltet und geprüft, anstatt darauf angewiesen zu sein, dass jemand eine E-Mail-Benachrichtigung bemerkt.

Ein einziges abgelaufenes Zertifikat kann eine kundenorientierte Anwendung innerhalb von Sekunden lahmlegen, und die meisten Sicherheitsteams erfahren davon durch eine Ausfallwarnung, nicht durch ein Dashboard. Da die Anzahl der Zertifikate pro Unternehmen in die Tausende geht, stoßen Tabellenkalkulationen und manuelle Erinnerungen zur Zertifikatserneuerung lange vor dem nächsten Compliance-Audit an ihre Grenzen.

Die ServiceNow-Integration von CertSecure Manager verknüpft Ereignisse des Zertifikatslebenszyklus direkt mit den Incident- und Ticketing-Workflows von ServiceNow. Wenn ein Zertifikat abläuft (nach 90, 60, 30 oder 7 Tagen) oder bereits abgelaufen ist, erstellt die Integration automatisch einen Incident, weist ihn über die rollenbasierte Zugriffskontrolle der zuständigen Gruppe zu und eskaliert ihn über eine Ausweichkette, falls keine Antwort erfolgt. Das Ergebnis: weniger verpasste Verlängerungen, ein dokumentierter Lösungsverlauf für Auditoren und keine Zertifikatsausfälle mehr, die auf „niemand hat die E-Mail gesehen“ zurückgeführt werden.

Dieser Leitfaden erläutert, warum die manuelle Zertifikatsverfolgung bei großem Umfang scheitert, wie die ServiceNow-Integration aufgebaut ist, den schrittweisen Einrichtungsablauf, die nach der Einführung zu verfolgenden Metriken und wie sich dies in Ihren umfassenderen 47-Tage-TLS-Zertifikatbereitschaftsplan einfügt.

Direkt zu: Zusammenfassung | Wichtigste Erkenntnisse | Kurzcheckliste | Schritt-für-Schritt-Anleitung | Verantwortlichkeits- und Aktionsmatrix | FAQ

Executive Summary

Die manuelle Nachverfolgung von Zertifikatsablaufdaten ist nicht skalierbar, sobald ein Unternehmen Tausende von Zertifikaten verwaltet. Dies verschärft sich noch, da das CA/Browser Forum die maximale Gültigkeitsdauer öffentlicher TLS- Zertifikate bis März 2029 auf 47 Tage verkürzt . Die ServiceNow-Integration von CertSecure Manager schließt diese Lücke, indem sie Ereignisse des Zertifikatslebenszyklus in rollenbasierte ServiceNow-Tickets mit automatischer Eskalation umwandelt, die über rollenbasierte Zugriffskontrolle (RBAC) verwaltet werden. So werden Verlängerungen nachverfolgt und geprüft, anstatt darauf angewiesen zu sein, dass jemand eine E-Mail bemerkt. Dieser Leitfaden beschreibt den Einrichtungsprozess, die zugrundeliegende Architektur, eine Verantwortlichkeits- und Aktionsmatrix für PKI-, Sicherheits-, Plattform- und Compliance-Teams sowie die zu verfolgenden Kennzahlen nach der Inbetriebnahme – alles im Rahmen einer umfassenderen Strategie zur Zertifikatserkennung und Krypto-Agilität.

Wichtige Erkenntnisse

• Die ServiceNow-Integration von CertSecure Manager wandelt Ereignisse im Zusammenhang mit dem Ablauf von Zertifikaten in RBAC-gesteuerte Incident-Tickets um, und zwar 90, 60, 30 und 7 Tage vor dem Ablauf sowie zum Zeitpunkt des Ablaufs.
• Eine integrierte Ausweich-Eskalationskette weist ungelöste Tickets einem benannten Gruppeninhaber zu und schließt so die Lücke zwischen dem Versenden einer Benachrichtigung und der tatsächlichen Erneuerung eines Zertifikats.
• Laut der DigiCert Trust Pulse Survey vom Juli 2025 berichteten 45 % der Unternehmen über Ausfallzeiten im Zusammenhang mit Zertifikaten im vergangenen Jahr, wobei 37.5 % davon speziell auf abgelaufene Zertifikate zurückzuführen waren.
• Die Teams für PKI, Sicherheit, Plattform/ITSM und Compliance sind jeweils für einen bestimmten Teil des Arbeitsablaufs verantwortlich, von der RBAC-Struktur bis hin zu den Prüfnachweisen.
• Da der Zeitplan des CA/B-Forums die maximale Gültigkeitsdauer von TLS-Zertifikaten auf 200 Tage im Jahr 2026, 100 Tage im Jahr 2027 und 47 Tage im Jahr 2029 verkürzt, wird die ticketbasierte Automatisierung notwendig und nicht mehr optional.

Kurzcheckliste: Bevor Sie beginnen

• Eine CertSecure Manager-Instanz wurde mit Administratorzugriff auf die Konnektorkonfiguration bereitgestellt.
• ServiceNow-Instanz mit API-Zugriff und ein Dienstkonto mit Berechtigungen zur Vorfallserstellung
• Definierte RBAC-Gruppen, die Zertifikatsinhabern zugeordnet sind (App-Teams, PKI-Team, Plattform-Team).
• Vereinbarte Alarmintervalle (üblicherweise 90/60/30/7 Tage vor Ablaufdatum, plus nach Ablaufdatum)
• Ein dokumentierter Fallback-/Eskalationsverantwortlicher für ungelöste Tickets
• Netzwerkverbindung zwischen CertSecure Manager und der ServiceNow-Instanz (Firewallregeln, API-Endpunkte auf der Zulassungsliste)

Tabelle der Voraussetzungen für die jeweilige Aktion:

Voraussetzung	Eigentümer	Maßnahmen vor der Integration
CertSecure Manager wurde bereitgestellt und Konnektoren für alle Zertifizierungsstellen konfiguriert.	PKI-Team	Bestätigen Sie, dass die HA-Architektur aktiv ist und das Zertifikatsinventar gefüllt ist.
ServiceNow API-Zugriff	Plattform-/ITSM-Team	Bereitstellung eines Dienstkontos und API-Zugangsdaten, die auf die Erstellung von Vorfällen beschränkt sind
RBAC-Gruppenzuordnung	Sicherheits-/PKI-Team	Zertifikatsinhaber den ServiceNow-Zuordnungsgruppen zuordnen
Alarmintervallrichtlinie	Compliance-Team	Den 90/60/30/7-Tage- und den Nachfrist-Warnplan vereinbaren und dokumentieren.
Eskalations-/Fallback-Verantwortlicher	PKI-Teamleiter	Nennen Sie einen Gruppeninhaber, der nach Ablauf des Ausweichfensters ungelöste Tickets erhält.

Warum die manuelle Zertifikatsverfolgung bei großem Umfang scheitert

Die zunehmende Verbreitung digitaler Zertifikate in Unternehmen ist eine direkte Folge der gestiegenen Komplexität moderner IT-Umgebungen. Server, Computergeräte, APIs und Benutzeridentitäten benötigen Zertifikate, und die Anzahl der in einem typischen Unternehmen ausgestellten Zertifikate geht mittlerweile in die Tausende. Laut der DigiCert Trust Pulse Survey (2. Juli 2025) verzeichneten 45 % der Unternehmen im vergangenen Jahr Serviceausfälle aufgrund von Zertifikatsproblemen, und 37.5 % führten die Ausfälle konkret auf abgelaufene Zertifikate zurück . Dies ist eine der am besten vermeidbaren Ursachen für Ausfallzeiten in der Unternehmens-IT, und sie tritt weiterhin auf, weil die meisten Teams Zertifikate immer noch genauso verwalten wie vor zehn Jahren.

Als Anbieter von Zertifikatsmanagementlösungen beobachten wir drei wiederkehrende Fehlermuster, wenn Unternehmen versuchen, dies manuell zu verwalten.

Herausforderung 1: Den Überblick über das stetig wachsende Zertifikatsportfolio behalten

Digitale Zertifikate werden mittlerweile für alles ausgestellt, von Entwicklertools bis hin zu Endgeräten für Endkunden. Das Ausstellungsvolumen übersteigt mittlerweile die Möglichkeiten von Tabellenkalkulationen oder manuellen Registern. Neben der Ausstellung muss zudem sichergestellt werden, dass jedes Zertifikat gültig und vertrauenswürdig bleibt – für jede Zertifizierungsstelle, jede Umgebung und jeden Verlängerungszyklus. Ohne entsprechende Überwachung führt diese Komplexität zu Ablaufdaten und Ausfällen.

Herausforderung 2: Lücke bei der Vorausschau auf den Ablauf von Zertifikaten

Die meisten Zertifikatsverwaltungssysteme bieten keine Echtzeit- und vorausschauende Anzeige ablaufender Zertifikate. Ohne eine klare, automatisierte Kennzeichnung bevorstehender Abläufe greifen Teams auf manuelle Nachverfolgung und Tabellenkalkulationen zurück, was menschliche Fehler in einem Ausmaß begünstigt, das am wenigsten tolerierbar ist. Nicht mangelnder Einsatz, sondern fehlende Voraussicht führt zu Ausfällen.

Herausforderung 3: Ineffizienz des Warnsystems und fehlende Nachverfolgung des Problemlebenszyklus

Selbst wenn Ablaufwarnungen vorhanden sind, beschränken sie sich oft auf eine Benachrichtigung ohne zugehöriges Ticket, Verantwortlichen oder Lebenszyklusverfolgung. Ein Zertifikat läuft ab, eine Warnung wird ausgelöst, und es gibt keinen Mechanismus, der nachverfolgt, ob das Problem tatsächlich behoben wurde. Schlimmer noch: Es gibt in der Regel keinen Ausweichpfad, wenn der erste Ansprechpartner nicht reagiert. Genau diese Lücke schließt die ServiceNow-Integration von CertSecure Manager.

Was ist CertSecure Manager?

CertSecure Manager ist die Zertifikatslebenszyklusmanagement-Plattform (CLM) von Encryption Consulting, die speziell für die Bewältigung der zentralen Herausforderung der Verwaltung von PKI- Umgebungen in großem Umfang entwickelt wurde. Dank ihrer Hochverfügbarkeitsarchitektur (HA) können Clients alle öffentlichen und privaten Zertifizierungsstellen (CAs) in einer zentralen Benutzeroberfläche integrieren, sodass keine CA – unabhängig davon, ob es sich um eine Multi-Cloud-, Hybrid- oder Public-Private-Umgebung handelt – im Bestand fehlt.

CertSecure Manager unterstützt außerdem Erneuerungsagenten, die sich direkt in Server wie IIS und Tomcat sowie Load Balancer wie F5 integrieren lassen und Zertifikate aktiv halten und vor deren Ablauf automatisch verlängern. Die Zertifikatserkennung findet jedes Zertifikat auf einem Webserver, unabhängig von Partition oder Installationspfad. Unternehmen können ihre eigenen Tools über ACME- oder REST-APIs integrieren, um die Zertifikatsausstellung für interne Anwendungen zu vereinfachen.

Warum ServiceNow nutzen? Die Bedeutung der Integration aufzeigen

Die ServiceNow-Integration unterstützt verbundene Organisationen bei der Konfiguration ihrer ServiceNow-Instanz für die direkte Zusammenarbeit mit CertSecure Manager. Sie basiert auf rollenbasierter Zugriffskontrolle (RBAC) , sodass die Verantwortung für die Zertifikatsverwaltung präzise den richtigen Personen zugeordnet wird. RBAC vereinfacht die Rollenzuweisung und Benutzergruppierung, indem das System Benutzer anhand ihrer Berechtigungen und Zugriffsebenen kategorisiert. Dies gewährleistet eine übersichtliche und nachvollziehbare Zertifikatsverwaltung.

Die Integration bietet vier konkrete Vorteile:

• Automatisiert die Zertifikatsverfolgung mit Echtzeit-Aktualisierungen und minimalem manuellem Eingriff
• Erstellt automatische Benachrichtigungen und Tickets frühzeitig (7, 30, 60, 90 Tage) und sofort nach Ablauf der Gültigkeitsdauer.
• Führt einen Ausweichalgorithmus zur Eskalation aus, wenn keine Lösung rechtzeitig empfangen wird.
• Verhindert menschliche Fehler und Serviceausfälle im Zusammenhang mit dem Ablauf von Zertifikaten

ServiceNow löst zudem das anhaltende Problem der Zertifikatsverfolgung. Läuft ein Zertifikat ab, wird ein Ticket erstellt, der zuständigen Gruppe zugewiesen und anschließend zur Bearbeitung an den Aussteller weitergeleitet. Dadurch bleibt der gesamte Prozess der Zertifikatserneuerung in einem einzigen, nachvollziehbaren System abgewickelt.

Wie die ServiceNow-Integration jede Herausforderung löst

Verfolgung des ständig wachsenden Portfolios

ServiceNow automatisiert und optimiert den Zertifikatslebenszyklus mithilfe der zentralen Zertifikatsdatenbank von CertSecure Manager. Es fungiert als dynamischer Orchestrator und automatisiert Routineaufgaben wie die Gültigkeitsüberwachung und die rechtzeitige Erneuerung von Zertifikaten. Diese präzise Automatisierung reduziert manuelle Eingriffe und damit das Risiko von Fehlern.

Schließung der Lücke in der Voraussicht bezüglich des Ablaufs von Zertifikaten

Die Integration schließt die Planungslücke durch automatisierte Nachverfolgung, Benachrichtigung und Ausweichmechanismen für jedes Zertifikat. RBAC stellt sicher, dass Verantwortlichkeiten und Rollen präzise den richtigen Benutzergruppen zugewiesen werden, und die ServiceNow-Automatisierung sendet Benachrichtigungen an die entsprechenden Gruppen und damit an die jeweiligen Benutzer, lange bevor ein Zertifikat abläuft.

Behebung von Ineffizienzen bei der Alarmierung und der Nachverfolgung des Problemlebenszyklus

ServiceNow optimiert die Benachrichtigungen, indem für jedes Ablaufproblem ein Incident erstellt wird. Die Integration generiert Tickets automatisch – rechtzeitig im Voraus in Intervallen von 7, 30, 60 und 90 Tagen sowie unmittelbar nach Ablauf der Gültigkeit. So wird jedes Ereignis protokolliert und nachverfolgt. Ein integrierter Ausweichalgorithmus weist das Ticket neu zu, falls keine rechtzeitige Antwort auf die vorgeschlagene Lösung eingeht. Dadurch ist der Prozess zuverlässig und nicht davon abhängig, dass eine einzelne Person eine E-Mail bemerkt.

Detaillierte Architektur der Integration

Die Integrationsarchitektur ist in drei Schichten gegliedert: die Administrationsschicht , die Schicht der Vorfallgruppen und die Schicht der Vorfalltickets . Die Administrationsschicht bildet die oberste Ebene und überwacht alle administrativen Gruppen sowie die darunterliegende Schicht. Die Zugriffskontrolle wird von der allgemeinen Ebene der Administrationsschicht auf die spezifische Ebene der Vorfalltickets verlagert.

Die Admin-Ebene steuert die allgemeine Gruppenverwaltung. Die Incident-Gruppenebene kümmert sich um gruppenspezifische Aktivitäten und die Teams, die für die Behebung von Zertifikatsproblemen zuständig sind. Das Incident-Ticket enthält alle Details zum Ablauf eines Zertifikats und sorgt so für einen strukturierten und organisierten Lösungsprozess.

Diese Struktur ist so konzipiert, dass sie sich nahtlos in die Arbeitsabläufe Ihres Unternehmens einfügt. Bestehende administrative Richtlinien lassen sich problemlos den einzelnen Ebenen zuordnen, sodass die Integration Ihre bestehenden Prozesse unterstützt, anstatt sie zu ersetzen.

So funktioniert die Ticketzuweisung für ein ablaufendes Zertifikat: Sobald ein Ticket erstellt wird, wird es der ausstellenden Gruppe zugewiesen, die für das Zertifikat zuständig ist. Diese Gruppe ist für das Ticket und die Verlängerung verantwortlich. Tickets werden rechtzeitig vor Ablauf des Zertifikats erstellt, und zwar 7, 30, 60 und 90 Tage vorher sowie erneut unmittelbar nach Ablauf, falls das Problem nicht rechtzeitig gelöst wurde.

Die Ticket-Lebenszyklusrichtlinie ist einfach: Das Ticket wird zunächst dem Zertifikatsaussteller oder einer benannten Stelle zugewiesen. Sobald das Zertifikat erneuert und das Problem behoben ist, wird das Ticket geschlossen. Bleibt es nach einer festgelegten Frist ungelöst, wird es automatisch dem Gruppeninhaber zugewiesen, der es dann an die zuständige Person weiterleitet. Dieser strukturierte und reaktionsschnelle Workflow verhindert, dass Zertifikatserneuerungsfälle stillschweigend mit dem Zertifikat selbst verfallen.

Schritt für Schritt: Einrichten der CertSecure Manager- und ServiceNow-Integration

Die folgende Konfiguration setzt voraus, dass CertSecure Manager bereits installiert und Ihr Zertifikatsbestand gefüllt ist. Die unten aufgeführten Screenshots sollten Ihre aktuelle Version der CertSecure Manager-Administrationskonsole und Ihrer ServiceNow-Instanz zum Zeitpunkt der Konfiguration widerspiegeln.

1. ServiceNow-Dienstkonto bereitstellen: Erstellen Sie in ServiceNow einen dedizierten Integrationsbenutzer mit API-Zugriff, der auf die Erstellung von Incidents und die Zuweisung von Gruppen (Lesen/Schreiben) beschränkt ist. Vermeiden Sie die Wiederverwendung eines persönlichen Administratorkontos; mit diesem Konto authentifiziert sich CertSecure Manager. Screenshot: ServiceNow-Benutzererstellungsbildschirm mit zugewiesener Rolle „Nur Webdienstzugriff“.
2. RBAC-Gruppen zuordnen: Definieren Sie in der Administrationskonsole von CertSecure Manager die Admin-Ebene und erstellen Sie anschließend Vorfallsgruppen, die Ihre bestehende Zertifikatsinhaberstruktur widerspiegeln (Anwendungsteams, PKI-Team, Plattformteam). Screenshot: CertSecure Manager RBAC-Konfigurationspanel mit Darstellung der Gruppenhierarchie.
3. Konfigurieren Sie den ServiceNow-Connector: Geben Sie in den Integrationseinstellungen von CertSecure Manager die ServiceNow-Instanz-URL, die Anmeldeinformationen des Dienstkontos und die Zieltabelle (in der Regel die Incident-Tabelle) ein. Screenshot: Seite mit den Integrationseinstellungen von CertSecure Manager, auf der die ServiceNow-Felder ausgefüllt sind.
4. Alarmintervalle festlegen: Definieren Sie den Benachrichtigungsplan vor Ablauf der Frist (üblicherweise 90, 60, 30 und 7 Tage) sowie eine Benachrichtigung nach Ablauf der Frist. Jedes Intervall sollte einer Ticketprioritätsstufe in ServiceNow zugeordnet sein. Screenshot: Konfigurationsbildschirm für das Alarmintervall.
5. Konfigurieren Sie die Fallback-/Eskalationskette: Legen Sie das Zeitfenster fest, nach dem ein ungelöstes Ticket dem Gruppeninhaber neu zugewiesen wird, und benennen Sie diesen Inhaber explizit. Screenshot: Eskalationsregelgenerator mit Anzeige des Zuweisungsfensters und des Zielverantwortlichen.
6. Führen Sie ein Testzertifikat durch die Pipeline: Verwenden Sie in einer Nicht-Produktionsumgebung ein Zertifikat mit einem baldigen Ablaufdatum, um sicherzustellen, dass ein Ticket von Anfang bis Ende korrekt erstellt, zugewiesen und eskaliert wird.
7. Ticketdaten anhand des Zertifikatsdatensatzes validieren: Stellen Sie sicher, dass das Ticket den CN/SAN des Zertifikats, die ausstellende Zertifizierungsstelle, das Ablaufdatum und die zugehörige Anwendung enthält, damit die Bearbeiter diese Informationen nicht separat nachschlagen müssen.
8. Schalten Sie live und überwachen Sie den ersten vollständigen Alarmzyklus: Bevor Sie sich vollständig darauf verlassen, sollten Sie die ersten 90-Tage- und 30-Tage-Alert-Batches genau beobachten, um sicherzustellen, dass sich die Zuweisungsgruppen und die Eskalationszeiten wie konfiguriert verhalten.

Beispielkonfiguration (die Werte variieren je nach ServiceNow-Instanz):

Integration endpoint: https://<instance>.service-now.com/api/now/table/incident
Auth type: OAuth 2.0 (service account)
Alert intervals (days before expiry): 90, 60, 30, 7
Post-expiry alert: immediate
Fallback escalation window: 48 hours
Escalation target: PKI team lead (group owner)

Vorher und Nachher: ​​Vergleich der Arbeitsabläufe

Schritt	Vor der Integration (Manuell)	Nach der Integration (automatisiert)
Ablaufverfolgung	Tabellen- oder Kalendererinnerungen, die regelmäßig überprüft werden	Kontinuierliche, automatisierte Überwachung innerhalb von CertSecure Manager
Alarmieren	E-Mail an eine Verteilerliste, keine Eigentumsgarantie	Das Ticket wurde automatisch erstellt und über RBAC der richtigen Eigentümergruppe zugewiesen.
Eskalation	Keine; es hängt davon ab, dass jemand die E-Mail bemerkt.	Automatische Fallback-Neuzuweisung nach einem definierten Zeitfenster
Audit-Trail	Verstreut in E-Mail-Verläufen und Tabellenkalkulationen	Lebenszyklusdatensatz eines einzelnen Tickets in ServiceNow
Auflösungssichtbarkeit	Unbekannt bis zum Auftreten eines Ausfalls	Von der Ticketerstellung bis zum Abschluss verfolgt

Rollback-Anleitung und häufige Fehler

Falls die Integration rückgängig gemacht werden muss, deaktivieren Sie zunächst den ServiceNow-Connector in den Integrationseinstellungen des CertSecure Managers. Dadurch wird die Erstellung neuer Tickets verhindert, ohne bestehende Tickets zu löschen. Behalten Sie die RBAC-Gruppenzuordnungen bei, damit beim späteren Reaktivieren der Integration die Besitzverhältnisse nicht von Grund auf neu konfiguriert werden müssen. Entziehen Sie das API-Token des ServiceNow-Dienstkontos zuletzt, nachdem Sie sichergestellt haben, dass keine laufenden Tickets für Aktualisierungen davon abhängen.

Häufige Fehler bei der Einrichtung:

• Tickets erstellt, aber noch nicht zugewiesen: bedeutet in der Regel, dass die RBAC-Gruppenzuordnung vor der Aktivierung des Konnektors nicht abgeschlossen wurde.
• Es wurden überhaupt keine Tickets generiert: Prüfen Sie, ob das API-Token des Dienstkontos noch gültig ist und ob die ServiceNow-Instanz-URL korrekt ist.
• Doppelte Tickets für dasselbe Zertifikat: typischerweise verursacht durch sich überschneidende Alarmintervallregeln; überprüfen Sie, ob jedes Intervall einem eindeutigen Ticketstatus zugeordnet ist.
• Eine Eskalation wird nie ausgelöst: Prüfen Sie, ob sowohl das Fallback-Fenster als auch das Eskalationsziel festgelegt sind; ein fehlendes Ziel deaktiviert die Eskalation in einigen ServiceNow-Konfigurationen stillschweigend.

Erfolgskennzahlen, die nach der Implementierung verfolgt werden sollten

Verfolgen Sie diese Kennzahlen mindestens ein volles Quartal nach der Inbetriebnahme, um zu bestätigen, dass die Integration die beabsichtigte Reduzierung des manuellen Aufwands und des Ausfallrisikos bewirkt:

• Anzahl der erstellten vs. innerhalb der Service-Level-Vereinbarung gelösten Tickets im Zusammenhang mit Zertifikatsvorfällen
• Prozentsatz der Tickets, die vor dem Auslösen des Eskalations-/Fallback-Fensters gelöst wurden
• Reduzierung der manuell erfassten Zertifikate (Tabelleneinträge wurden abgeschafft)
• Anzahl der ausfallbedingten Zertifikatsausfälle im Quartalsvergleich mit dem Basiswert vor der Integration
• Durchschnittliche Zeit von der Alarmierung bis zur Ticketlösung, nach Alarmierungsintervall (90/60/30/7 Tage)

Organisationen, die die vollständige Automatisierungssuite von CertSecure Manager inklusive der Erneuerungsagenten und der ServiceNow-Integration nutzen, berichten üblicherweise von kürzeren Erneuerungszeiten und einem messbaren Rückgang manuell erstellter Zertifikatstickets innerhalb der ersten beiden Quartale nach der Einführung. Wenn Sie Ihre eigenen Zahlen erfassen, protokollieren Sie diese quartalsweise, um den Trend bei Ihrer nächsten Compliance- oder Auditprüfung aufzeigen zu können.

Wie dies mit der 47-tägigen TLS-Zertifikatsbereitschaft zusammenhängt

Die Notwendigkeit einer automatisierten Zertifikatsüberwachung wird mit jedem Jahr, in dem der Gültigkeitsreduzierungsplan des CA/Browser-Forums voranschreitet, deutlicher. Laut Sectigos Ankündigung vom 11. April 2025 wird die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate gemäß dem vom CA/B-Forum genehmigten Abstimmungsplan schrittweise von 398 Tagen auf 200 Tage ab dem 15. März 2026, auf 100 Tage ab dem 15. März 2027 und schließlich auf 47 Tage ab dem 15. März 2029 reduziert . Jeder dieser Schritte verkürzt das Erneuerungsfenster und erhöht die Häufigkeit der Überprüfung Ihrer Zertifikate.

Ein manueller oder halbautomatisierter Nachverfolgungsprozess, der bei einer Gültigkeitsdauer von 398 Tagen lediglich umständlich war, wird bei 47 Tagen unpraktikabel, da mittelständische Unternehmen ihre Zertifikate dann nahezu kontinuierlich erneuern müssen. Die ticketbasierte Lebenszyklusverfolgung, die Alarmintervalle und die Eskalationsfunktion der ServiceNow-Integration bieten genau die Automatisierungsebene, die für die 47-tägige Zertifikatsbereitschaft erforderlich ist: Sie wandelt die Aussage „Jemand sollte das bald erneuern“ in ein nachverfolgbares, zugeordnetes und revisionssicheres Ticket um.

Umgang damit in Multi-Cloud- oder hybriden PKI-Umgebungen

In Multi-Cloud- oder Hybrid-PKI-Umgebungen vervielfacht sich die Herausforderung der Zertifikatsverwaltung bei Cloud-Anbieter-CAs, lokalen CAs und öffentlichen Drittanbieter-CAs. Die HA-Architektur von CertSecure Manager integriert all diese CAs in ein einziges Inventar, unabhängig von ihrem Standort. Daher benötigt die ServiceNow-Integration keine separate Konfiguration pro Cloud oder CA-Typ. RBAC-Gruppen werden anhand der Anwendungs- oder Teamzugehörigkeit definiert, nicht anhand der ausstellenden CA. So wird ein Ticket an den richtigen Verantwortlichen weitergeleitet, unabhängig davon, ob das Zertifikat von einer internen Microsoft-CA, einer öffentlichen CA oder einer Cloud-nativen CA stammt.

Teams, die Hybridumgebungen betreiben, sollten diese Integration auch in ihren umfassenderen CBOM Secure- Erkennungsprozess einbinden. Eine kryptografische Stückliste liefert Ihnen das vollständige Zertifikats- und kryptografische Asset-Inventar für Cloud- und On-Premise-Umgebungen. Die ServiceNow-Integration wandelt die Lebenszyklusereignisse dieses Inventars in zugeordnete und nachverfolgbare Tickets um. Damit werden beide Hälften des Problems gelöst: die Kenntnis des vorhandenen Inventars und die Sicherstellung, dass rechtzeitig Maßnahmen ergriffen werden, bevor die Zertifikate ablaufen.

Eigentümer- und Aktionsmatrix des Teams

Team	Verantwortung	Maßnahmen nach der Einführung
PKI-Team	Verantwortlich für CA-Integrationen, RBAC-Gruppenstruktur und Eskalationsrichtlinie	Überprüfen Sie vierteljährlich die Alarmintervalle und die Ausweichzeitpunkte.
Sicherheits Team	Verantwortlich für die Gesamtrisikobewertung des Zertifikats und die Vermeidung von Produktionsausfällen	Ausfall- und Störungsbehebungsmetriken mit dem Basiswert vergleichen
Plattform-/ITSM-Team	Verantwortlich für die ServiceNow-Instanz und den Integritätszustand der API-Integration	Überwachung der Verbindungsverfügbarkeit und Rotation der Anmeldeinformationen des Dienstkontos
Compliance-Team	Besitzt Prüfnachweise für die Verwaltung des Zertifikatslebenszyklus	Tickethistorie als Nachweis für DORA, PCI DSS oder interne Audits abrufen.

Was macht man als nächstes

Wenn Sie diese Integration evaluieren, sieht der schnellste Weg folgendermaßen aus:

1. PKI- und Sicherheitsteams: Vergewissern Sie sich, dass Ihr Zertifikatsbestand vollständig ist, bevor Sie Warnmeldungen konfigurieren; ein unvollständiger Bestand erzeugt falsche Sicherheit und führt nicht zu weniger Ausfällen.
2. Plattformteams: Stellen Sie das ServiceNow-Dienstkonto zunächst in einer Nicht-Produktionsumgebung bereit und überprüfen Sie die API-Konnektivität.
3. Compliance-Teams: Vor der Inbetriebnahme muss festgelegt werden, welche Alarmintervalle und Eskalationsprotokolle als Prüfnachweise aufbewahrt werden müssen.
4. Alle Teams: Die RBAC-Gruppenstruktur sollte gemeinsam festgelegt werden, da eine fehlerhafte Zuordnung der Zuständigkeiten die häufigste Ursache für nicht zugewiesene Tickets nach der Einführung ist.

Fazit

Die Integration von CertSecure Manager in ServiceNow wandelt die Zertifikatsüberwachung und -verwaltung von einem reaktiven, manuellen Prozess in einen strukturierten, nachvollziehbaren Ablauf um. Die dreistufige Architektur, von der Administratorsteuerung bis hin zum einzelnen Incident-Ticket, sorgt dafür, dass der Workflow mit den bestehenden Zuständigkeitsstrukturen Ihres Unternehmens übereinstimmt. Gleichzeitig schließen automatisierte Benachrichtigungen und Eskalationsmechanismen die Schwachstellen, die überhaupt erst zu zertifikatsbedingten Ausfällen führen.

Da sich die Gültigkeitsdauer von Zertifikaten gemäß dem Zeitplan des CA/B-Forums auf 47 Tage verkürzt, ist diese Art der Automatisierung nicht länger nur ein nettes Extra, sondern die einzig realistische Möglichkeit, ein wachsendes Zertifikatsportfolio zu verwalten. In Kombination mit den Erkennungs- und Inventarisierungsfunktionen von CBOM Secure und einer umfassenderen PQC-Readiness -Strategie bietet die ServiceNow-Integration PKI-, Sicherheits-, Plattform- und Compliance-Teams eine zentrale, gemeinsame Datenquelle für alle Ereignisse im Zertifikatslebenszyklus.

CertSecure Manager bietet umfassende Funktionen für das Lebenszyklusmanagement von Zertifikaten – von der Erkennung und Inventarisierung über die Ausstellung, Bereitstellung, Verlängerung und den Widerruf bis hin zum Reporting – unterstützt durch intelligente Benachrichtigungen, Automatisierung und automatische Serverbereitstellung. Entdecken Sie im PQC Center of Excellence , wie die Zertifikatsautomatisierung in Ihre umfassende Strategie für Krypto-Agilität passt.

Was ist der wichtigste Vorteil der Verbesserung des digitalen Zertifikatsmanagements durch die ServiceNow-Integration von CertSecure? Die ServiceNow-Integration von CertSecure Manager wandelt Ablaufereignisse von Zertifikaten automatisch in zugeordnete, nachverfolgbare Incident-Tickets um, indem sie rollenbasierte Zuweisung und Eskalationsmechanismen nutzt und so die Lücke zwischen dem Versand einer Benachrichtigung und der tatsächlichen Erneuerung des Zertifikats schließt.

Warum ist das für das Zertifikatslebenszyklusmanagement in Unternehmen wichtig? Unternehmen verwalten heute Tausende von Zertifikaten über mehrere Zertifizierungsstellen und Cloud-Umgebungen hinweg. Ohne automatisierte, ticketbasierte Nachverfolgung werden Ablaufdaten übersehen, bis es zu Ausfällen kommt. Zudem gibt es keinen Prüfpfad, der die Verantwortlichkeit oder die Lösung des Problems dokumentiert.

Welche Teams sind für die Umsetzung dieser Richtlinien verantwortlich? PKI-Teams sind für die RBAC-Struktur und die CA-Integrationen zuständig, Sicherheitsteams für die Kennzahlen zur Ausfallvermeidung, Plattform-/ITSM-Teams für den ServiceNow-Connector und die API-Integrität, und Compliance-Teams verwenden die resultierende Tickethistorie als Prüfungsnachweis.

Welche Risiken steigen, wenn dieses Thema manuell behandelt wird? Die manuelle Nachverfolgung erhöht das Risiko verpasster Verlängerungen, undokumentierter Lösungswege und Ausfälle; laut der DigiCert Trust Pulse Survey vom Juli 2025 berichteten 45 % der Unternehmen im vergangenen Jahr über ausfallbedingte Probleme mit Zertifikaten, wobei 37.5 % dieser Ausfallzeiten speziell auf abgelaufene Zertifikate zurückzuführen waren.

Wie reduziert Automatisierung das Risiko von Zertifikatsausfällen? Die Automatisierung ersetzt die manuelle Tabellenkalkulationsverfolgung durch kontinuierliche Überwachung, generiert automatisch Tickets in definierten Intervallen (7, 30, 60, 90 Tage und bei Ablauf), weist sie über RBAC dem richtigen Verantwortlichen zu und eskaliert sie automatisch, wenn niemand rechtzeitig reagiert.

Welche Kennzahlen sollten Teams nach der Implementierung verfolgen? Verfolgen Sie das Ticketvolumen im Verhältnis zur SLA-Lösungsrate, den Prozentsatz der Tickets, die vor dem Auslösen einer Eskalation gelöst wurden, die Reduzierung der manuell verfolgten Zertifikate, die Anzahl der Ausfälle im Vergleich zum Vorquartal und die durchschnittliche Zeit von der Alarmierung bis zur Lösung nach Alarmierungsintervall.

Wie hängt das mit der 47-tägigen Gültigkeitsdauer von TLS-Zertifikaten zusammen? Der vom CA/B-Forum genehmigte Zeitplan verkürzt die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate von 398 Tagen auf 200 Tage im März 2026, 100 Tage im März 2027 und 47 Tage im März 2029. Die ticketbasierte Automatisierung ermöglicht die operative Umsetzung der Verlängerungen in dieser Frequenz.

Wie sollte dies in Multi-Cloud- oder hybriden PKI-Umgebungen gehandhabt werden? Definieren Sie RBAC-Gruppen anhand der Anwendungs- oder Teamzugehörigkeit anstatt anhand der ausstellenden Zertifizierungsstelle, da die HA-Architektur von CertSecure Manager öffentliche, private, Cloud- und lokale Zertifizierungsstellen bereits in einem Inventar zusammenführt. Die Kombination mit der Erkennungsfunktion von CBOM Secure erweitert die Nachverfolgung auf die gesamte hybride Umgebung.

Welche Voraussetzungen müssen vor der Implementierung erfüllt sein? Sie benötigen eine bereitgestellte CertSecure Manager-Instanz mit einem gefüllten Zertifikatsinventar, ein ServiceNow-Dienstkonto mit Zugriff auf die Incident-Erstellungs-API, definierte RBAC-Gruppen, die Zertifikatsinhabern zugeordnet sind, eine vereinbarte Alarmintervallrichtlinie und einen benannten Eskalations-/Fallback-Verantwortlichen.

Welche Screenshots oder Konfigurationsbeispiele sollten enthalten sein? Dokumentieren Sie den Bildschirm zur Erstellung des ServiceNow-Dienstkontos, das RBAC-Konfigurationsfeld von CertSecure Manager, die Seite mit den Integrationseinstellungen, auf der die ServiceNow-Felder ausgefüllt sind, den Bildschirm zur Konfiguration des Alarmintervalls und den Eskalationsregelgenerator. Die Aufnahmen sollten von Ihren aktuellen CertSecure Manager- und ServiceNow-Versionen zum Zeitpunkt der Einrichtung stammen.