Certificate Lifecycle Management Best Practices: 7 Strategien für mehr Sicherheit und Kontrolle

Öffentliche TLS-Zertifikate gelten seit März 2026 höchstens 200 Tage, ab März 2027 nur noch 100. Ob Unternehmen mithalten, hängt weniger vom Werkzeug ab als davon, wie sie Certificate Lifecycle Management aufsetzen.

Bei einer Laufzeit von 100 Tagen steht für jedes Zertifikat drei- bis viermal im Jahr eine Erneuerung an, und die Laufzeit von SSL-Zertifikaten wird auch danach weiter sinken. Gleichzeitig liegen Zertifikate längst nicht mehr nur auf Webservern, sondern in Cloud-Diensten, Containern, Geräten und internen Anwendungen, für die unterschiedliche Teams zuständig sind. Einzelne Maßnahmen wie eine bessere Tabelle oder ein zusätzlicher Erinnerungsdienst reichen dafür nicht mehr aus.

Was Certificate Lifecycle Management grundsätzlich leistet, ist schnell gesagt: Es steuert digitale Zertifikate von der Beantragung bis zur Erneuerung oder zum Widerruf. Die eigentliche Arbeit liegt in der Frage, wie sich diese Steuerung im Unternehmen verankern lässt, organisatorisch ebenso wie technisch. Sieben Bereiche entscheiden darüber, ob sie im Alltag trägt.

Sieben Best Practices für Certificate Lifecycle Management

Die folgenden Certificate Lifecycle Management Best Practices, kurz CLM Best Practices, sind nach demselben Muster aufgebaut: Zuerst steht das typische Problem, dann die Empfehlung und schließlich die Konsequenz für den Alltag. Die Reihenfolge folgt der Einführung im Unternehmen und nicht der Wichtigkeit, denn jeder Schritt baut auf dem vorherigen auf. Ohne vollständigen Bestand lässt sich nichts steuern, und ohne klare Regeln lässt sich nichts sinnvoll automatisieren.

1. Den Bestand kontinuierlich erfassen

Das Problem: Zertifikate entstehen häufig außerhalb zentraler Prozesse. Entwicklerteams richten sie für Testumgebungen ein, Cloud-Dienste stellen sie automatisch aus, Dienstleister bringen eigene mit. Ein Teil davon ist der IT nicht bekannt und fällt erst auf, wenn er abläuft.

Die Best Practice: Zertifikate werden regelmäßig und automatisiert erfasst und in einem zentralen Inventar zusammengeführt. Quellen dafür sind Netzwerkscans, die Konten bei den Zertifizierungsstellen, Cloud-Plattformen und Zertifikatsspeicher. Für öffentlich vertrauenswürdige Zertifikate zeigen zudem die Certificate-Transparency-Logs, welche Zertifikate für die eigenen Domains ausgestellt wurden. Im Inventar stehen zu jedem Zertifikat mindestens Fundort, Aussteller, Ablaufdatum, Schlüsseltyp und der zuständige Verantwortliche.

In der Praxis: Discovery ist keine einmalige Aufgabe zu Beginn eines Projekts, sondern ein dauerhafter Prozess mit festem Rhythmus. Jeder Lauf zeigt, welche Zertifikate neu hinzugekommen sind und wer sie verantwortet. Dabei gehören nicht nur Serverzertifikate in den Blick, sondern auch Maschinenidentitäten von Diensten, Geräten und Anwendungen. Ein guter Einstieg ist der Abgleich der Zertifikate in den Konten bei den Zertifizierungsstellen mit den Ergebnissen eines Netzwerkscans: Die Differenz zeigt, wo Zertifikate außerhalb der bekannten Wege entstanden sind.

2. Zentral steuern, dezentral ausstellen

Das Problem: In vielen Unternehmen gibt es nur zwei Zustände. Entweder läuft jede Anfrage über die zentrale IT und wird dort zum Engpass, oder die Fachbereiche beschaffen ihre Zertifikate selbst, jeweils bei einem anderen Anbieter und nach eigenen Regeln.

