So sieht die Meldung aus
curl: (60) SSL certificate problem: certificate has expiredHäufige Ursachen
- Automatische Erneuerung ist gescheitert, z. B. Port 80 gesperrt oder DNS geändert.
- Zertifikat wurde erneuert, nginx, Postfix oder Dovecot aber nicht neu geladen.
- Timer oder Cronjob für certbot existiert nicht (mehr), etwa nach einer Migration.
- Zertifikat wurde manuell kopiert und liegt außerhalb von
/etc/letsencrypt/live. - Die Uhr des Clients steht falsch – dann wirkt auch ein gültiges Zertifikat abgelaufen.
Prüfen
- Gültigkeit des tatsächlich ausgelieferten Zertifikats anzeigen
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates - Ablaufdaten der certbot-Zertifikate anzeigen
certbot certificates 2>/dev/null | grep -E 'Certificate Name|Expiry' - Prüfen, ob der Erneuerungs-Timer aktiv ist
systemctl list-timers | grep -i certbot - Erneuerung testen, ohne echte Zertifikate zu holen
certbot renew --dry-run
Lösung
- Sofort erneuern:
certbot renewund den Dienst neu laden. - Reload dauerhaft einbauen:
--deploy-hook 'systemctl reload nginx'bzw. ein Skript in/etc/letsencrypt/renewal-hooks/deploy/. - Fehler aus
certbot renew --dry-runbeheben, typischerweise Firewall, DNS oder geänderte vHosts. - Ablaufdaten überwachen – eine Warnung 14 Tage vor Ablauf reicht.
- Bei Mailservern daran denken: Postfix und Dovecot brauchen ebenfalls einen Reload.
Häufige Fragen
Warum ist das Zertifikat abgelaufen, obwohl certbot erneuert hat?
Der Dienst hält das alte Zertifikat im Speicher. Ohne Reload liefert nginx weiter die alte Version aus, auch wenn die Datei auf der Platte neu ist.
Kann ein Zwischenzertifikat ablaufen?
Ja. Liefert der Server eine veraltete Kette aus, scheitern Clients trotz gültigem Serverzertifikat. Nutzen Sie immer die aktuelle fullchain.pem.