acme.sh hat das Zertifikat erneuert, aber Nginx liefert noch das alte

1. Den Zertifikatseintrag für die Erneuerung finden

Listen Sie die Zertifikate auf und prüfen Sie den betreffenden Eintrag. Ersetzen Sie example.com durch den Hauptnamen des Zertifikats. Die Beispiele mit --ecc wählen ein ECC-Zertifikat. Lassen Sie diese Option bei einem RSA-Eintrag in den Befehlen weg. Verwenden Sie eigene Pfade für --home, --config-home oder --cert-home, behalten Sie diese in jedem Befehl bei, damit Sie die richtige Installation abfragen.

"$HOME/.acme.sh/acme.sh" --list
"$HOME/.acme.sh/acme.sh" --info -d example.com --ecc

Prüfen Sie Le_RealKeyPath, Le_RealFullChainPath und Le_ReloadCmd sowie die Angaben zu Ausstellung und Erneuerung. Halten Sie diese Ausgabe vertraulich: Konfiguration und Befehle können sensible Werte enthalten. Prüfen Sie Konto, Zeitplan und Protokolle des Erneuerungsjobs. Eine fehlgeschlagene Ausstellung erfordert eine eigene Diagnose. Ein gültiges neues Zertifikat mit einem Installationsfehler ist kein Grund, wiederholt eine Erneuerung zu erzwingen.

2. Die Zieldateien mit den Nginx-Pfaden abgleichen

Verwenden Sie eigene Zieldateien für Nginx. Das interne Arbeitsverzeichnis von acme.sh ist keine stabile Schnittstelle für die Bereitstellung. Prüfen Sie die Pfade in der aktiven Serverkonfiguration und gegebenenfalls die Container-Mounts. Dieser Ausschnitt gehört in einen vorhandenen HTTPS-Serverblock.

ssl_certificate     /etc/nginx/tls/example.com/fullchain.pem;
ssl_certificate_key /etc/nginx/tls/example.com/key.pem;

Lesen Sie das öffentliche Zertifikat am konfigurierten Ziel und notieren Sie SHA-256-Fingerabdruck, Gültigkeitsdaten und SANs. In der vollständigen Kette steht zuerst das Serverzertifikat, danach folgen die Zwischenzertifikate.

openssl x509 -in /etc/nginx/tls/example.com/fullchain.pem \
  -noout -sha256 -fingerprint -issuer -dates -ext subjectAltName

Eine aktuelle interne acme.sh-Datei beweist nicht, dass die Zieldatei aktualisiert wurde. Eine aktuelle Zieldatei beweist nicht, dass Nginx sie geladen hat. Halten Sie den privaten Schlüssel geheim und stellen Sie sicher, dass der ladende Prozess die nötigen Zugriffsrechte besitzt.

3. Die richtigen Pfade und den Reload-Befehl speichern

Der folgende Befehl ändert die Dateien sofort und lädt Nginx neu. Prüfen Sie vorher die Ziele und den Zertifikatseintrag. Bereiten Sie das Zielverzeichnis mit passendem Eigentümer und passenden Berechtigungen vor. Das Konto, unter dem acme.sh läuft, muss die Dateien schreiben und den Reload-Befehl ohne Benutzereingriff ausführen können.

"$HOME/.acme.sh/acme.sh" --install-cert -d example.com --ecc \
  --key-file /etc/nginx/tls/example.com/key.pem \
  --fullchain-file /etc/nginx/tls/example.com/fullchain.pem \
  --reloadcmd "/usr/sbin/nginx -t && /usr/bin/systemctl reload nginx"

Passen Sie die absoluten Programmpfade und die systemd-Unit an. Durch && wird nur nach erfolgreichem nginx -t neu geladen. acme.sh speichert Ziele und Befehl für spätere Erneuerungen. Eigentümer und Berechtigungen bestehender Zieldateien bleiben erhalten. Prüfen Sie Rückgabecode und Protokolle: Nach einem fehlgeschlagenen Reload können die neuen Dateien auf dem Datenträger liegen, während weiter das alte Zertifikat ausgeliefert wird. Beheben Sie die Ursache und führen Sie --install-cert mit den vorgesehenen Parametern erneut aus. Bei Containern muss der Befehl den zuständigen Nginx-Prozess erreichen, nicht einen gleichnamigen Dienst auf dem Host.

