Die Seite erscheint an einem Dienstag um 9:01 Uhr: „NET::ERR_CERT_DATE_INVALID“. Das letzte Let's Encrypt-Zertifikat ist um Mitternacht abgelaufen. Certbot läuft auf dem Server – Protokolle zeigen sechs Wochen lang HTTP-01-Fehler: Die Firewall hat Port 80 nach der Härtung geschlossen, und am Zertifikatsdatum hat niemand gewarnt, nur bei einem HTTP 443-Ping.
ACME automatisiert die Ausstellung – nicht die Governance. Eine erfolgreiche Erneuerung in certbot garantiert weder, dass das Zertifikat Besuchern zugestellt wird, noch dass eine Überwachung des tatsächlichen Ablaufs vorhanden ist.
ACME-Fluss und Haltepunkte
Der Standardzyklus:
- Der Agent (Certbot, Lego, integrierter Caddy) fordert eine Herausforderung an.
- Let's Encrypt validiert HTTP-01 oder DNS-01.
- Das Zertifikat wird ausgestellt; Der Agent installiert es und lädt den Webserver neu.
| Herausforderung | Anwendungsfälle | Häufiger Ausfall |
|---|---|---|
| HTTP-01 | VPS, öffentlicher Ursprung auf Port 80 | Port 80 geschlossen, Umleitungsschleife |
| DNS-01 | Platzhalter, privater Ursprung | Abgelaufenes oder falsch konfiguriertes DNS-API-Token |
Nutzen Sie die Staging-Umgebung von Let's Encrypt zum Testen – ohne Produktionskontingent zu verbrauchen.
Ein „erfolgreiches“ Erneuerungsprotokoll ohne „nginx -s reload“ lässt das alte Zertifikat aktiv – oder schlimmer noch, eine aktualisierte Datei, die der Server nicht liest.
Informationen zur wartbaren TLS-Konfiguration nach der Erneuerung finden Sie unter TLS konfigurieren.
Certbot-, Cron- und Bereitstellungs-Hooks
Überprüfen Sie unter Debian/Ubuntu, ob „certbot.timer“ systemd aktiv ist: „systemctl status certbot.timer“.
Fügen Sie einen Hook in „/etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh“ hinzu:
„Bash #!/bin/sh nginx -t && nginx -s neu laden
Synchronisieren Sie Zertifikate auf mehreren Servern oder koordinieren Sie das Neuladen pro Knoten nach der Erneuerung.
:::Hinweis
**Denken Sie daran.** Planen Sie einen monatlichen „certbot renew --dry-run“-Test mit Warnung, wenn der Exit-Code ungleich Null ist – dies ist die einzige Möglichkeit, eine fehlerhafte Challenge vor Ablauf zu erkennen.
:::
## Multi-Domäne, SAN und Wildcard
Ein SAN-Zertifikat deckt „www“ und apex ab – beide Namen müssen die Herausforderung bestehen. Ein Platzhalter „*.example.com“ erfordert DNS-01: Automatisieren Sie über die API oder das CDN Ihres Registrars (Cloudflare, OVH usw.).
Wenn Sie eine Host-Migration durchführen, führen Sie eine erneute Ausgabe aus, **bevor** Sie den alten Ursprung ausschneiden – lassen Sie eine Überlappung von 48 Stunden zu.
Vergleichen Sie [Let's Encrypt oder kostenpflichtiges Zertifikat](/de/blog/letsencrypt-ou-certificat-payant/) entsprechend Ihren B2B- oder erweiterten Validierungsbeschränkungen.
## Ablaufüberwachung
Implementieren Sie mindestens:
- „ssl_exporter“-Probe mit Warnung „days_until_expiry < 21“.
- Blackbox-Prüfung bei tatsächlicher TLS-Verbindung
- Inventar der X.509-Daten nach Produktionsdomäne
Trennen Sie die **Erneuerungsfehler**-Warnung (Certbot-Protokolle) von der **Ablaufwarnung** (dem Browser angezeigtes Zertifikat). SSL Labs ersetzt keine Prometheus-Warnung oder einen Cron, der „Certbot-Zertifikate“ liest.
Wenn ein CDN TLS vor dem Ursprung beendet, befolgen Sie **zwei Daten**: Edge-Zertifikat und Ursprungszertifikat.
## Verwaltete Hosts und integriertes ACME
Die Panels (Plesk, cPanel, Infomaniak-Manager) verwalten Let’s Encrypt häufig nativ – überprüfen Sie, ob die automatische Verlängerung aktiviert ist und die Administrator-E-Mail-Adresse aktuell ist.
## Der Gipfel: Automatisierung ohne Regelkreis
Folgendes vergessen wir, wenn wir certbot ein für alle Mal installieren.
:::Höhepunkt
**ACME hat den manuellen Aufwand beim Kauf eines Zertifikats beseitigt – nicht das Risiko eines Ablaufs.** Bis jemand das Datum des dem Browser **präsentierten** Zertifikats misst und die Erneuerung im Probelauf überprüft, verlassen Sie sich auf eine Automatisierung, die eine vergessene Firewall oder ein vergessenes DNS vierzig Tage lang stillschweigend deaktivieren kann.
:::
Die Überwachung der Erneuerung umfasst einen Trockenlauf plus Ablaufüberwachung plus Reload-Hook – nicht nur die Installation von Certbot.
## Entscheide dich und gehe ohne blinden Fleck voran
In einem halben Tag können Sie die ACME-Schleife schließen:
1. **Überprüfen** Sie, ob der Certbot-Timer oder Cron aktiv und dokumentiert ist.
2. **Fügen** Sie einen Reload-Hook nach der Erneuerung hinzu, der unter realen Bedingungen getestet wurde.
3. **Planen** Sie einen monatlichen Probelauf mit Benachrichtigung im Fehlerfall.
4. **Konfigurieren** Sie eine 21-tägige Ablaufwarnung für das **bereitgestellte** Zertifikat, nicht nur auf der Festplatte.
5. **Dokumentieren** Sie die Challenge-Abhängigkeiten (Port 80, DNS-API, Firewall-Whitelist).
6. **Schreiben** Sie ein Runbook mit „abgelaufenem Zertifikat“: erzwungene Erneuerung, Neuladen, Kettenprüfung.
Vergleichen Sie Hosts mit integriertem Let's Encrypt über das [Verzeichnis](/de/verzeichnis/) und den [Vergleich](/de/vergleich/).
## Häufig gestellte Fragen
### Wie oft verlängert sich Let's Encrypt?
Zertifikate gültig für 90 Tage; automatische Versuche ca. 30 Tage vor Ablauf. Der systemd-Cron oder Timer sollte überprüft werden – dies erfolgt nicht automatisch bei allen Installationen.
### HTTP-01 oder DNS-01?
HTTP-01, wenn Port 80 öffentlich und stabil ist. DNS-01 für Wildcard, privaten Ursprung oder komplexes Routing – mit automatisierter DNS-API und überwachten Token.
### Wie kann der Ablauf überwacht werden?
Benachrichtigung über das Datum, an dem das Zertifikat den Kunden vorgelegt wird, innerhalb von 21 Tagen. Komplett mit einem monatlichen Trockenlauf. Die E-Mail von Let's Encrypt allein reicht nicht aus.
### Erneuerung in Ordnung, aber TLS-Site defekt?
Das Neuladen des Webservers nach der Erneuerung fehlt oft. Automatisieren Sie den Bereitstellungs-Hook und testen Sie ihn nach jeder Konfigurationsänderung.
---
Let's Encrypt erneuert sich oft – Ihr Stack muss nachweisen, dass er das richtige Zertifikat rechtzeitig bereitstellt.