TLS-Zertifikate automatisiert verwalten: Mit ACME auf kürzere Laufzeiten vorbereiten

Montagmorgen, kurz vor einem wichtigen Kundentermin: Das Kundenportal liefert plötzlich nur noch eine Browserwarnung. Die Ursache ist kein Angriff und kein Serverausfall, sondern ein am Wochenende abgelaufenes TLS-Zertifikat. Solche Vorfälle sind vermeidbar, werden aber wahrscheinlicher, wenn Zertifikatslaufzeiten kürzer werden und Teams ihre Erneuerungen weiterhin über Kalendertermine, Tabellen und Einzelwissen organisieren.

TLS-Zertifikate sind ein zentraler Baustein für sichere Verbindungen. Sie schützen die Übertragung zwischen Browsern, Anwendungen, APIs und Diensten vor dem Mitlesen und Manipulieren. Gleichzeitig bestätigen sie, mit welchem Server oder Dienst sich ein Client verbindet. Läuft ein Zertifikat ab, verweigern Browser, Clients oder Integrationen je nach Konfiguration den Zugriff. Das kann Websites, VPN-Zugänge, Maildienste, APIs, interne Anwendungen und Maschinenkommunikation treffen.

Kürzere Laufzeiten erhöhen daher nicht nur den administrativen Aufwand. Sie machen ein verlässliches, automatisiertes Zertifikatsmanagement zur Betriebsaufgabe. Bei uns sehen wir regelmäßig, dass Teams zwar einzelne Webserver gut im Blick haben, aber Zertifikate auf Load Balancern, Reverse Proxys, Monitoring-Endpunkten, Testsystemen oder Drittanbieterplattformen übersehen.

Infografik zu TLS-Zertifikate automatisiert verwalten: Mit ACME auf kürzere Laufzeiten vorbereiten (KI-generiert).

Warum kürzere Laufzeiten Prozesse sichtbar machen

Manuelle Verlängerungen funktionieren nur so lange, wie wenige Zertifikate an wenigen Stellen betrieben werden und Verantwortlichkeiten eindeutig sind. In gewachsenen Umgebungen ist das selten der Fall. Zertifikate liegen auf unterschiedlichen Systemen, werden durch verschiedene Teams betreut und nutzen teils verschiedene Zertifizierungsstellen.

Mit kürzeren Laufzeiten steigt die Zahl der notwendigen Erneuerungen. Damit steigen auch die Risiken:

• Ein Zertifikat wird nicht im Inventar geführt.
• Der zuständige Dienst wurde migriert, aber die alte Dokumentation blieb bestehen.
• Die Erneuerung findet statt, das neue Zertifikat wird jedoch nicht auf dem Zielsystem aktiviert.
• Ein automatisierter Prozess scheitert an einer geänderten Firewall-, DNS- oder Berechtigungskonfiguration.
• Eine Zertifikatskette wird unvollständig ausgeliefert.
• Ein externer Dienst nutzt weiterhin ein altes Zertifikat oder einen alten privaten Schlüssel.
• Warnungen erreichen ein unbetreutes Postfach.

Die technische Verschlüsselung allein genügt nicht. Entscheidend ist der gesamte Lebenszyklus: beantragen, ausstellen, bereitstellen, überwachen, erneuern, widerrufen und dokumentieren. Grundlagen für die sichere Segmentierung und Absicherung der beteiligten Systeme findest du auch in unserem Beitrag Netzwerksicherheit: Grundlagen für den Schutz.

Zuerst das Zertifikatsinventar aufbauen

Bevor du Automatisierung einführst, musst du wissen, welche Zertifikate tatsächlich im Einsatz sind. Ein Inventar ist keine einmalige Excel-Liste, sondern eine gepflegte Datenbasis für Betrieb, Security und Störungsbearbeitung.

Erfasse sowohl öffentlich vertrauenswürdige als auch interne Zertifikate. Öffentliche Zertifikate schützen typischerweise Dienste mit Internetzugang. Interne Zertifikate werden etwa für Verwaltungsoberflächen, interne APIs, Verzeichnisdienste, Geräteverwaltung oder mTLS-Verbindungen eingesetzt. Beide Gruppen können Ausfälle verursachen, unterscheiden sich aber oft bei Zertifizierungsstelle, Erneuerungsprozess und Vertrauenskette.

Für jedes Zertifikat sollte das Inventar mindestens diese Informationen enthalten:

Information	Zweck
DNS-Namen und Subject Alternative Names	Betroffene Domains und Dienste erkennen
Ausstellende Zertifizierungsstelle	Erneuerungsweg und Vertrauenskette bestimmen
Ablaufdatum	Fristen überwachen
System und Endpunkt	Installationsort eindeutig zuordnen
Technischer und fachlicher Eigentümer	Verantwortlichkeiten klären
Erneuerungsmethode	Manuell, ACME oder Plattformprozess unterscheiden
Speicherort des privaten Schlüssels	Schlüssel schützen und Rotation planen
Kritikalität des Dienstes	Warnungen und Reaktionen priorisieren
Letzter erfolgreicher Erneuerungslauf	Automatisierung nachvollziehen

