Let's-Encrypt-Auto-Renew-Fehler beheben
lets encrypt auto renew fehler · certbot renewal failed · acme challenge problem
Fehlgeschlagene Let's-Encrypt-Erneuerungen verstehen: ACME-Challenges, DNS-01, HTTP-01, Rate Limits und Nachprüfung mit SSL Checker.
Von DN01 Netzwerk-Team
Auto-Renew klingt wartungsfrei, bis eine Challenge nicht erreichbar ist und das Zertifikat kurz vor Ablauf steht. Für Besucher sieht das Ergebnis oft nur wie "Diese Verbindung ist nicht privat" aus, während Betreiber mehrere Schichten auseinanderhalten müssen: DNS-Ziel, Server Name Indication, Zertifikatskette, Gültigkeit, SAN-Namen, Protokollversion und Browser-Cache.
Der praktische Startpunkt ist der DN01 SSL Certificate Checker unter /de/ssl-certificate-checker. Er zeigt die öffentlich sichtbare TLS-Antwort einer Domain und hilft, Panel-Angaben, Load-Balancer-Konfiguration und Browserfehler gegen Live-Daten zu prüfen.
Dieser Leitfaden ist bewusst operativ geschrieben: erst eingrenzen, dann ändern, danach erneut messen. Verlinken Sie die relevanten SSL-Guides im Change-Ticket, damit Support, Hosting-Team und Entwickler nicht mit unterschiedlichen Annahmen arbeiten.
Wann dieser Check wichtig ist
Nutzen Sie den Guide bei Certbot-, acme.sh-, Plesk-, cPanel- oder Kubernetes-cert-manager-Fehlern, besonders wenn Domains hinter CDN, Redirects oder Firewalls liegen.
Besonders kritisch sind Änderungen, die nicht überall gleichzeitig sichtbar werden: DNS-Umzüge, neue CDN-Zonen, Ingress-Regeln in Kubernetes, Zertifikatswechsel auf mehreren Nodes oder parallele IPv4/IPv6-Pfade. Prüfen Sie deshalb nicht nur die Hauptdomain, sondern auch www, api, mail, staging und jede öffentlich verlinkte Subdomain.
Öffnen Sie /de/ssl-certificate-checker, testen Sie den Hostnamen ohne Pfad und dokumentieren Sie Zeitpunkt, IP-Ziel, Ablaufdatum, Aussteller und Kette. Bei DNS-Fragen ergänzt /de/dns-checker die Sicht auf A-, AAAA- und CNAME-Ziele; bei Security-Headern hilft /de/http-header-checker.
Schritt-für-Schritt prüfen
1. Domain im SSL Checker testen und zuerst den Hostnamen im Zertifikat mit der geprüften Domain vergleichen. 2. notBefore und notAfter lesen. 3. Intermediate-Zertifikate und Reihenfolge prüfen. 4. Ergebnis mit Browserfehler, Server-Config und Deploy-Zeitpunkt abgleichen.
Nach einem erfolgreichen Renewal unbedingt live prüfen. Entscheidend ist nicht die Meldung des ACME-Clients, sondern das notAfter-Datum am öffentlichen HTTPS-Endpunkt.
Wenn ein Ergebnis unerwartet ist, wiederholen Sie die Prüfung mit exakt demselben Hostnamen nach einem TTL-Zyklus und zusätzlich über den alternativen Namen, zum Beispiel example.com und www.example.com. Unterschiedliche Resultate deuten meist auf SNI, CDN, IPv6 oder einen nicht aktualisierten Backend-Knoten hin.
Häufige Fehler in der Praxis
HTTP-01 scheitert oft an Redirects, Basic Auth oder nicht erreichbaren /.well-known/acme-challenge-Pfaden. DNS-01 scheitert an falscher Zone, langsamer Propagation oder API-Rechten.
Ein weiterer Klassiker ist die Verwechslung von Zertifikat und HTTPS-Weiterleitung: Ein Redirect auf https://www.example.com hilft nicht, wenn https://example.com bereits vor dem Redirect mit falschem Zertifikat antwortet. Der TLS-Handshake passiert zuerst, die HTTP-Weiterleitung danach.
Verlassen Sie sich nicht nur auf Hosting-Panels. Panels zeigen oft das gespeicherte Zertifikat, nicht zwingend das Zertifikat, das der öffentliche Edge, Proxy oder Mail-Server gerade ausliefert.
Nützliche Querprüfungen
Lesen Sie im selben Cluster weiter: /de/guides/ssl/lets-encrypt-ssl-renewal-guide, /de/guides/ssl/ssl-zertifikat-erneuern-checkliste, /de/guides/ssl/dns-01-challenge-ssl-guide. Diese Guides decken angrenzende Ursachen ab und verhindern, dass ein Chain-Problem als DNS-Problem oder ein HSTS-Problem als Zertifikatsproblem behandelt wird.
Für Migrationen lohnt sich ein kleines Prüfprotokoll: alte IP, neue IP, geprüfter Hostname, Zertifikatsfingerprint, Ablaufdatum, Chain-Status, Browserfehler und verantwortlicher Dienst. Dieses Protokoll beschleunigt Eskalationen, weil Provider konkrete Live-Werte statt Screenshots aus lokalen Browsern bekommen.
Nach der Korrektur erneut mit dem SSL Checker prüfen und erst dann Caches, CDN-Purge oder HSTS-Änderungen ausrollen. So bleibt klar, welche Änderung den Fehler wirklich beseitigt hat.
| Beobachtung | Wahrscheinliche Ursache | Nächster Schritt |
|---|---|---|
| Browserfehler nur auf einer Subdomain | SAN-Name fehlt oder falscher vHost | Subdomain separat im SSL Checker prüfen |
| Mobil funktioniert, Desktop nicht | Kette oder Trust Store unterscheidet sich | Intermediate-Reihenfolge vergleichen |
| IPv6 liefert anderes Zertifikat | AAAA-Pfad zeigt auf alten Edge | DNS und Load Balancer gemeinsam prüfen |
| Fehler nach Renewal | Neues Zertifikat nicht auf allen Nodes aktiv | Fingerprint pro Edge/Backend vergleichen |
Häufig gestellte Fragen
- Wie oft erneuert Let's Encrypt?
Zertifikate sind meist 90 Tage gültig; viele Clients erneuern ab etwa 30 Tagen Restlaufzeit.
- Kann ein Renewal erfolgreich sein und trotzdem altes Cert ausliefern?
Ja, wenn Webserver, Proxy oder Load Balancer nicht neu geladen wurden.