Cyber resilience
for your domain landscape

Certificate Lifecycle Management (CLM) im Enterprise-Umfeld ist mehr als das reine Ausstellen und Erneuern von SSL-Zertifikaten. Wer in Umgebungen mit hunderten oder tausenden Zertifikaten arbeitet, braucht strategische Antworten auf vier Kernfragen: Wie sichere ich mich gegen den Ausfall einer einzelnen Certificate Authority ab? Wie finde ich Zertifikate, von denen ich nicht weiß, dass sie existieren? Wie regle ich Zugriffsrechte auf die Ausstellungs-Infrastruktur? Und wie erkenne ich Zertifikate, die außerhalb meiner Kontrolle für meine Domains ausgestellt wurden? Diese Seite ordnet die vier Bausteine ein.

Sie möchten direkt zur technischen Umsetzung?

Werfen Sie einen Blick auf die technische Umsetzung über die RFC-2136-Schnittstelle

ACME über RFC 2136
Inhalte

Warum Certificate Lifecycle Management im Enterprise anders funktioniert

In kleinen Umgebungen mit einer Hand voll Zertifikaten reicht ein guter ACME-Client aus. Ausgestellt, installiert, automatisch verlängert – fertig. Diese Sicht ist technisch korrekt, aber greift für Enterprise-Umgebungen zu kurz. Sobald das Portfolio dreistellig wird, entstehen strukturelle Herausforderungen, die keine reine Client-Frage sind.

Vervielfachung der Angriffsfläche. Jedes Zertifikat ist ein potenzieller Schwachpunkt: privater Schlüssel muss geschützt werden, Ausstellungs-Prozess muss abgesichert sein, Renewal darf nicht ausfallen. Bei fünfhundert Zertifikaten ist die kumulative Angriffsfläche fünfhundertmal größer als bei einem einzelnen.

Reglementarische Anforderungen. ISO 27001, NIS-2, DORA und BSI-Grundschutz verlangen zunehmend explizite Nachweise über Zertifikats-Prozesse: wer hat wann welches Zertifikat für welche Domain ausgestellt, wer hatte Schreibrechte, wie wurde bei Kompromittierung reagiert. Diese Nachweise müssen im Audit belastbar sein.

Organisatorische Fragmentierung. Enterprise-IT ist selten homogen. Verschiedene Teams (Web, API, Mobile, Backend, Legacy) verwalten Zertifikate oft unabhängig voneinander. Zentrale Sichtbarkeit fehlt strukturell.

Zeitliche Dynamik. Mit der 200-Tage-Regel ab Oktober 2026 – und den folgenden Verkürzungen auf 100 und 47 Tage – wird die Frequenz der Zertifikats-Prozesse strukturell hoch. Manuelle Nachsteuerung ist nicht mehr möglich.

Aus diesen vier Faktoren ergibt sich die Grundfrage jedes Enterprise-CLM-Ansatzes: Wie schaffe ich Governance-Transparenz und Automatisierungs-Robustheit gleichzeitig? Vier strategische Bausteine sind zentral.

Baustein 1 – Multi-CA-Strategie

Warum eine einzelne CA-Abhängigkeit riskant ist

Die vergangenen Jahre haben mehrfach gezeigt, dass auch etablierte Certificate Authorities in kurzer Zeit Vertrauensverlust erleiden können. Konkrete Beispiele:

Compliance-Verstöße einzelner CAs. Symantec-CA-Zertifikate wurden 2018 durch Google Chrome schrittweise als nicht mehr vertrauenswürdig eingestuft, nachdem strukturelle Prozess-Mängel im Ausstellungsverfahren festgestellt wurden. Kunden, die Symantec-Zertifikate im Einsatz hatten, mussten in kurzer Zeit umstellen.

Regulierungs-Änderungen. Politische Ereignisse können den Einsatz einzelner CAs in bestimmten Regionen einschränken. Für Unternehmen mit internationalem Geschäft ist eine Multi-CA-Fähigkeit damit auch geopolitische Absicherung.

Technische Ausfälle. Auch etablierte CAs haben in der Vergangenheit Ausfälle ihres Ausstellungs-Systems gehabt, die über Stunden oder Tage andauerten. Wer in dieser Zeit ein Zertifikat neu ausstellen musste, hatte keinen Ausweg – außer eine zweite CA im Portfolio zu haben.

Was eine belastbare Multi-CA-Strategie leistet

Wahlfreiheit ohne Endsystem-Umbau. Wenn Sie heute mit Let’s Encrypt arbeiten und morgen zu Sectigo oder DigiCert wechseln müssen, sollte dieser Wechsel eine Konfigurationsänderung sein – kein struktureller Umbau auf allen betroffenen Servern.