Beginne mit extern erreichbaren Domains, weil sie meist geschäftskritisch und gut auffindbar sind. Ergänze anschließend interne DNS-Zonen, Load Balancer, Container-Plattformen, API-Gateways, Mailserver, VPN-Systeme, Appliances und SaaS-Integrationen. Prüfe auch Zertifikate, die nicht für HTTPS genutzt werden, etwa für SMTP, LDAP, RDP-Gateways oder Client-Authentisierung.

Wichtig ist die Unterscheidung zwischen Zertifikat und Dienst. Ein Zertifikat kann mehrere Namen enthalten. Umgekehrt kann ein Dienst mehrere Zertifikate verwenden, etwa für verschiedene Mandanten oder Fallback-Konfigurationen. Dokumentiere daher immer die konkrete Zuordnung.

ACME verstehen und passend einsetzen

ACME steht für Automated Certificate Management Environment. Das Protokoll ermöglicht es, Zertifikate automatisiert bei einer unterstützten Zertifizierungsstelle anzufordern und zu erneuern. Statt dass Mitarbeitende Zertifikatsanfragen manuell erstellen, Dateien herunterladen und auf Server kopieren, übernimmt ein ACME-Client diese Schritte nach definierten Regeln.

Der Client weist dabei nach, dass er die Kontrolle über eine Domain besitzt. Dafür kommen verschiedene Challenge-Verfahren infrage:

• HTTP-01: Der ACME-Client stellt eine Prüfdatei über eine definierte URL bereit. Das eignet sich gut für öffentlich erreichbare Webdienste.
• DNS-01: Der Client setzt einen speziellen DNS-TXT-Eintrag. Dieses Verfahren ist für Wildcard-Zertifikate erforderlich und hilfreich, wenn kein Webserver direkt erreichbar ist.
• TLS-ALPN-01: Der Nachweis erfolgt über eine spezielle TLS-Verbindung. Das Verfahren kann in bestimmten Proxy- und Webserver-Szenarien sinnvoll sein.

Die Auswahl ist keine reine Komfortfrage. HTTP-01 benötigt einen von außen erreichbaren Webpfad. DNS-01 verlangt kontrollierten Zugriff auf die DNS-Verwaltung. Gerade dort entstehen Risiken, wenn ein ACME-Client weitreichende Rechte für die gesamte Zone erhält.

Unser Rat: Gib dem Automatisierungskonto nur die Rechte, die für die benötigten DNS-Einträge notwendig sind. Nutze getrennte Konten oder Tokens pro Zone und Umgebung. Speichere Zugangsdaten nicht im Repository und nicht unverschlüsselt in Deployment-Skripten. Für automatisierte Prozesse gelten dieselben Grundsätze wie für andere Maschinenidentitäten. Besonders bei API-Zugängen und Secrets helfen klare Verantwortlichkeiten und minimale Berechtigungen.

Wildcard-Zertifikate können die Anzahl einzelner Zertifikate reduzieren, erhöhen aber die Tragweite eines kompromittierten privaten Schlüssels. Sie sind deshalb nicht automatisch die beste Wahl. Häufig sind einzelne Zertifikate pro Dienst oder klar abgegrenzte Namensräume sicherer und besser nachvollziehbar.

Die Automatisierung sicher einführen

Starte nicht sofort mit allen produktiven Diensten. Wähle zunächst einen überschaubaren, aber realistischen Dienst aus, beispielsweise einen Reverse Proxy in einer Testumgebung. Ziel ist ein vollständiger Ablauf: Ausstellung, sichere Ablage, Installation, Reload des Dienstes, Prüfung und Monitoring.

Ein belastbarer Einführungsplan sieht so aus:

• Lege für jeden Dienst einen verantwortlichen Eigentümer fest.
• Entscheide je Zertifikat, welches Challenge-Verfahren verwendet wird.
• Richte ACME-Konten getrennt nach Umgebung und Zuständigkeit ein.
• Lege private Schlüssel in einem geschützten Speicher ab.
• Automatisiere die Bereitstellung auf dem Zielsystem.
• Führe nach der Bereitstellung einen kontrollierten Reload oder eine Konfigurationsprüfung aus.
• Prüfe den extern und intern ausgelieferten Zertifikatsstand.
• Dokumentiere Fehlerwege, Rückfallverfahren und Kontaktpersonen.
• Überführe den Dienst erst nach erfolgreichen Tests in den Regelbetrieb.