Die Best Practice: Eine zentrale Stelle legt fest, welche Zertifizierungsstellen und Zertifikatstypen zulässig sind und wer was beantragen darf. Die Ausstellung selbst erfolgt dezentral, also dort, wo das Zertifikat gebraucht wird, aber innerhalb dieser Regeln. So bleibt die Steuerung zentral, ohne die Teams auszubremsen.

In der Praxis: Für jedes Zertifikat gibt es einen benannten Verantwortlichen und eine Vertretung. Diese Zuständigkeit endet nicht mit der Ausstellung, sondern umfasst Erneuerung und Widerruf. Sie steht im Inventar und wird bei Personalwechseln aktiv übertragen, damit kein Zertifikat ohne Verantwortlichen zurückbleibt.

3. Verbindliche Standards festlegen

Das Problem: Ohne Vorgaben entscheidet jede Abteilung selbst über Zertifizierungsstelle, Schlüssellänge und Speicherort der privaten Schlüssel. Spätestens bei einem Audit zeigt sich dann ein uneinheitliches Bild, das sich nur mühsam erklären lässt.

Die Best Practice: Eine schriftliche Zertifikatsrichtlinie legt die zugelassenen Zertifizierungsstellen fest, außerdem Zertifikatstypen je Einsatzzweck, Algorithmen und Schlüssellängen, maximale Laufzeiten, Regeln für die Speicherung privater Schlüssel sowie einheitliche Benennungen. Für besonders schützenswerte Schlüssel kann die Richtlinie zum Beispiel die Speicherung in einem Hardware-Sicherheitsmodul vorschreiben.

In der Praxis: Standards sollten so formuliert sein, dass sie sich ändern lassen. Das betrifft vor allem die Algorithmen: Mit der Post-Quanten-Kryptographie kommen neue Verfahren hinzu, die sich ohne Neuaufbau einführen lassen müssen. Diese Fähigkeit wird als Krypto-Agilität bezeichnet. Die Richtlinie wird deshalb regelmäßig überprüft und nicht erst dann, wenn eine Branchenvorgabe wie die nächste Laufzeitverkürzung bereits gilt. Sie sollte außerdem festlegen, was mit Zertifikaten geschieht, die ihr nicht entsprechen: ob sie bis zur nächsten Erneuerung geduldet oder sofort ersetzt werden.

4. Genehmigungen nach Risiko staffeln

Das Problem: Wird jede Anfrage einzeln freigegeben, dauern Routinefälle unnötig lange. Wird dagegen keine Anfrage geprüft, entstehen auch Zertifikate mit hohem Risiko ohne Kontrolle, etwa Wildcard-Zertifikate, die für beliebig viele Subdomains einer Ebene gelten.

Die Best Practice: Approval Workflows werden nach Zertifikatstyp und Risiko gestaffelt. Standardzertifikate, die der Richtlinie entsprechen, werden ohne manuelle Freigabe ausgestellt. Sonderfälle wie Wildcard-Zertifikate oder Zertifikate, die die Identität des Unternehmens bestätigen, durchlaufen eine Freigabe durch eine zweite Person. Ein Zertifikat für einen internen Testserver wird so ohne Wartezeit ausgestellt, ein Wildcard-Zertifikat für die Hauptdomain dagegen erst nach Prüfung.

In der Praxis: Die Freigaberegeln sind dokumentiert, und jede Freigabe wird protokolliert. Dadurch entsteht nebenbei ein Nachweis für Audits. Lohnend ist auch ein Blick darauf, wie lange Freigaben im Durchschnitt dauern, denn lange Wartezeiten sind ein häufiger Grund dafür, dass Teams den Prozess umgehen.

5. Self-Service ermöglichen, ohne Kontrolle abzugeben

Das Problem: Wenn der offizielle Weg zu einem Zertifikat umständlich ist, suchen sich Teams einen anderen. So entstehen Zertifikate, die in keinem Inventar auftauchen und für die niemand zuständig ist.