Domain-Pattern-basierte CA-Zuordnung. In ausgereiften Setups wird pro Domain-Pattern die passende CA gewählt: Let’s Encrypt für Standard-Webserver, Sectigo für OV-Zertifikate, DigiCert für EV-Zertifikate. Diese Zuordnung sollte in einer zentralen Konfiguration liegen, nicht in jedem einzelnen ACME-Client.

Rapid-Switch-Fähigkeit. Im Falle eines akuten CA-Vorfalls muss der Wechsel innerhalb weniger Stunden möglich sein – nicht innerhalb von Wochen. Das setzt voraus, dass die Alternative-CA bereits vor-konfiguriert und getestet ist.

Kosten-Optimierung durch CA-Bündelung. Enterprise-Rahmenverträge mit einer CA verhandeln sich anders als der Ad-hoc-Bezug einzelner Zertifikate. Multi-CA-Fähigkeit ermöglicht das gezielte Verhandeln pro CA nach Volumen und Validierungslevel.

Wo klassische ACME-Clients an Grenzen kommen

Certbot, acme.sh und cert-manager können prinzipiell alle gegen jede ACME-fähige CA laufen. Das reicht für Multi-CA-Basics – aber nicht für Enterprise-Governance. Was fehlt:

  • Zentrale Konfiguration der CA-Auswahl pro Domain-Pattern
  • Auditierbarkeit der Ausstellungs-Historie über CAs hinweg
  • Automatisches Fallback im Fehler-Fall
  • Cost-Reporting je CA und Bestell-Volumen

Diese Governance-Ebene ist genau die Lücke, die zwischen einem reinen Client-Betrieb und einer strategischen Enterprise-CLM-Plattform besteht.

Baustein 2 – Certificate Discovery

Der häufigste Ausgangspunkt für ein Enterprise-CLM-Projekt lautet: „Wir wissen nicht genau, wie viele Zertifikate wir haben.” Das ist keine Ausnahme, sondern der Regelfall.

Wie es zu unbekannten Zertifikaten kommt

Historische Ausstellungen. Zertifikate, die vor Jahren einmalig für ein spezifisches Projekt ausgestellt wurden und deren Ansprechpartner das Unternehmen längst verlassen haben.

Dezentrale Ausstellungs-Prozesse. Wenn jeder Fach-Bereich autark Zertifikate anfordert (via Certbot auf dem eigenen Server, via Direkt-Bestellung bei einer CA, via einer Cloud-Plattform), fehlt zentrale Sichtbarkeit.

Shadow-IT-Deployments. Zertifikate, die in Test-Umgebungen ausgestellt wurden und ungeplant in produktive Landschaften eingezogen sind – ohne dokumentierten Owner.

Legacy-Systeme. Alte Appliances, Hardware-Boxen und interne Anwendungen, die Zertifikate manuell installiert bekommen haben – und deren Betriebsverantwortung im Laufe der Zeit unklar wurde.

Warum Discovery vor Automatisierung kommen muss

Wer Zertifikats-Renewal automatisiert, ohne den Bestand zu kennen, automatisiert ein blindes Feld. Konkret bedeutet das:

  • Zertifikate, die im automatischen Prozess nicht erfasst sind, laufen weiter manuell ab – mit dem entsprechenden Ausfall-Risiko
  • Compliance-Reports sind unvollständig, weil Zertifikate außerhalb des CLM-Systems nicht in die Auswertung einfließen
  • Kosten sind nicht steuerbar, weil unbekannte Zertifikate weiter über Direkt-Verträge laufen

Ein sauber aufgesetzter Discovery-Prozess ist damit die Grundlage jedes belastbaren CLM-Setups.

Wie Discovery in der Praxis funktioniert

Network-basiertes Scanning. Aktives Anfragen der TLS-Endpunkte im internen Netzwerk. Für jeden gefundenen Endpoint werden die Zertifikats-Metadaten (Common Name, SAN, Issuer, Ablaufdatum) erfasst.

CT-Log-basiertes Scanning. Certificate-Transparency-Logs enthalten alle öffentlich vertrauenswürdigen Zertifikate, die für Ihre Domains ausgestellt wurden. Das ist besonders relevant, um Zertifikate zu finden, die außerhalb Ihrer Kontrolle ausgestellt wurden (siehe Baustein 4).

Cloud-Provider-Integration. In Cloud-nativen Umgebungen (AWS, Azure, GCP) können API-basierte Abfragen die dort verwalteten Zertifikate direkt inventarisieren.