Die Erneuerung allein reicht nicht aus. Ein neues Zertifikat im Dateisystem hilft nicht, wenn der Webserver weiterhin die alte Version im Speicher verwendet. Plane deshalb einen sicheren Reload ein und prüfe anschließend aktiv, welches Zertifikat am tatsächlichen Endpunkt ausgeliefert wird.

Bei Container- und Plattformumgebungen gehört die Zertifikatsbereitstellung in die regulären Deployment-Prozesse. Vermeide manuelle Kopiervorgänge in laufende Container. Nutze dafür zentrale Secrets-Mechanismen, Ingress-Controller oder die vorgesehenen Funktionen deiner Plattform. So bleibt nachvollziehbar, welche Konfiguration wann aktiv war.

Monitoring muss unabhängig von ACME funktionieren

Ein erfolgreicher ACME-Job ist kein Beweis dafür, dass Nutzerinnen und Nutzer einen funktionierenden Dienst erreichen. Deshalb brauchst du zusätzlich ein unabhängiges Monitoring, das die reale Verbindung prüft.

Überwache mindestens:

• Restlaufzeit des ausgelieferten Zertifikats
• Erreichbarkeit über den vorgesehenen Hostnamen
• Gültigkeit der Zertifikatskette
• Übereinstimmung des DNS-Namens mit dem Zertifikat
• Erfolg oder Fehler der automatisierten Erneuerung
• Änderungen an Zertifikatsaussteller oder Fingerprint
• Ablaufdaten interner Zertifikate und Zwischenzertifikate

Definiere Warnschwellen, die ausreichend Zeit für Analyse und Korrektur lassen. Entscheidend ist nicht nur die erste Warnung, sondern ein klarer Eskalationsweg. Wenn ein kritisches Zertifikat kurz vor Ablauf steht, muss eine verantwortliche Person die Meldung tatsächlich bearbeiten können. Sende Warnungen nicht ausschließlich an eine allgemeine Mailadresse ohne verbindliche Betreuung.

Wie du technische Signale sinnvoll in Betriebsprozesse überführst, erläutern wir auch in Angriffe früh erkennen: Logging und Monitoring. Zwar geht es bei ablaufenden Zertifikaten meist nicht um einen Angriff, aber die Prinzipien für zuverlässige Erkennung, Alarmierung und Reaktion sind dieselben.

Notfallplan für Zertifikatsausfälle vorbereiten

Auch mit guter Automatisierung können Ausfälle auftreten, etwa durch DNS-Probleme, abgelaufene API-Tokens, fehlerhafte Berechtigungen oder Störungen bei einer Zertifizierungsstelle. Für kritische Dienste sollte daher ein dokumentierter Notfallplan existieren.

Kläre vorab:

• Wer darf ein Ersatzzertifikat beantragen und installieren?
• Wo liegen gesicherte Zugänge zu DNS, Load Balancer und Zielsystem?
• Wie wird ein Zertifikat im Störungsfall schnell ausgerollt?
• Wie prüfst du, ob alle Knoten eines Clusters das neue Zertifikat ausliefern?
• Wie informierst du Fachbereiche, Support und betroffene Kundinnen und Kunden?
• Wann muss ein Zertifikat widerrufen und ein privater Schlüssel ersetzt werden?

Wenn ein Zertifikat abläuft, zählt jede Minute. Wenn ein privater Schlüssel kompromittiert sein könnte, ist die Lage ernster: Dann müssen Erneuerung, Schlüsselwechsel und gegebenenfalls Widerruf koordiniert erfolgen. Solche Abläufe gehören in die allgemeine Störungsorganisation. Praktische Grundlagen dazu findest du in Incident Response: was tun im Ernstfall.

Zertifikatsmanagement als dauerhaften Prozess etablieren

Automatisierung reduziert Handarbeit, ersetzt aber keine Verantwortung. Prüfe dein Inventar regelmäßig, kontrolliere Berechtigungen für DNS und ACME-Konten und teste den Erneuerungsprozess nach Änderungen an Infrastruktur, Netzwerk oder Deployment.

Behandle Zertifikate außerdem als Teil deiner gesamten TLS-Strategie. Dazu gehören sichere Protokollversionen, passende Cipher Suites, geschützte private Schlüssel und eine geplante Migration kryptografischer Verfahren. Gerade bei langfristigen Infrastrukturentscheidungen lohnt sich der Blick auf unseren Beitrag Post-Quantum-Kryptografie im Unternehmen vorbereiten: Krypto-Inventar und TLS-Migration planen.

Wenn du Zertifikatsinventar, ACME-Automatisierung, unabhängiges Monitoring und Notfallabläufe verbindest, werden kürzere Laufzeiten beherrschbar. Statt auf den nächsten Ablaufalarm zu reagieren, schaffst du einen wiederholbaren Prozess, der Dienste zuverlässig erreichbar und TLS-Verbindungen vertrauenswürdig hält. Passende Seminare und Termine findest du bei uns auf cmt.de.