\u00d6ffentliche TLS-Zertifikate gelten seit M\u00e4rz 2026 h\u00f6chstens 200 Tage, ab M\u00e4rz 2027 nur noch 100. Ob Unternehmen mithalten, h\u00e4ngt weniger vom Werkzeug ab als davon, wie sie Certificate Lifecycle Management aufsetzen.<\/p>\n
Bei einer Laufzeit von 100 Tagen steht f\u00fcr jedes Zertifikat drei- bis viermal im Jahr eine Erneuerung an, und die Laufzeit von SSL-Zertifikaten<\/a> wird auch danach weiter sinken. Gleichzeitig liegen Zertifikate l\u00e4ngst nicht mehr nur auf Webservern, sondern in Cloud-Diensten, Containern, Ger\u00e4ten und internen Anwendungen, f\u00fcr die unterschiedliche Teams zust\u00e4ndig sind. Einzelne Ma\u00dfnahmen wie eine bessere Tabelle oder ein zus\u00e4tzlicher Erinnerungsdienst reichen daf\u00fcr nicht mehr aus.<\/p>\n Was Certificate Lifecycle Management<\/a> grunds\u00e4tzlich 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\u00e4sst, organisatorisch ebenso wie technisch. Sieben Bereiche entscheiden dar\u00fcber, ob sie im Alltag tr\u00e4gt.<\/p>\n 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\u00dflich die Konsequenz f\u00fcr den Alltag. Die Reihenfolge folgt der Einf\u00fchrung im Unternehmen und nicht der Wichtigkeit, denn jeder Schritt baut auf dem vorherigen auf. Ohne vollst\u00e4ndigen Bestand l\u00e4sst sich nichts steuern, und ohne klare Regeln l\u00e4sst sich nichts sinnvoll automatisieren.<\/p>\n Das Problem:<\/strong> Zertifikate entstehen h\u00e4ufig au\u00dferhalb zentraler Prozesse. Entwicklerteams richten sie f\u00fcr Testumgebungen ein, Cloud-Dienste stellen sie automatisch aus, Dienstleister bringen eigene mit. Ein Teil davon ist der IT nicht bekannt und f\u00e4llt erst auf, wenn er abl\u00e4uft.<\/p>\n Die Best Practice:<\/strong> Zertifikate werden regelm\u00e4\u00dfig und automatisiert erfasst und in einem zentralen Inventar zusammengef\u00fchrt. Quellen daf\u00fcr sind Netzwerkscans, die Konten bei den Zertifizierungsstellen, Cloud-Plattformen und Zertifikatsspeicher. F\u00fcr \u00f6ffentlich vertrauensw\u00fcrdige Zertifikate zeigen zudem die Certificate-Transparency-Logs, welche Zertifikate f\u00fcr die eigenen Domains ausgestellt wurden. Im Inventar stehen zu jedem Zertifikat mindestens Fundort, Aussteller, Ablaufdatum, Schl\u00fcsseltyp und der zust\u00e4ndige Verantwortliche.<\/p>\n In der Praxis:<\/strong> 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\u00f6ren nicht nur Serverzertifikate in den Blick, sondern auch Maschinenidentit\u00e4ten<\/a> von Diensten, Ger\u00e4ten 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\u00dferhalb der bekannten Wege entstanden sind.<\/p>\n Das Problem:<\/strong> In vielen Unternehmen gibt es nur zwei Zust\u00e4nde. Entweder l\u00e4uft jede Anfrage \u00fcber die zentrale IT und wird dort zum Engpass, oder die Fachbereiche beschaffen ihre Zertifikate selbst, jeweils bei einem anderen Anbieter und nach eigenen Regeln.<\/p>\n Die Best Practice:<\/strong> Eine zentrale Stelle legt fest, welche Zertifizierungsstellen und Zertifikatstypen zul\u00e4ssig 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.<\/p>\n In der Praxis:<\/strong> F\u00fcr jedes Zertifikat gibt es einen benannten Verantwortlichen und eine Vertretung. Diese Zust\u00e4ndigkeit endet nicht mit der Ausstellung, sondern umfasst Erneuerung und Widerruf. Sie steht im Inventar und wird bei Personalwechseln aktiv \u00fcbertragen, damit kein Zertifikat ohne Verantwortlichen zur\u00fcckbleibt.<\/p>\n Das Problem:<\/strong> Ohne Vorgaben entscheidet jede Abteilung selbst \u00fcber Zertifizierungsstelle, Schl\u00fcssell\u00e4nge und Speicherort der privaten Schl\u00fcssel. Sp\u00e4testens bei einem Audit zeigt sich dann ein uneinheitliches Bild, das sich nur m\u00fchsam erkl\u00e4ren l\u00e4sst.<\/p>\n Die Best Practice:<\/strong> Eine schriftliche Zertifikatsrichtlinie legt die zugelassenen Zertifizierungsstellen fest, au\u00dferdem Zertifikatstypen je Einsatzzweck, Algorithmen und Schl\u00fcssell\u00e4ngen, maximale Laufzeiten, Regeln f\u00fcr die Speicherung privater Schl\u00fcssel sowie einheitliche Benennungen. F\u00fcr besonders sch\u00fctzenswerte Schl\u00fcssel kann die Richtlinie zum Beispiel die Speicherung in einem Hardware-Sicherheitsmodul vorschreiben.<\/p>\n In der Praxis:<\/strong> Standards sollten so formuliert sein, dass sie sich \u00e4ndern lassen. Das betrifft vor allem die Algorithmen: Mit der Post-Quanten-Kryptographie<\/a> kommen neue Verfahren hinzu, die sich ohne Neuaufbau einf\u00fchren lassen m\u00fcssen. Diese F\u00e4higkeit wird als Krypto-Agilit\u00e4t bezeichnet. Die Richtlinie wird deshalb regelm\u00e4\u00dfig \u00fcberpr\u00fcft und nicht erst dann, wenn eine Branchenvorgabe wie die n\u00e4chste Laufzeitverk\u00fcrzung bereits gilt. Sie sollte au\u00dferdem festlegen, was mit Zertifikaten geschieht, die ihr nicht entsprechen: ob sie bis zur n\u00e4chsten Erneuerung geduldet oder sofort ersetzt werden.<\/p>\n Das Problem:<\/strong> Wird jede Anfrage einzeln freigegeben, dauern Routinef\u00e4lle unn\u00f6tig lange. Wird dagegen keine Anfrage gepr\u00fcft, entstehen auch Zertifikate mit hohem Risiko ohne Kontrolle, etwa Wildcard-Zertifikate, die f\u00fcr beliebig viele Subdomains einer Ebene gelten.<\/p>\n Die Best Practice:<\/strong> Approval Workflows werden nach Zertifikatstyp und Risiko gestaffelt. Standardzertifikate, die der Richtlinie entsprechen, werden ohne manuelle Freigabe ausgestellt. Sonderf\u00e4lle wie Wildcard-Zertifikate oder Zertifikate, die die Identit\u00e4t des Unternehmens best\u00e4tigen, durchlaufen eine Freigabe durch eine zweite Person. Ein Zertifikat f\u00fcr einen internen Testserver wird so ohne Wartezeit ausgestellt, ein Wildcard-Zertifikat f\u00fcr die Hauptdomain dagegen erst nach Pr\u00fcfung.<\/p>\n In der Praxis:<\/strong> Die Freigaberegeln sind dokumentiert, und jede Freigabe wird protokolliert. Dadurch entsteht nebenbei ein Nachweis f\u00fcr Audits. Lohnend ist auch ein Blick darauf, wie lange Freigaben im Durchschnitt dauern, denn lange Wartezeiten sind ein h\u00e4ufiger Grund daf\u00fcr, dass Teams den Prozess umgehen.<\/p>\n Das Problem:<\/strong> Wenn der offizielle Weg zu einem Zertifikat umst\u00e4ndlich ist, suchen sich Teams einen anderen. So entstehen Zertifikate, die in keinem Inventar auftauchen und f\u00fcr die niemand zust\u00e4ndig ist.<\/p>\n Die Best Practice:<\/strong> \u00dcber delegierte Administration erhalten Teams eigene Rechte f\u00fcr einen klar umrissenen Bereich, zum Beispiel f\u00fcr bestimmte Domains oder Zertifikatstypen. Innerhalb dieses Bereichs beantragen, erneuern und widerrufen sie Zertifikate selbst, w\u00e4hrend die Richtlinien automatisch greifen.<\/p>\n In der Praxis:<\/strong> Ein Self-Service-Portal oder eine Schnittstelle ersetzt das Ticket an die zentrale IT. Die zentrale Stelle beh\u00e4lt dennoch den \u00dcberblick, weil jedes so ausgestellte Zertifikat im Inventar landet. Ein typisches Beispiel ist ein Entwicklungsteam, das f\u00fcr seine Testumgebungen selbst Zertifikate ausstellen darf, allerdings nur unterhalb einer festgelegten Subdomain und nur mit den zugelassenen Zertifikatstypen. Die vergebenen Rechte werden regelm\u00e4\u00dfig \u00fcberpr\u00fcft und bei Rollenwechseln angepasst.<\/p>\n Das Problem:<\/strong> Bei 100 Tagen Laufzeit wird die manuelle Erneuerung zum Dauerbetrieb. Jeder Handgriff vom Antrag bis zur Installation ist eine m\u00f6gliche Fehlerquelle, und mit der Zahl der Zertifikate steigt der Aufwand linear.<\/p>\n Die Best Practice:<\/strong> Ausstellung, Erneuerung und Installation laufen automatisiert, \u00fcber standardisierte Protokolle wie das ACME-Protokoll<\/a> oder \u00fcber die Schnittstellen von Zertifizierungsstellen und Plattformen. Welcher Weg passt, h\u00e4ngt von der Umgebung ab: Die Umstellung auf ACME, eine PKI as a Service und eine zentrale Plattform sind die drei g\u00e4ngigen Ans\u00e4tze der Zertifikatsautomatisierung<\/a>.<\/p>\n In der Praxis:<\/strong> Am meisten bringt die Automatisierung bei Systemen, die h\u00e4ufig erneuert werden und standardisiert sind, etwa bei Webservern und Load Balancern. Zur Automatisierung geh\u00f6rt auch die Verteilung auf die Zielsysteme, denn ein automatisch erneuertes Zertifikat n\u00fctzt wenig, wenn es anschlie\u00dfend von Hand auf mehreren Servern eingespielt werden muss. Systeme, die sich nicht automatisieren lassen, werden als Ausnahme dokumentiert und besonders eng \u00fcberwacht. Nach jeder automatischen Erneuerung sollte zudem gepr\u00fcft werden, ob das neue Zertifikat tats\u00e4chlich im Einsatz ist und nicht nur ausgestellt wurde.<\/p>\n Das Problem:<\/strong> Ohne \u00dcberwachung f\u00e4llt ein Ablauf erst auf, wenn ein Dienst nicht mehr erreichbar ist oder Browser eine Warnung anzeigen. Abgelaufene Zertifikate<\/a> sind deshalb eine typische Ursache vermeidbarer Ausf\u00e4lle.<\/p>\n Die Best Practice:<\/strong> Reporting und Alerting informieren die Verantwortlichen rechtzeitig und gestaffelt vor dem Ablauf. Erfolgt keine Reaktion, eskaliert die Meldung an die Vertretung oder das zust\u00e4ndige Team. Warnungen sollten deshalb an Funktionspostf\u00e4cher oder Teams gehen und nicht nur an eine einzelne Person, die gerade im Urlaub sein k\u00f6nnte. Neben dem Ablaufdatum pr\u00fcft die \u00dcberwachung auch schwache Algorithmen, unbekannte Aussteller und widerrufene Zertifikate.<\/p>\n In der Praxis:<\/strong> Die Warnfristen orientieren sich an der Laufzeit: Bei 100 Tagen l\u00e4sst eine erste Meldung etwa 30 Tage vor Ablauf genug Zeit f\u00fcr eine geordnete Erneuerung, eine Meldung erst wenige Tage vorher dagegen kaum Spielraum. Regelm\u00e4\u00dfige Berichte dienen zugleich als Nachweis f\u00fcr Audits. Aussagekr\u00e4ftige Kennzahlen sind der Anteil automatisch erneuerter Zertifikate, die Zahl der Zertifikate ohne Verantwortlichen und die Abweichungen von der Richtlinie.<\/p>\n Die sieben Certificate Management Best Practices lassen sich nicht alle gleichzeitig einf\u00fchren. Sinnvoll ist ein Vorgehen in vier Phasen, die sich in der Praxis \u00fcberlappen:<\/p>\n Entscheidend ist, mit der ersten Phase nicht zu warten, bis alle anderen geplant sind. Schon ein erstes Inventar zeigt, wo die gr\u00f6\u00dften Risiken liegen, und damit auch, wo die weiteren Phasen ansetzen sollten.<\/p>\n Certificate Lifecycle Management scheitert seltener an der Technik als an unklaren Zust\u00e4ndigkeiten. Hilfreich ist deshalb eine klare Aufteilung in vier Rollen:<\/p>\n Diese Rollen sollten schriftlich festgehalten und bei Personalwechseln nachbesetzt werden. Sonst entsteht nach einiger Zeit genau die L\u00fccke, die das Inventar schlie\u00dfen sollte: Zertifikate, f\u00fcr die sich niemand mehr zust\u00e4ndig f\u00fchlt.<\/p>\n Die folgenden Fragen zeigen, wo Ihr Unternehmen heute steht. Jede Frage, die Sie nicht eindeutig mit Ja beantworten k\u00f6nnen, markiert ein Handlungsfeld.<\/p>\n Welche Funktionen eine L\u00f6sung 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\u00e4ten. Die Best Practices beschreiben dabei das Ziel, und eine L\u00f6sung ist nur so gut, wie sie diese Abl\u00e4ufe im eigenen Unternehmen unterst\u00fctzt. Mit dieser Grundlage lassen sich L\u00f6sungen f\u00fcr Certificate Lifecycle Management vergleichen, ohne sich von Funktionslisten leiten zu lassen. Bei der Bestandsaufnahme und der Auswahl unterst\u00fctzt Sie unser Team, vereinbaren Sie dazu schnell und einfach einen online Termin<\/a>.<\/p>\nSieben Best Practices f\u00fcr Certificate Lifecycle Management<\/h2>\n
1. Den Bestand kontinuierlich erfassen<\/h3>\n
2. Zentral steuern, dezentral ausstellen<\/h3>\n
3. Verbindliche Standards festlegen<\/h3>\n
4. Genehmigungen nach Risiko staffeln<\/h3>\n
5. Self-Service erm\u00f6glichen, ohne Kontrolle abzugeben<\/h3>\n
6. Wiederkehrende Aufgaben automatisieren<\/h3>\n
7. \u00dcberwachen, melden, nachweisen<\/h3>\n
In welcher Reihenfolge Unternehmen vorgehen<\/h2>\n
\n
Wer im Unternehmen welche Aufgabe \u00fcbernimmt<\/h2>\n
\n
Checkliste: Wie gut ist Ihr Zertifikatsmanagement aufgestellt?<\/h2>\n
\n
Von der Strategie zur passenden L\u00f6sung<\/h2>\n