Endsystem-basiertes Reporting. Auf Servern installierte Zertifikate lassen sich per Konfigurations-Management-Tool (Ansible, Puppet, Chef) oder direkt per API abfragen.

Ein belastbares Discovery-Setup kombiniert mehrere dieser Quellen und dedupliziert die Ergebnisse in einer zentralen Inventar-Datenbank.

Baustein 3 – Zero-Trust-Prinzipien für Zertifikatsverwaltung

Das Zero-Trust-Modell besagt: kein Nutzer, kein System, kein Prozess erhält Vertrauen nur aufgrund seiner Netzwerk-Position. Jede Aktion muss explizit autorisiert werden. Für die Zertifikatsverwaltung heißt das konkret:

Rechte-Trennung nach Zuständigkeit

Wer ein Zertifikat für eine bestimmte Domain anfordern darf, muss nicht auch die DNS-Konfiguration ändern können. Und wer die DNS-Konfiguration ändern kann, sollte nicht automatisch Zugriff auf die private-Key-Speicherung haben.

In der Praxis heißt das:

  • Owner-Rolle für einzelne Domains: kann Zertifikate anfordern, aber nicht die zugrundeliegende DNS-Zone ändern
  • DNS-Admin-Rolle: pflegt DNS-Einträge, hat aber keinen Zugriff auf Zertifikats-Metadaten oder private Keys
  • Audit-Rolle: hat Lesezugriff auf alle Prozesse für Compliance-Zwecke, kann aber selbst keine Änderungen vornehmen

Segmentierung der Validierungs-Pfade

Wenn ein ACME-Client auf einer Domain schreiben darf, um die DCV-Challenge zu beantworten, darf er nur auf einen dedizierten Validierungs-Namespace schreiben – nicht auf die produktive DNS-Zone. Das DCV-Zonen-Konzept mit CNAME-Delegation (im Detail auf der Webseite ACME über RFC 2136 DNS-01 beschrieben) ist die architektonische Umsetzung dieses Zero-Trust-Prinzips.

Least-Privilege-Access für automatisierte Prozesse

API-Tokens und TSIG-Keys sollten so scoped sein, dass sie ausschließlich die Rechte haben, die für ihre spezifische Aufgabe nötig sind. Ein Token, der zum Beispiel Zertifikate für 
*.example.com
anfordern soll, sollte technisch nicht in der Lage sein, Zertifikate für 
*.example.com
anzufordern.

Kontinuierliche Verifikation

Zugriffs-Rechte sind kein einmaliger Zustand, sondern werden regelmäßig überprüft. Bei Personal-Wechseln, Team-Umstrukturierungen oder System-Migrationen müssen bestehende Rechte hinterfragt werden. Ein zentrales Audit-Log macht diese Verifikation überhaupt erst möglich.

Baustein 4 – CT-Log-Monitoring zum Erkennen von Angriffen

Certificate Transparency (CT) ist ein öffentliches Log-System, in dem alle öffentlich vertrauenswürdigen Zertifikate registriert werden. Für Enterprise-CLM ist CT-Monitoring aus zwei Gründen relevant.

Wie Sie das nicht-autorisierte Ausstellen von Zertifikaten erkennen

Wenn jemand ein Zertifikat für Ihre Domain ausstellen lässt, ohne dass Sie das autorisiert haben, erscheint dieses Zertifikat im CT-Log. Angriffs-Vektoren, die dahinter stecken können:

  • CA-Kompromittierung: Ein Angreifer bewegt eine CA (mit gestohlenen Credentials oder Social-Engineering) dazu, ein Zertifikat für Ihre Domain auszustellen
  • DNS-Hijackweing: Ein Angreifer übernimmt kurzzeitig die Kontrolle über Ihre DNS-Einträge und lässt ein Zertifikat für Ihre Domain ausstellen
  • Insider-Threat: Ein autorisierter Mitarbeiter stellt ein Zertifikat aus, das nicht vorgesehen war
  • Shadow-IT: Ein Fach-Bereich stellt eigenmächtig ein Zertifikat für eine Firmen-Domain aus, ohne die zentrale IT einzubeziehen

Ein aktives CT-Log-Monitoring meldet solche ausgestellten Zertifikate typischerweise innerhalb weniger Stunden. Damit haben Sie ein Frühwarn-System, das ohne CT-Monitoring gar nicht existieren würde.

Ergänzung zum Certificate Discovery

