Certbot hat das Zertifikat erneuert, aber Nginx liefert noch das alte aus

1. Das Zertifikat auf der Festplatte prüfen

Listen Sie auf dem Nginx-Host die von Certbot verwalteten Zertifikate auf. Verwenden Sie den angezeigten Certificate Name. Er kann vom Domainnamen abweichen, etwa example.com-0001. Lesen Sie das Serverzertifikat aus diesem Verzeichnis und notieren Sie SHA-256-Fingerabdruck, Seriennummer und Gültigkeitsdaten. Kopieren Sie den privaten Schlüssel niemals in einen Diagnosebericht.

sudo certbot certificates
sudo openssl x509 \
  -in /etc/letsencrypt/live/example.com/cert.pem \
  -noout -sha256 -fingerprint -serial -dates

Ein erfolgreicher Aufruf von certbot renew beweist keine Erneuerung: Der Befehl ist auch erfolgreich, wenn noch kein Zertifikat erneuert werden muss. Ein dry run prüft die Erneuerung über den Testdienst und ersetzt das Produktionszertifikat nicht.

2. Eine neue TLS-Verbindung von außen prüfen

Führen Sie diesen Befehl auf einem anderen Rechner außerhalb des Hosting-Netzes aus. Der Hostname wird zusätzlich als SNI übertragen, damit der Server den passenden virtuellen Host auswählt. Der Befehl zeigt das präsentierte Zertifikat an; er prüft weder das Vertrauen in die Zertifikatskette noch die Übereinstimmung des Hostnamens.

set -o pipefail
openssl s_client -connect example.com:443 \
  -servername example.com </dev/null |
  openssl x509 -noout -sha256 -fingerprint -serial -dates

Vergleichen Sie die SHA-256-Fingerabdrücke, nicht nur die Gültigkeitsdaten. Stimmen sie überein, hat diese Verbindung das Zertifikat von der Festplatte erhalten. Eine Abweichung zeigt ein anderes Zertifikat, beweist aber noch keinen fehlgeschlagenen Nginx-Reload. Schlägt die Verbindung fehl oder wird kein Zertifikat angezeigt, untersuchen Sie zuerst diesen Fehler.

3. Den TLS-Endpunkt prüfen und Nginx neu laden

Prüfen Sie die wirksame Konfiguration lokal mit sudo nginx -T. Suchen Sie für den Hostnamen die Direktiven server_name, listen, ssl_certificate und ssl_certificate_key. Die Ausgabe kann Geheimnisse enthalten und sollte nicht veröffentlicht werden. Bei Certbot endet der übliche Zertifikatspfad auf live/<certificate-name>/fullchain.pem. Ein alter archive-Pfad oder eine Dateikopie wird bei einer Erneuerung nicht automatisch aktualisiert.

sudo nginx -t && sudo systemctl reload nginx

Wenn systemd Nginx auf diesem Host verwaltet, prüfen Sie vor dem Neuladen die Konfiguration. Schlägt einer der Befehle fehl, lesen Sie das Dienstjournal und das Nginx-Fehlerprotokoll. Wiederholen Sie anschließend die externe Prüfung mit einer neuen Verbindung und vergleichen Sie die Fingerabdrücke. Erneuerung und erfolgreiche Bereitstellung müssen getrennt geprüft werden.

4. Das Neuladen in die Bereitstellung aufnehmen

Wenn Sie certonly mit Webroot- oder DNS-Validierung verwenden und Nginx selbst konfigurieren, können Sie nach erfolgreicher Erneuerung einen Deploy-Hook ausführen. Speichern Sie das folgende Skript auf einer üblichen Linux-Installation ausführbar unter /etc/letsencrypt/renewal-hooks/deploy/reload-nginx. Prüfen Sie die Programmpfade auf Ihrem Host und testen Sie das Skript mit sudo. Der Nginx-Installer von Certbot kann die Bereitstellung bereits übernehmen. Prüfen Sie die bestehende Einrichtung, bevor Sie einen zweiten Mechanismus ergänzen.

#!/bin/sh
set -eu
/usr/sbin/nginx -t
/usr/bin/systemctl reload nginx

Certbot renew --dry-run führt Deploy-Hooks standardmäßig nicht aus. Mit --run-deploy-hooks werden sie beim Test ausgeführt; dabei kann der produktive Dienst mit dem aktiven Zertifikat neu geladen werden. Planen Sie diesen Test bewusst. Wiederholte Aufrufe mit --force-renewal helfen nicht bei der Diagnose eines Bereitstellungsfehlers.

5. Die Abweichung lokal nachstellen

Das herunterladbare Bash-Skript startet einen isolierten Nginx-Container, der nur über 127.0.0.1 auf einem automatisch vergebenen Port erreichbar ist. Es erstellt zwei selbstsignierte Zertifikate für renewal.test, ersetzt die Dateien und vergleicht den ausgelieferten Fingerabdruck vor und nach dem Neuladen. Es simuliert den Dateiaustausch, keine ACME-Ausstellung. Voraussetzungen: Linux, ein lokaler Docker-Daemon und OpenSSL. Docker lädt bei Bedarf das festgelegte Nginx-Image herunter.

Demonstrationsskript herunterladen und prüfen

Lesen Sie die heruntergeladene Datei und starten Sie bash nginx-certificate-reload.sh ohne sudo, sofern Ihre Docker-Konfiguration dies erlaubt. BEFORE und SERVED müssen übereinstimmen, DISK muss abweichen. AFTER muss DISK entsprechen. Das Skript prüft diese Bedingungen und entfernt beim Beenden seinen Container und seine temporären Schlüssel. Ihr Nginx-Dienst bleibt unverändert.

6. Weitere Verbindungen prüfen und dauerhaft überwachen

Ein CDN darf ein anderes Zertifikat ausliefern als der Ursprungsserver. Prüfen Sie beide TLS-Verbindungen getrennt. Bei mehreren Backends oder IPv4/IPv6 prüfen Sie jede relevante Adresse mit demselben SNI-Hostnamen. Eine erfolgreiche Prüfung deckt nicht alle Server, Netzwerkpfade oder Besucher ab. Bei getrennten RSA- und ECDSA-Zertifikaten vergleichen Sie das Zertifikat, das zum jeweiligen Handshake gehört. Ersetzen Sie im folgenden Beispiel 192.0.2.10 durch die Adresse, die Sie prüfen dürfen. Verwenden Sie für IPv6 [Adresse]:443 bei -connect.

openssl s_client -connect 192.0.2.10:443 \
  -servername example.com </dev/null |
  openssl x509 -noout -sha256 -fingerprint -serial -dates

Nocert beobachtet regelmäßig die Zertifikate erreichbarer TLS-Endpunkte und wertet Ablaufwarnregeln in einem täglichen Zyklus aus. Prüfen Sie den Endpunkt und den Beobachtungszeitpunkt und konfigurieren Sie die Empfänger der Ablaufwarnungen. Diese Überwachung ergänzt die unmittelbare externe Prüfung. Sie stellt keine Zertifikate aus, lädt Nginx nicht neu und bestätigt nicht die erfolgreiche Bereitstellung jeder Certbot-Erneuerung.