Abgelaufene SSL/TLS-Zertifikate gehören zu den häufigsten und gleichzeitig vermeidbarsten Ursachen für Website-Ausfälle und Browser-Sicherheitswarnungen. Wenn ein Zertifikat abläuft, zeigen Browser sofortige Fehlermeldungen, APIs verweigern Verbindungen, und Monitoring-Systeme lösen Alarme aus – oft zu einem Zeitpunkt, zu dem schnelles Handeln unter Druck stattfinden muss. Die Ursache ist dabei fast immer dieselbe: Das Ablaufdatum war bekannt, aber kein automatisierter Prozess hat rechtzeitig gehandelt.
Dieser Artikel zeigt, wie IT-Teams Zertifikatsablauffristen systematisch überwachen, frühzeitig Alerts konfigurieren und Zertifikatsverlängerungen zuverlässig automatisieren – damit Zertifikatsprobleme zur gelösten Kategorie werden, nicht zur Ursache für Nachtalarme.
Warum Zertifikate ablaufen – obwohl alle es wussten
In den meisten Fällen überrascht ein abgelaufenes Zertifikat niemanden wirklich – das Ablaufdatum steht im Zertifikat selbst. Die eigentlichen Ursachen für übersehene Abläufe sind meist organisatorischer Natur:
- Zertifikate wurden einmalig manuell ausgestellt und manuell erneuert, ohne strukturierte Nachverfolgung
- Verantwortlichkeiten sind unklar – niemand fühlt sich zuständig
- Monitoring deckt interne Dienste und APIs nicht explizit ab
- Zertifikate auf internen Microservices, Mail-Servern oder Admin-Interfaces werden vergessen
- Teamwechsel: Die Person, die das Zertifikat kennt und verwaltet, ist nicht mehr im Unternehmen
Der erste Schritt ist daher nicht Automatisierung, sondern Inventarisierung: Welche Zertifikate existieren, wo laufen sie, wann laufen sie ab, und wer ist zuständig?
Monitoring von Ablauffristen: Der erste Schutzwall
Bevor Automatisierung greift, braucht es verlässliches Monitoring. Zertifikat-Monitoring prüft regelmäßig die erreichbaren HTTPS-Endpunkte und erfasst dabei:
- Verbleibende Laufzeit in Tagen bis zum Ablauf
- Zertifikat-Issuer und Zertifikatskette (vollständig oder gebrochen?)
- Hostname-Übereinstimmung (Common Name und Subject Alternative Names)
- Verwendete TLS-Protokollversion (TLS 1.2 vs. 1.3)
- HSTS-Header und weitere Sicherheitskonfigurationen
Monitoring-Systeme wie FreshCore prüfen HTTPS-Endpunkte aktiv und ermöglichen Ablauf-Alerts mit konfigurierbaren Schwellenwerten. Die Empfehlung: Alerts in drei Eskalationsstufen staffeln:
- 30 Tage vor Ablauf: Info-Alert – ausreichend Zeit für geplante Erneuerung ohne Stress
- 14 Tage vor Ablauf: Warning-Alert – Eskalation, wenn die Erneuerung noch nicht eingeleitet wurde
- 7 Tage vor Ablauf: Kritischer Alert – sofortige Handlung erforderlich, On-Call informieren
Wichtig: Nicht nur externe, öffentlich erreichbare Domains überwachen. Interne APIs, Microservices, Mail-Server, VPN-Endpunkte und Admin-Interfaces verwenden ebenfalls TLS – und werden in der Praxis häufig vergessen.
Let's Encrypt und das ACME-Protokoll: Automatische Erneuerung als Standard
Let's Encrypt hat die Zertifikatsverwaltung grundlegend verändert. Das ACME-Protokoll (Automatic Certificate Management Environment, RFC 8555) ermöglicht vollautomatische Zertifikatsausstellung und -erneuerung über Domain-Validierung – kostenlos und ohne manuelle Eingriffe.
Let's Encrypt-Zertifikate laufen nach 90 Tagen ab – dieser kurze Zeitraum ist absichtlich gewählt, um Automatisierung zu erzwingen und die Risiken aus kompromittierten Zertifikaten zu begrenzen.
Weit verbreitete ACME-Clients für die Automatisierung:
- Certbot: Der Referenz-Client von Let's Encrypt, unterstützt Apache, Nginx und eigenständigen Betrieb
- acme.sh: Shell-basiert, sehr flexibel, unterstützt zahlreiche DNS-Provider für DNS-01-Challenges
- Caddy: Webserver mit nativem ACME-Support – Zertifikate werden automatisch ausgestellt, erneuert und installiert
- Traefik: Reverse-Proxy mit integriertem ACME-Support für container-basierte Umgebungen
Für neue Projekte sollte heute die Frage nicht mehr lauten, ob Let's Encrypt eingesetzt wird, sondern welcher ACME-Client am besten zur Infrastruktur passt.
Automatisierung in der Pipeline: Zertifikate als Code
Für Teams, die Infrastruktur als Code verwalten, empfiehlt sich die Zertifikatsverwaltung direkt in IaC-Workflows zu integrieren.
cert-manager in Kubernetes
In Kubernetes-Umgebungen ist cert-manager der de-facto-Standard für automatisches Zertifikat-Management. Zertifikate werden als Kubernetes Custom Resources (Certificate-Objekte) deklarativ definiert, cert-manager übernimmt die Ausstellung und Erneuerung über ACME oder andere Issuers (z.B. interne CAs). TLS-Secrets werden automatisch aktualisiert und von Ingress-Controllern direkt genutzt. Keine manuellen Schritte nach der initialen Konfiguration.
Terraform mit ACME-Provider
Der Terraform ACME Provider ermöglicht es, Let's Encrypt-Zertifikate direkt in Terraform-Konfigurationen zu deklarieren. Bei jedem Apply-Zyklus wird geprüft, ob ein Zertifikat sich dem Ablauf nähert, und es wird bei Bedarf erneuert. Das erneuerte Zertifikat kann direkt in AWS Certificate Manager, Azure Key Vault oder andere Secrets-Stores geschrieben werden.
Managed Zertifikate bei Cloud-Providern
Moderne Cloud-Load-Balancer wie AWS ALB mit ACM, Cloudflare oder Azure Front Door verwalten Zertifikate vollständig selbst – inklusive automatischer Erneuerung. In diesen Umgebungen entfällt die Zertifikatsverwaltung auf Anwendungsebene komplett, vorausgesetzt, die DNS-Delegation und Domain-Validierung sind korrekt konfiguriert. Für Infrastruktur hinter diesen Diensten ist das der empfohlene Weg.
Wildcard-Zertifikate: Komfort mit Einschränkungen
Wildcard-Zertifikate (*.domain.de) decken alle Subdomains einer Ebene ab und reduzieren die Anzahl zu verwaltender Zertifikate erheblich. Sie erfordern für die ACME-Validierung jedoch ausschließlich DNS-01-Challenges – also programmatischen Schreibzugriff auf den DNS-Provider. Dabei gilt:
- DNS-API-Credentials sicher verwahren – in einem Secrets Manager, nicht in der Pipeline
- Scope des Wildcard-Zertifikats kennen: *.domain.de deckt nicht *.sub.domain.de
- Eine Kompromittierung des Wildcard-Zertifikats betrifft alle Subdomains gleichzeitig – Rotation erfordert koordinierten Einsatz
Fehlerbehandlung: Automatisierung braucht eigene Überwachung
Automatisierung kann scheitern: DNS-Validierungen schlagen fehl, Rate Limits von Let's Encrypt werden erreicht, oder der ACME-Server ist temporär nicht erreichbar. Deshalb braucht jede automatisierte Zertifikats-Pipeline eine eigene Überwachungsschicht – unabhängig von der Automatisierung selbst:
- Heartbeat-Monitoring für Erneuerungsjobs: Wenn der Cronjob oder Pipeline-Job nicht planmäßig meldet, schlägt das Monitoring an
- Log-basierte Alarmierung für fehlgeschlagene Erneuerungsversuche mit klaren Fehlermeldungen
- Paralleles Endpunkt-Monitoring bleibt aktiv, auch wenn Erneuerung automatisiert ist – als unabhängiger Kontrollpfad, der immer greift
Grundsatz: Automatisierung und Monitoring sind keine Alternativen – sie ergänzen sich. Das Monitoring überprüft das Ergebnis; die Automatisierung produziert es.
Fazit: Zertifikatsprobleme sind gelöste Probleme
Kein Zertifikat muss unerwartet ablaufen. Mit dreistufigen Monitoring-Alerts, ACME-basierter Automatisierung und konsequenter Pipeline-Integration ist die Zertifikatsverwaltung ein vollständig lösbares Problem. Der strukturierte Weg dorthin: erst inventarisieren, dann überwachen, dann automatisieren – und das Monitoring immer als unabhängige Kontrollschicht aktiv lassen.
Teams, die diesen Weg konsequent gehen, befreien sich von Nachtalarmen wegen abgelaufener Zertifikate – und gewinnen Zeit und Aufmerksamkeit für Aufgaben, die echte Expertise erfordern.
Bildquelle: Pexels.com – Foto von Christina Morillo
Quellen: Let's Encrypt – Getting Started (letsencrypt.org), ACME RFC 8555 (ietf.org), cert-manager Documentation (cert-manager.io), NIST TLS Guidelines SP 800-52 Rev. 2 (csrc.nist.gov)