CT-Logs sind auch eine passive Discovery-Quelle: Sie zeigen alle öffentlich vertrauenswürdigen Zertifikate für Ihre Domains, unabhängig davon, wo sie deployed sind. Für Unternehmen mit vielen Sub-Domains und historisch gewachsenen Setups ist das oft die einzige Möglichkeit, ein wirklich vollständiges Bild zu bekommen.

Wie CT-Monitoring in der Praxis eingerichtet wird

Manuell: Über öffentliche Tools wie crt.sh können Sie Ihre Domains einzeln abfragen. Das ist für Ad-hoc-Prüfungen sinnvoll, für kontinuierliches Monitoring aber nicht praktikabel.

Skript-basiert: Ein eigenes Skript, das regelmäßig die CT-Log-APIs abfragt und Änderungen protokolliert. Machbar, bedeutet aber deutlichen Wartungsaufwand.

Managed CT-Monitoring: Als Teil einer Enterprise-CLM-Plattform. Neue Zertifikate für Ihre Domains werden automatisch erkannt, unbekannte Ausstellungen alarmiert. Kein separates Skript, keine eigene Infrastruktur.

Compliance-Anforderungen im Enterprise-Kontext

Die vier Bausteine haben nicht nur operativen Nutzen, sondern erfüllen zunehmend explizite regulatorische Anforderungen:

  • ISO 27001 (Annex A, A.10.1.1 – Kryptografie-Richtlinie): verlangt eine dokumentierte Strategie für den Einsatz kryptografischer Verfahren, inklusive Zertifikats-Lebenszyklus. Multi-CA-Strategie, Discovery und Audit-Trail sind zentrale Bausteine dieser Dokumentation.
  • NIS-2 (Art. 21, Risikomanagement-Maßnahmen): verlangt Maßnahmen zum Umgang mit Vorfällen, inklusive Wiederherstellung nach Kompromittierung. Rapid-CA-Switch und CT-Monitoring adressieren genau diese Anforderungen.
  • DORA (Kap. II, ICT-Risikomanagement): verlangt für Finanz-Dienstleister explizit die Absicherung von Verschlüsselungs-Prozessen. Zero-Trust-Rechte-Trennung und lückenlose Audit-Logs sind hier direkt relevant.
  • BSI-Grundschutz (CON.1 – Kryptokonzept): setzt strukturell die gleichen Anforderungen wie ISO 27001, mit teils detaillierteren Umsetzungs-Anleitungen.

Der Detail-Grad der Nachweispflicht wird mit jedem Regulierungs-Update strenger. Wer heute noch mit einer manuellen Excel-Übersicht arbeitet, kann diese Nachweise praktisch nicht sauber führen. Ein zentraler Audit-Trail ist mittelfristig nicht optional.

LEMARIT Certificate Automation im Enterprise-Kontext

Alle vier oben beschriebenen Bausteine setzt LEMARIT Certificate Automation strukturell um – nicht als Zusatz-Feature, sondern als Kern-Architektur der Plattform.

Multi-CA-Governance. Über die LEMARIT.app konfigurieren Sie pro Domain-Pattern die gewünschte Certificate Authority – Let’s Encrypt, Sectigo, DigiCert, SSL.com oder andere angebundene Partner. Der Wechsel zwischen CAs ist eine Konfigurationsänderung in der Plattform, ohne dass Ihre ACME-Clients oder Endsysteme angepasst werden müssen.

Certificate Discovery. Für neue Kunden bieten wir eine initiale Discovery-Phase an, in der wir Ihren Bestand aus mehreren Quellen inventarisieren – interne Netzwerk-Scans, CT-Log-Abgleich und Import aus bestehenden CA-Portalen. Das Ergebnis ist ein vollständiges Portfolio-Inventar als Basis für alle weiteren Schritte.

Zero-Trust-Rechte-Modell. Die Plattform kennt granulare Rollen (Owner, DNS-Admin, Audit, Support), die pro Domain-Pattern oder Zertifikats-Gruppe zugewiesen werden. TSIG-Keys und EAB-Credentials werden ausschließlich auf DCV-Namespaces gescoped, nie auf produktive DNS-Zonen.

CT-Log-Monitoring. Wir überwachen die Certificate-Transparency-Logs kontinuierlich auf neue Ausstellungen für Ihre Domains. Ausstellungen, die nicht über die LEMARIT-Plattform laufen, werden Ihrem Account-Manager gemeldet – Sie erfahren innerhalb weniger Stunden von einem potenziellen Vorfall.

Audit-Trail-Export. Jede Ausstellung, jeder Widerruf und jede Konfigurationsänderung wird protokolliert. ISO-27001-, NIS-2- und DORA-konforme Exports stehen direkt aus der LEMARIT.app zur Verfügung.