Die Best Practice: Über delegierte Administration erhalten Teams eigene Rechte für einen klar umrissenen Bereich, zum Beispiel für bestimmte Domains oder Zertifikatstypen. Innerhalb dieses Bereichs beantragen, erneuern und widerrufen sie Zertifikate selbst, während die Richtlinien automatisch greifen.

In der Praxis: Ein Self-Service-Portal oder eine Schnittstelle ersetzt das Ticket an die zentrale IT. Die zentrale Stelle behält dennoch den Überblick, weil jedes so ausgestellte Zertifikat im Inventar landet. Ein typisches Beispiel ist ein Entwicklungsteam, das für seine Testumgebungen selbst Zertifikate ausstellen darf, allerdings nur unterhalb einer festgelegten Subdomain und nur mit den zugelassenen Zertifikatstypen. Die vergebenen Rechte werden regelmäßig überprüft und bei Rollenwechseln angepasst.

6. Wiederkehrende Aufgaben automatisieren

Das Problem: Bei 100 Tagen Laufzeit wird die manuelle Erneuerung zum Dauerbetrieb. Jeder Handgriff vom Antrag bis zur Installation ist eine mögliche Fehlerquelle, und mit der Zahl der Zertifikate steigt der Aufwand linear.

Die Best Practice: Ausstellung, Erneuerung und Installation laufen automatisiert, über standardisierte Protokolle wie das ACME-Protokoll oder über die Schnittstellen von Zertifizierungsstellen und Plattformen. Welcher Weg passt, hängt von der Umgebung ab: Die Umstellung auf ACME, eine PKI as a Service und eine zentrale Plattform sind die drei gängigen Ansätze der Zertifikatsautomatisierung.

In der Praxis: Am meisten bringt die Automatisierung bei Systemen, die häufig erneuert werden und standardisiert sind, etwa bei Webservern und Load Balancern. Zur Automatisierung gehört auch die Verteilung auf die Zielsysteme, denn ein automatisch erneuertes Zertifikat nützt wenig, wenn es anschließend von Hand auf mehreren Servern eingespielt werden muss. Systeme, die sich nicht automatisieren lassen, werden als Ausnahme dokumentiert und besonders eng überwacht. Nach jeder automatischen Erneuerung sollte zudem geprüft werden, ob das neue Zertifikat tatsächlich im Einsatz ist und nicht nur ausgestellt wurde.

7. Überwachen, melden, nachweisen

Das Problem: Ohne Überwachung fällt ein Ablauf erst auf, wenn ein Dienst nicht mehr erreichbar ist oder Browser eine Warnung anzeigen. Abgelaufene Zertifikate sind deshalb eine typische Ursache vermeidbarer Ausfälle.

Die Best Practice: Reporting und Alerting informieren die Verantwortlichen rechtzeitig und gestaffelt vor dem Ablauf. Erfolgt keine Reaktion, eskaliert die Meldung an die Vertretung oder das zuständige Team. Warnungen sollten deshalb an Funktionspostfächer oder Teams gehen und nicht nur an eine einzelne Person, die gerade im Urlaub sein könnte. Neben dem Ablaufdatum prüft die Überwachung auch schwache Algorithmen, unbekannte Aussteller und widerrufene Zertifikate.

In der Praxis: Die Warnfristen orientieren sich an der Laufzeit: Bei 100 Tagen lässt eine erste Meldung etwa 30 Tage vor Ablauf genug Zeit für eine geordnete Erneuerung, eine Meldung erst wenige Tage vorher dagegen kaum Spielraum. Regelmäßige Berichte dienen zugleich als Nachweis für Audits. Aussagekräftige Kennzahlen sind der Anteil automatisch erneuerter Zertifikate, die Zahl der Zertifikate ohne Verantwortlichen und die Abweichungen von der Richtlinie.

In welcher Reihenfolge Unternehmen vorgehen

Die sieben Certificate Management Best Practices lassen sich nicht alle gleichzeitig einführen. Sinnvoll ist ein Vorgehen in vier Phasen, die sich in der Praxis überlappen:

1. Bestand und Verantwortliche klären: Discovery starten, das Inventar aufbauen und jedem Zertifikat einen Verantwortlichen zuordnen.
2. Regeln festlegen: Zertifikatsrichtlinie verabschieden, Rollen definieren und Freigaben nach Risiko staffeln.
3. Automatisieren und öffnen: Erneuerungen dort automatisieren, wo es sich am meisten lohnt, und den Fachbereichen Self-Service innerhalb der Regeln ermöglichen.
4. Messen und nachweisen: Überwachung, Eskalation und Berichte etablieren und anhand der Kennzahlen nachsteuern.

Entscheidend ist, mit der ersten Phase nicht zu warten, bis alle anderen geplant sind. Schon ein erstes Inventar zeigt, wo die größten Risiken liegen, und damit auch, wo die weiteren Phasen ansetzen sollten.

Wer im Unternehmen welche Aufgabe übernimmt

Certificate Lifecycle Management scheitert seltener an der Technik als an unklaren Zuständigkeiten. Hilfreich ist deshalb eine klare Aufteilung in vier Rollen:

• Zentrale Stelle: Ein PKI- oder Security-Team, in kleineren Unternehmen auch eine benannte Person in der IT, verantwortet Richtlinie, Inventar, Freigaben und Überwachung.
• Zertifikatsverantwortliche: Die Teams, die ein System betreiben, beantragen und erneuern dessen Zertifikate und reagieren auf Warnungen.
• Informationssicherheit und Compliance: Sie prüfen die Einhaltung der Richtlinie und nutzen die Berichte für Audits.
• Einkauf und Vertragsmanagement: Sie bündeln die Verträge mit Zertifizierungsstellen, damit nicht jede Abteilung eigene Konten anlegt.

Diese Rollen sollten schriftlich festgehalten und bei Personalwechseln nachbesetzt werden. Sonst entsteht nach einiger Zeit genau die Lücke, die das Inventar schließen sollte: Zertifikate, für die sich niemand mehr zuständig fühlt.

Checkliste: Wie gut ist Ihr Zertifikatsmanagement aufgestellt?

Die folgenden Fragen zeigen, wo Ihr Unternehmen heute steht. Jede Frage, die Sie nicht eindeutig mit Ja beantworten können, markiert ein Handlungsfeld.

• Kennen Sie alle Zertifikate in Ihrem Unternehmen, auch die außerhalb der zentralen IT?
• Hat jedes Zertifikat einen benannten Verantwortlichen und eine Vertretung?
• Gibt es schriftliche Vorgaben zu Zertifizierungsstellen, Algorithmen und Laufzeiten?
• Sind Freigaben nach dem Risiko des Zertifikats gestaffelt?
• Können Fachbereiche Zertifikate selbst beantragen, ohne Richtlinien zu umgehen?
• Werden Zertifikate mit kurzer Laufzeit automatisch erneuert und installiert?
• Erhalten die Verantwortlichen rechtzeitig Warnungen vor dem Ablauf?
• Können Sie für ein Audit jederzeit nachweisen, welche Zertifikate im Einsatz sind?

Von der Strategie zur passenden Lösung

Welche Funktionen eine Lösung abdecken muss, ergibt sich aus den Antworten auf diese Fragen, aus der vorhandenen Infrastruktur und aus der Zahl der eingesetzten Zertifizierungsstellen. Ein Unternehmen mit wenigen Webservern braucht etwas anderes als eines mit mehreren PKIs, Cloud-Umgebungen und Tausenden Maschinenidentitäten. Die Best Practices beschreiben dabei das Ziel, und eine Lösung ist nur so gut, wie sie diese Abläufe im eigenen Unternehmen unterstützt. Mit dieser Grundlage lassen sich Lösungen für Certificate Lifecycle Management vergleichen, ohne sich von Funktionslisten leiten zu lassen. Bei der Bestandsaufnahme und der Auswahl unterstützt Sie unser Team, vereinbaren Sie dazu schnell und einfach einen online Termin.