4. Das über TLS empfangene Zertifikat prüfen

Öffnen Sie außerhalb des Hosting-Netzes eine neue TLS-Verbindung zu einem Dienst, den Sie betreiben oder prüfen dürfen. Behalten Sie den Hostnamen als SNI bei und vergleichen Sie den Fingerabdruck mit der Zieldatei. Der Befehl zeigt das Zertifikat; er validiert weder das Vertrauen in die Kette noch die Übereinstimmung des Hostnamens.

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

Weichen die Fingerabdrücke ab, ermitteln Sie die Komponente, die TLS terminiert. Ein CDN oder Load Balancer kann ein eigenes Zertifikat ausliefern. Prüfen Sie die relevanten öffentlichen Adressen und Zugänge zum Ursprung. Verwenden Sie IP:443 oder [IPv6]:443 mit -connect und behalten Sie den Hostnamen in -servername bei. Mehrere Replikate oder RSA/ECDSA-Zertifikate können unterschiedliche Beobachtungen ergeben. Wird das erwartete Zertifikat ausgeliefert, aber vom Browser abgelehnt, prüfen Sie Kette und abgedeckte Namen.

5. Einen fehlgeschlagenen Reload lokal nachstellen

Das Skript führt den tatsächlichen Befehl acme.sh --install-cert mit temporären selbstsignierten Testzertifikaten aus. Nginx liefert zunächst das alte Zertifikat. Ein absichtlich fehlschlagender Reload-Befehl lässt acme.sh die neuen Dateien kopieren, liefert aber einen Fehler zurück. Eine zweite Installation mit funktionierendem Reload-Befehl führt dazu, dass Nginx das neue Zertifikat ausliefert.

acme.sh-Demonstration herunterladen und prüfen

Voraussetzungen: Linux, Bash, ein lokaler Docker-Daemon, curl, OpenSSL und GNU coreutils. Das Skript lädt eine festgelegte acme.sh-Version, prüft deren Prüfsumme und verwendet ein per Digest festgelegtes Nginx-Image. Lesen Sie es und starten Sie es mit bash acme-sh-install-reload.sh.

BEFORE und SERVED zeigen den alten Fingerabdruck, DISK den neuen. AFTER muss mit DISK übereinstimmen. Assertions prüfen außerdem die gespeicherten Pfade, den Reload-Befehl und die unveränderten Berechtigungen der Schlüsseldatei. Das Skript verwendet ein temporäres acme.sh-Verzeichnis und einen Loopback-Port. Beim Beenden entfernt es Container und temporäre Dateien. Es richtet keinen Cronjob ein. Das Docker-Image bleibt im Cache.

Nur dieser an eine bestimmte Version gebundene Test befüllt den internen acme.sh-Zustand mit synthetischen Dateien. Übernehmen Sie diese Vorbereitung nicht in einen echten Zertifikatsspeicher. Die Demonstration prüft Installation, Fehlerbehandlung und Neuladen, keine ACME-Ausstellung, Erneuerungsplanung oder Vertrauensprüfung öffentlicher Browser.

6. Nach der unmittelbaren Prüfung weiter überwachen

Notieren Sie nach der Bereitstellung die beobachtete Adresse, SNI, Zeit und den Fingerabdruck. Stellen Sie sicher, dass der Erneuerungsjob auch ohne interaktive Shell dieselben Pfade und ausreichende Berechtigungen verwendet. Erfassen Sie seine Fehler in Ihrer bestehenden Jobüberwachung.

Nocert beobachtet regelmäßig die Zertifikate erreichbarer TLS-Endpunkte und wertet Regeln für Ablaufwarnungen täglich aus. Prüfen Sie Endpunkt und Beobachtungszeit und konfigurieren Sie die Empfänger. Das ergänzt die unmittelbare externe Prüfung. Nocert führt acme.sh nicht aus, installiert keine Zertifikate und lädt Nginx nicht neu. Es garantiert nicht, dass alle Besucher dasselbe Zertifikat erhalten.