Deutsche Datenverarbeitung. Alle Daten und Prozesse werden ausschließlich in Deutschland verarbeitet, ohne Sub-Provider mit US-Rechtsraum-Bezug. Für Kunden mit DSGVO- oder Souveränitäts-Anforderungen ein relevanter Baustein.

ACME über RFC 2136

Häufige Fragen (FAQ)

Ab welcher Portfolio-Größe lohnt sich ein Enterprise-CLM-Setup?

Erfahrungsgemäß liegt der Break-Even bei rund 50 aktiven Zertifikaten pro Umgebung. Unterhalb dieser Größe kann ein Team mit Standard-ACME-Clients und einer sauberen Dokumentation den Prozess noch selbst stemmen. Oberhalb steigen die Skalierungs-Kosten überproportional – Config-Drift, Multi-CA-Anforderungen und Monitoring-Blindstellen werden zum operativen Risiko.
Ein ACME-Setup lösst die technische Frage der Ausstellung und Erneuerung. Enterprise-CLM adressiert die strategischen Fragen darüber: Multi-CA-Absicherung, Discovery, Governance, Compliance-Nachweisführung. ACME ist eine Komponente von Enterprise-CLM, nicht das Ganze.
Ja, das ist der praktische Regelfall. Sie behalten Ihre Certbot-, acme.sh- oder cert-manager-Installationen und ändern nur den ACME-Endpoint auf die LEMARIT-Plattform. Discovery, Multi-CA-Konfiguration und Zero-Trust-Rollen werden dann in der Plattform aufgesetzt, ohne dass die Endsysteme umgebaut werden müssen.
Selbst-signierte Zertifikate und private CA-Ausstellungen erscheinen NICHT im öffentlichen CT-Log, weil sie nicht durch eine öffentlich vertrauenswürdige CA gehen. Das CT-Log deckt ausschließlich öffentlich vertrauenswürdige Zertifikate ab – exakt der Bereich, in dem Sie ein Missbrauchs-Risiko haben.
LEMARIT hat mehrere Partner-CAs angebunden und kann im Ausfall-Fall einer einzelnen CA Ausstellungen auf eine Alternative-CA umleiten – für die betroffenen Kunden transparent und ohne Endsystem-Änderung. Diese Rapid-Switch-Fähigkeit ist eine der zentralen Design-Entscheidungen der Plattform.
Die relevanten CT-Logs sind öffentlich und werden von den großen Browsern (Chrome, Firefox, Safari) betrieben oder anerkannt. LEMARIT monitored die anerkannten CT-Logs kontinuierlich und dedupliziert die Findings. Für Kunden ist das Frontend die zentrale Alerting-Anzeige in der LEMARIT.app.
Für ein Portfolio mit 100 bis 500 Zertifikaten liegt die typische Discovery-Phase zwischen einer und drei Wochen. Der Aufwand ist stark abhängig von der Reife Ihrer bestehenden Dokumentation und der Zugänglichkeit Ihrer Systeme. Wir bieten Discovery als eigenständige Beratungsphase an, unabhängig davon, ob Sie danach mit LEMARIT als Plattform weiterarbeiten.

Der Weg zu einem belastbaren Enterprise-CLM-Setup

Sie haben jetzt einen Überblick über die vier strategischen Bausteine. Die konkrete Umsetzung folgt in den meisten Enterprise-Umgebungen einer klaren Sequenz: erst Discovery (den Bestand erfassen), dann Multi-CA-Setup (Anbieter-Diversifikation), dann Zero-Trust-Rollen (Rechte-Modell), dann CT-Monitoring (Angriffserkennung). Compliance-Reporting läuft parallel dazu mit.
Wenn Sie diesen Weg jetzt für Ihr Unternehmen planen wollen, ist ein 30-minütiges Erstgespräch mit unserem Team der pragmatischste Einstieg. Wir ordnen gemeinsam ein, wo Sie stehen, wo die dringlichsten Handlungsfelder sind und wie eine Umsetzungs-Sequenz für Ihr Portfolio aussehen könnte.
LEMARIT Certificate Automation ansehen
©SARIPICTURE Sarah Domandl LEMARIT Stockfotos 0236 20260219

Weiterführende Inhalte

ACME über RFC 2136: DNS-01-Validierung mit TSIG

Was ist ACME? Bedeutung, Funktionsweise & Vorteile

DV, OV, EV – die drei SSL-Validierungsstufen im Überblick

ACME einrichten: Schritt-für-Schritt-Anleitung

SSL-Zertifikate automatisch verlängern

Close
Suchen