Zum Hauptinhalt springen
Ratgeber

Zertifikatsinventar aufbauen: Erkennung, Verantwortung, Datensätze

Bevor die Verlängerung automatisiert wird, muss eine Frage beantwortet sein: Welches Zertifikat, auf welchem System, in wessen Verantwortung? In den meisten Organisationen fehlt die Hälfte dieser Liste.

31. August 2026 · 6 Min. Lesezeit

Wo Zertifikate liegen

  • Load Balancer und Reverse Proxys: der sichtbarste Ort, aber auch die Systeme dahinter können Zertifikate tragen.
  • Web- und Anwendungsserver, API-Gateways, Kubernetes-Ingresses und Secret-Objekte.
  • Mail-, VPN-, Verzeichnis- (LDAPS) und Datenbankserver; Management-Schnittstellen (BMC, Switches, Storage).
  • Interne Werkzeuge: CI/CD, Monitoring, Logging; das meiste davon läuft mit selbstsignierten Zertifikaten oder interner PKI.
  • Cloud-Ressourcen: verwaltete Load Balancer und CDNs tragen eigene Zertifikate.

Erkennungsmethoden

Netzwerkscan
In vorgegebenen IP-Bereichen werden Ports mit TLS gescannt und das ausgelieferte Zertifikat gelesen. Der direkteste Weg, interne Endpunkte zu finden; nur lesend, es wird nichts verändert.
Certificate Transparency (CT)
Jedes öffentlich vertrauenswürdige Zertifikat wird in öffentliche CT-Logs geschrieben (RFC 9162). Werkzeuge wie crt.sh listen jedes jemals für eine Domain ausgestellte Zertifikat; vergessene oder nicht autorisierte Ausstellungen werden sichtbar.
DNS- und Cloud-Inventare
DNS-Zonen und Cloud-Konten liefern die Namen, die gescannt werden müssen.
Konfigurationsmanagement
Zertifikatspfade in Server-Konfigurationsdateien zeigen, an wie vielen Stellen dasselbe Zertifikat installiert ist.

Was jeder Datensatz braucht

Identität
Der SHA-256-Fingerabdruck; er unterscheidet Versionen, die für dieselbe Domain ausgestellt wurden.
Domainnamen
CN und die SAN-Liste.
Aussteller und Kette
Zertifizierungsstelle, Zwischenzertifikat, Root. Eine unvollständige Zertifikatskette auszuliefern ist ein häufiger Fehler.
Laufzeit
Ablaufdatum und Schwellwert für die Benachrichtigung.
Installationsort
System, Port, Dateipfad oder Objektname; ein Zertifikat kann an mehreren Stellen liegen.
Verantwortung und Verlängerungsweg
Das zuständige Team; Verlängerung über ACME oder manuell.

Häufige Fehler

  • Dasselbe Zertifikat an drei Stellen installiert, an einer verlängert: die alte Version wird weiterhin ausgeliefert.
  • Ein abgelaufenes Zertifikat wird weiterhin ausgeliefert und niemand bemerkt es; die Clients haben die Prüfung abgeschaltet.
  • Unvollständige Kette: Desktop-Browser funktionieren, die Mobile-App oder der API-Client scheitert.
  • Selbstsignierte und interne Zertifikate fehlen im Inventar; niemand verfolgt ihren Ablauf.

Standards und Leitfäden

NIST SP 1800-16 beschreibt das Management von TLS-Serverzertifikaten als Unternehmensprogramm: Inventar, Verantwortung, Automatisierung, Überwachung und Incident Response.

  • Die Automatisierung beginnt nicht, bevor das Inventar vollständig ist.
  • Jedes Zertifikat hat einen Verantwortlichen und eine Verlängerungsmethode.
  • Kürzere Laufzeiten lassen manuelle Prozesse nicht mehr skalieren; der Leitfaden empfiehlt ausdrücklich die Automatisierung.

Häufige Fragen

Zeigen CT-Logs interne Zertifikate?
Nein. CT erfasst nur Zertifikate öffentlicher Zertifizierungsstellen; Zertifikate aus interner PKI erfordern einen Netzwerkscan.
Wie lange dauert ein Scan?
Ein /24-Bereich ist in wenigen Minuten gescannt; große Organisationen wiederholen Scans nach Zeitplan.
Können wir das Inventar manuell führen?
In kleinem Maßstab, für kurze Zeit. Mit kürzeren Laufzeiten veraltet eine manuelle Liste schnell; Erkennung und Verifizierung sollten automatisiert werden.

Quellen

Weitere Beiträge

Verwalten Sie Ihre Zertifikate an einem Ort

Inventar, Ablaufüberwachung, Verlängerung über ACME und verifizierte Installation, in Ihrer eigenen Infrastruktur.

Demo anfragen