Certbot für Nginx unter Ubuntu 24.04 installieren

Certbot installieren: apt oder snap

Unter Ubuntu 24.04 liefert sudo apt install certbot python3-certbot-nginx ein funktionierendes Certbot, das echte, öffentlich vertrauenswürdige Let's-Encrypt-Zertifikate ausstellt. Die Upstream-Dokumentation von Certbot verweist stattdessen auf snap. Der Unterschied ist begrenzt: snap folgt den Upstream-Releases, während das Archivpaket der Version folgt, die mit dem LTS ausgeliefert wurde, und Sicherheitsupdates erhält.

Wählen Sie eine Variante. Zwei Certbot-Installationen bedeuten zwei Erneuerungs-Timer, die auf denselben /etc/letsencrypt-Baum zeigen. Die vergessene Installation verursacht dann unerwartete Erneuerungen.

Der apt-Weg:

sudo apt update
sudo apt install certbot python3-certbot-nginx

Damit werden /usr/bin/certbot, das nginx-Plugin, ein Paar aus certbot.service und certbot.timer sowie ein /etc/cron.d/certbot-Eintrag installiert, der unter systemd keine Aktion ausführt.

Der snap-Weg:

sudo apt remove certbot python3-certbot-nginx
sudo snap install core && sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

snap liefert einen eigenen Timer, snap.certbot.renew.timer. Entfernen Sie das apt-Paket, bevor Sie snap installieren.

Nach der Installation verhalten sich beide Varianten gleich. Der einzige Unterschied besteht darin, wann sie eine Erneuerung auslösen (siehe „Erneuerung“ weiter unten). Certbot 2.x verwendet standardmäßig ECDSA-Schlüssel (P-256). Verwenden Sie --key-type rsa nur für einen Client, der ECDSA nicht unterstützt. Der gesamte Status liegt unter /etc/letsencrypt: archive/ enthält die eigentlichen Schlüssel- und Zertifikatsdateien, live/ enthält Symlinks auf die aktuellen Dateien, renewal/ enthält eine Konfigurationsdatei pro Zertifikat und accounts/ enthält Ihren ACME-Accountschlüssel.

Was HTTP-01 tatsächlich tut und warum Port 80 nicht optional ist

Die HTTP-01-Challenge ist ein Callback. Sie fordern bei Let's Encrypt ein Zertifikat für example.com an. Let's Encrypt löst den Namen im öffentlichen DNS auf, öffnet an der ermittelten Adresse eine Verbindung zu Port 80 und ruft http://example.com/.well-known/acme-challenge/<token> ab. Ihr Server antwortet mit dem exakten Token-Inhalt, den Certbot gerade auf die Festplatte geschrieben hat. Das ist der gesamte Mechanismus. Daraus ergeben sich drei Konsequenzen. Sie sind die Ursache für die meisten fehlgeschlagenen Zertifikatsausstellungen.

• Port 80 muss aus dem öffentlichen Internet erreichbar sein, nicht nur von Ihrem Laptop. Eine ufw-Regel, eine Security Group des Cloud-Anbieters oder eine Firewall in der VPS-Konsole, die nur Port 443 freigibt, verhindert die Ausstellung und jede spätere Erneuerung.
• Der DNS-Eintrag muss bereits auf diesen Server zeigen. Der Validierungsserver führt seine eigene DNS-Abfrage von außerhalb durch. Ihre /etc/hosts-Einträge und der Browser-Cache sind für ihn nicht relevant.
• Wenn Sie einen AAAA-Eintrag veröffentlichen, wird zuerst IPv6 verwendet. Let's Encrypt versucht IPv4 nur erneut, wenn die IPv6-Verbindung mit einem Timeout abläuft. Eine abgewiesene IPv6-Verbindung führt nicht zu einem weiteren Versuch. Ein veralteter AAAA-Eintrag, der auf einen Host zeigt, der die Verbindung akzeptiert und andere Inhalte ausliefert, verursacht einen endgültigen Fehler.

Weiterleitungen sind zulässig: Die Validierung folgt einer HTTP-Weiterleitung zu HTTPS. Dabei spielt es keine Rolle, ob das Zertifikat auf der Zielseite fehlt, abgelaufen oder selbst signiert ist. Der Startpunkt muss jedoch immer Port 80 sein. Certbot unterstützt TLS-ALPN-01 nicht. „Einfach Port 443 verwenden“ ist daher keine Alternative.

Wahl eines Authenticators: --nginx, --webroot, --standalone

--nginx ist die richtige Standardwahl, wenn nginx bereits läuft und die Domain ausliefert. Certbot analysiert Ihre Konfiguration, fügt einen temporären Challenge-Pfad hinzu, lädt nginx neu, validiert und schreibt anschließend die TLS-Direktiven in Ihren Server-Block. Dies geschieht ohne Ausfallzeit.

sudo certbot --nginx -d example.com -d www.example.com

Skriptgesteuert, für ein frisches System:

sudo certbot --nginx \
  -d example.com -d www.example.com \
  --agree-tos -m ops@example.com --no-eff-email \
  --redirect --non-interactive

--webroot ist die richtige Wahl, wenn Certbot Ihre nginx-Konfiguration nicht verändern soll, etwa weil Sie diese aus einer Vorlage generieren, in git verwalten oder per Ansible verteilen. Certbot schreibt lediglich die Challenge-Datei in ein Verzeichnis, das bereits von Ihnen ausgeliefert wird.

sudo certbot certonly --webroot -w /var/www/example.com \
  -d example.com -d www.example.com \
  --deploy-hook "systemctl reload nginx"

--standalone ist die richtige Wahl, wenn kein Dienst auf Port 80 lauscht: beispielsweise bei einem Mailserver, einer API, die nur über 443 kommuniziert, oder einem Initialisierungsskript, das vor der Installation von nginx ausgeführt wird. Certbot belegt Port 80 für wenige Sekunden selbst. Falls nginx bereits läuft, schlägt dies fehl; stoppen Sie den Dienst daher vor der Ausführung:

sudo certbot certonly --standalone -d mail.example.com \
  --pre-hook "systemctl stop nginx" \
  --post-hook "systemctl start nginx"

Diese Hooks werden in der Erneuerungskonfiguration des Zertifikats gespeichert, sodass derselbe Stopp- und Startvorgang bei der automatischen Erneuerung ohne manuelles Eingreifen erfolgt.

Ein Serverblock, der vor und nach dem Vorhandensein des Zertifikats funktioniert

Das Henne-Ei-Problem: nginx startet nicht, wenn ssl_certificate auf eine nicht vorhandene Datei verweist, und Certbot kann die Validierung nicht durchführen, solange nginx nicht läuft. Schalten Sie die Website zunächst auf Port 80 frei.

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.html;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/example.com;
        default_type "text/plain";
        try_files $uri =404;
    }

    location / {
        try_files $uri $uri/ =404;
    }
}

Führen Sie sudo nginx -t && sudo systemctl reload nginx aus und bestätigen Sie, dass curl -I http://example.com/ von außerhalb des Servers antwortet. Stellen Sie anschließend das Zertifikat aus.

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    location ^~ /.well-known/acme-challenge/ {
        root /var/www/example.com;
        default_type "text/plain";
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Der längere ACME-Präfix hat bereits Vorrang vor location /. Daher erhält return 301 keine Challenge-Anfrage. Der Modifikator ^~ ist an anderer Stelle wichtig: Sobald dieser Präfix übereinstimmt, überspringt nginx reguläre Location-Blöcke vollständig. Eine später hinzugefügte Regel wie location ~ /\. { deny all; } kann die Challenge daher nicht blockieren. Wenn dieser Location-Block auf Port 80 bleibt, funktionieren Erneuerungen auch dann weiter, wenn der restliche Inhalt der Website nur noch über HTTPS erreichbar ist.

Beide oben gezeigten Blöcke liefern Dateien von der Festplatte aus. Wenn nginx stattdessen als Proxy vor einer Anwendung läuft, wird location / zu einem proxy_pass-Block. Der Reverse-Proxy-Serverblock, Zeile für Zeile beschreibt die für diese Anwendung erforderlichen Header. Der ACME-Location-Block und die TLS-Direktiven bleiben unverändert.

Die Syntax für HTTP/2 hängt von Ihrer nginx-Version ab. Ubuntu 24.04 liefert nginx 1.24 aus. Diese Version erwartet die Angabe inline als listen 443 ssl http2; und startet nicht, wenn Sie die separate Direktive http2 on; verwenden. Debian 13 liefert nginx 1.26 aus. Diese Version erwartet http2 on; und gibt bei der Inline-Form nur eine Warnung aus, dass sie veraltet ist. Prüfen Sie zuerst nginx -v.

Verweisen Sie nginx auf live/, niemals auf archive/. Die symbolischen Links unter live/ werden bei jeder Erneuerung neu gesetzt. Ein fester Pfad unter archive/ bindet Sie dagegen an ein Zertifikat, das abläuft, ohne dass der Pfad aktualisiert wird.

Wildcards erfordern DNS-01, und DNS-01 erfordert ein Plugin

Ein Wildcard-Zertifikat (*.example.com) kann nicht über HTTP-01 validiert werden, da es keinen einzelnen Hostnamen gibt, von dem eine Datei abgerufen werden könnte. DNS-01 ist der einzige Weg: Sie beweisen die Kontrolle, indem Sie einen _acme-challenge.example.com TXT-Record veröffentlichen. Certbot benötigt API-Zugangsdaten für Ihren DNS-Anbieter, um dies automatisiert durchzuführen; genau dafür existieren die Anbieter-Plugins. Die vollständige Anleitung für Wildcard-Zertifikate behandelt die Mechanismen der TXT-Records und die Erneuerungsfalle im manuellen Modus; die kurze Cloudflare-Version folgt hier.

sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-cloudflare

Auf dem apt-Pfad ist dies stattdessen sudo apt install python3-certbot-dns-cloudflare. Die Zugangsdaten gehören in eine Datei, die nur für root lesbar ist:

# /root/.secrets/cloudflare.ini
# then: sudo chmod 600 /root/.secrets/cloudflare.ini
dns_cloudflare_api_token = your_scoped_token_here

Beschränken Sie das Token auf DNS-Bearbeitungsrechte für diese eine Zone. Es ist ein kryptografischer Schlüssel für Ihr DNS; behandeln Sie ihn auch so.

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini \
  -d example.com -d '*.example.com'

Setzen Sie den Wildcard-Eintrag in Anführungszeichen, damit die Shell ihn nicht als Glob-Muster interpretiert. DNS-01 löst zudem Probleme, die mit HTTP-01 nicht lösbar sind: Zertifikate für Hosts ohne öffentlichen Port 80, einen internen Dienst, einen Server, der nur über ein selbst gehostetes WireGuard VPN auf einem VPS erreichbar ist, oder ein Admin-Panel auf einer privaten Schnittstelle.

Erneuerung: die 90 Tage, der Timer, der Deploy-Hook

Let's-Encrypt-Zertifikate sind 90 Tage gültig. Das apt-Paket (Certbot 2.9.0) erneuert sie, wenn weniger als 30 Tage verbleiben. Der Snap verwendet die aktuelle Certbot-Version. Seit Version 4.1 fragt Certbot Let’s Encrypt zusätzlich über ACME Renewal Info (ARI) nach einem empfohlenen Erneuerungszeitpunkt und kann Zertifikate früher erneuern. Bei einem Let’s-Encrypt-Zertifikat entspricht das typischerweise etwa zwei Dritteln seiner Gültigkeitsdauer. In beiden Fällen haben Sie ungefähr 30 Tage Zeit, um eine fehlgeschlagene Erneuerung zu beheben, bevor daraus ein Ausfall wird. Ab dem nächsten Jahr werden Erneuerungen voraussichtlich häufiger erforderlich sein: Das Standardprofil von Let’s Encrypt stellt am February 10, 2027 auf Zertifikate mit 64 Tagen Gültigkeit und am February 16, 2028 auf Zertifikate mit 45 Tagen Gültigkeit um. Let’s Encrypt versendet keine E-Mail-Warnungen vor dem Ablauf mehr. Niemand weist Sie darauf hin. Die Überwachung liegt jetzt bei Ihnen.

Prüfen Sie den Timer, den Ihre Installation eingerichtet hat:

systemctl list-timers 'certbot*' 'snap.certbot*'
sudo certbot certificates

certbot renew durchläuft jede Konfiguration in /etc/letsencrypt/renewal/, überspringt noch nicht fällige Einträge und erneuert die übrigen Zertifikate mit den in der jeweiligen Konfiguration gespeicherten Optionen. Dabei handelt es sich um die Flags des ursprünglichen Aufrufs, sofern Sie sie nicht später mit certbot reconfigure geändert haben. Deshalb ist der erste Aufruf wichtig: Er wird aufgezeichnet.

Wenn das Zertifikat auf der Festplatte erneuert wird, ändert sich dadurch allein noch nichts. nginx verwendet weiterhin das alte Zertifikat aus dem Speicher, bis ein Reload ausgelöst wird. Richten Sie einmalig einen Deploy-Hook ein:

sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh >/dev/null <<'EOF'
#!/bin/sh
set -e
nginx -t && systemctl reload nginx
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Alles Ausführbare in renewal-hooks/deploy/ wird nach jeder erfolgreichen Erneuerung ausgeführt. Das Flag --deploy-hook erfüllt dieselbe Aufgabe für ein einzelnes Zertifikat und speichert renew_hook = ... in dessen Erneuerungskonfiguration. certbot --nginx führt den Reload automatisch aus. Bei --webroot- und --standalone-Setups geschieht das nicht. Ein fehlender Hook ist genau der Grund, warum eine Website ein abgelaufenes Zertifikat ausliefert, während certbot certificates ordnungsgemäß ein neues Zertifikat meldet. Alles andere, das das Zertifikat beim Start einliest, benötigt denselben Hook. Eine containerisierte Anwendung wie eine Nextcloud-VPS-Installation mit Docker, TLS und Backups benötigt hier ebenfalls einen eigenen Restart- oder Reload-Schritt.

Erneuerung unter realen Bedingungen testen

sudo certbot renew --dry-run

Damit wird die vollständige Challenge gegen die Staging-Umgebung von Let's Encrypt ausgeführt: derselbe Codepfad, dieselbe Firewall, dasselbe DNS, ohne Ihre Produktionslimits zu belasten (Staging hat eigene, deutlich großzügigere Limits), und ohne Zertifikate auf der Festplatte zu speichern. Wenn der Test heute erfolgreich ist, funktioniert auch die unbeaufsichtigte Erneuerung in 60 Tagen, sofern sich an der Umgebung des Servers nichts ändert.

Ein Probelauf bestätigt nicht, dass Ihr Reload-Hook ausgeführt wird. Das Verhalten unterscheidet sich je nach Certbot-Version. Testen Sie diesen Teil manuell: Führen Sie das Hook-Skript direkt aus, bestätigen Sie, dass systemctl reload nginx erfolgreich ist, und prüfen Sie sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf.

Die Fehler, auf die Sie tatsächlich stoßen werden

Could not bind to IPv4 or IPv6., --standalone, während nginx Port 80 bereits verwendet. Verwenden Sie --nginx oder --webroot, oder beenden Sie nginx für die Dauer des Laufs. Ermitteln Sie den Prozess, der den Port verwendet, mit sudo ss -lntp | grep ':80'.

Timeout during connect (likely firewall problem), Let's Encrypt konnte Port 80 nicht erreichen. Gehen Sie die möglichen Ursachen von innen nach außen durch: sudo ufw status (öffnen Sie ihn mit sudo ufw allow 'Nginx Full'), anschließend die Firewall des VPS-Anbieters und danach DNS. Testen Sie von einem System aus, das nicht Ihr Server ist: curl -sSv http://example.com/.well-known/acme-challenge/test. Ein veralteter AAAA-Record erzeugt dieselbe Meldung.

unauthorized :: Invalid response from http://example.com/.well-known/acme-challenge/xyz: 404, Port 80 ist erreichbar, aber das Token wird nicht ausgeliefert. Die Anfrage ist in einem anderen Server-Block gelandet (prüfen Sie, welcher für default_server zuständig ist), oder das an -w übergebene Verzeichnis ist nicht das Verzeichnis, das nginx ausliefert. Legen Sie unter /var/www/example.com/.well-known/acme-challenge/test eine Datei ab und rufen Sie sie extern ab. Wenn dabei ein 404-Fehler auftritt, war das Zertifikat nie die Ursache.

DNS problem: NXDOMAIN looking up A for example.com, der Name wird öffentlich nicht aufgelöst. Möglicherweise wurden neue DNS-Einträge noch nicht verteilt, oder der Eintrag befindet sich in einer Zone, die Ihr Registrar nicht bereitstellt.

too many certificates (5) already issued ..., ein Rate-Limit, und das Limit, auf das man beim Debuggen in einer Schleife stößt. Die Meldung nennt das Limit und endet mit einer Zeitangabe im Format retry after. Let’s Encrypt begrenzt identische Zertifikate, also exakt dieselbe Menge an Namen, auf fünf pro Woche. Für dieses Limit gibt es keine Ausnahme. Es wird daher nur durch das Verstreichen der Zeit aufgehoben. Unabhängig davon erlaubt Let’s Encrypt 50 neue Zertifikate pro registrierter Domain und Woche. Dieses Limit kann durch einen Antrag auf eine Ausnahme erhöht werden. Ein Antrag für exakt dieselbe Menge an Namen wie bei einem vorhandenen Zertifikat gilt als Erneuerung und wird auf dieses Limit nicht angerechnet. Über ARI koordinierte Erneuerungen sind von allen Limits ausgenommen. Testen Sie das Debugging gegen die Staging-Umgebung mit --dry-run.

nginx: [emerg] cannot load certificate "/etc/letsencrypt/live/example.com/fullchain.pem": No such file or directory nginx ist für ein Zertifikat konfiguriert, das nie ausgestellt wurde, oder für ein Zertifikat, das mit certbot delete entfernt wurde. Kommentieren Sie den TLS-Serverblock aus, starten Sie nginx, stellen Sie das Zertifikat aus und stellen Sie den Block anschließend wieder her.

open() "/etc/letsencrypt/options-ssl-nginx.conf" failed wird mit dem nginx-Plugin-Paket installiert. Auf einem certonly-System ohne python3-certbot-nginx installieren Sie entweder das Plugin oder ersetzen die Zeile include durch eigene Einstellungen für ssl_protocols und ssl_ciphers.

Skalierung der Zertifikatsverwaltung

Ein Zertifikat kann bis zu 100 Namen enthalten, und ein einzelnes certbot --nginx -d a.example.com -d b.example.com ... ist verlockend, bis ein veralteter DNS-Eintrag die Validierung fehlschlagen lässt und damit alle anderen Namen auf diesem Zertifikat ebenfalls ungültig werden. Separate Zertifikate pro Website fallen unabhängig voneinander aus, was bei einem Server mit mehr als nur ein paar Diensten das gewünschte Verhalten ist. Ab einer Handvoll Websites zahlt sich ein ACME-fähiger Reverse Proxy aus: Ein Traefik Reverse Proxy, der mehrere Anwendungen unter Docker Compose betreibt, fordert die Zertifikate selbst an und erneuert sie, wodurch Certbot vollständig entfällt. Welcher Proxy an dieser Stelle eingesetzt wird, ist eine individuelle Entscheidung, und der Vergleich von Nginx mit Caddy und Traefik hängt hauptsächlich davon ab, wie viel Arbeit bei der Zertifikatsverwaltung und der anwendungsspezifischen Konfiguration der Proxy übernehmen soll.

Sichern Sie /etc/letsencrypt vollständig, inklusive sudo tar -czf letsencrypt-$(date +%F).tar.gz -C /etc letsencrypt, unter Beibehaltung der Symlinks. Dieser Verzeichnisbaum enthält accounts/, Ihren ACME-Account-Key, den Sie nicht identisch neu generieren können. Der Umzug auf einen neuen VPS reduziert sich damit auf: Synchronisieren des Verzeichnisbaums mit -a, Installation von Certbot, Anpassung der DNS-Einträge und Ausführen von certbot renew --dry-run, bevor Sie den Datenverkehr umstellen.

Wenn Sie den Server neu aufsetzen oder auf eine neue LTS-Version wechseln, wird der Erneuerungs-Timer nicht automatisch übernommen. Führen Sie nach jeder Migration, Wiederherstellung eines Snapshots oder Distribution-Upgrade systemctl list-timers 'certbot*' und einmal --dry-run aus. Wer dies versäumt, riskiert, dass eine Website 89 Tage später um 3 Uhr morgens ausfällt, weil ein Zertifikat abgelaufen ist, bei dem alle davon ausgingen, dass es sich selbst erneuert.

Die oben beschriebenen HTTP-01-Verfahren setzen einen Server voraus, den Sie kontrollieren, mit einer öffentlichen IP-Adresse und einem für die Welt offenen Port 80 – also einen VPS; DNS-01 benötigt dies nicht. Die zugrunde liegenden Mechanismen sind bei jeder dieser Varianten identisch.

Die gleichen Schritte für Zertifikate gelten für Apache anstelle von nginx, und wenn ein öffentliches Zertifikat keine Option ist, deckt ein selbstsigniertes Zertifikat unter Ubuntu interne Dienste ab.

FAQ

Muss Port 80 geöffnet sein, wenn meine Website nur HTTPS bereitstellt?

Ja, für die HTTP-01-Challenge. Let’s Encrypt startet seine Validierungsanfrage immer auf Port 80. Certbot implementiert TLS-ALPN-01 nicht. Eine Firewall, die nur Port 443 öffnet, blockiert daher sowohl die erste Ausstellung als auch jede anschließende unbeaufsichtigte Erneuerung. Eine Weiterleitung von Port 80 auf HTTPS ist unproblematisch, da die Validierung dieser Weiterleitung folgt. Port 80 lässt sich nur mit DNS-01 vollständig vermeiden, entweder über ein Provider-Plugin oder mit Certbots --manual --preferred-challenges dns. Dabei fügen Sie den TXT-Eintrag selbst hinzu. Die Erneuerung ist dann nicht mehr automatisch, sofern Sie kein --manual-auth-hook-Skript angeben.

apt oder snap: Welche Certbot-Variante sollte ich für nginx auf Ubuntu 24.04 installieren?

Verwenden Sie apt. sudo apt install certbot python3-certbot-nginx stellt auf Ubuntu 24.04 Certbot 2.9.0 bereit. Diese Version ist für alle Inhalte dieses Leitfadens aktuell genug, erhält Sicherheitsupdates über unattended-upgrades und erfordert kein snapd. Wählen Sie snap nur, wenn Sie sofort die neueste Version benötigen oder ein DNS-Plugin verwenden möchten, das ausschließlich als snap verteilt wird. Installieren Sie in jedem Fall genau eine Variante: Zwei Installationen bedeuten zwei Erneuerungs-Timer, die auf denselben /etc/letsencrypt-Baum zeigen. Die vergessene Installation verursacht dann das Problem.

Kann Certbot ein Wildcard-Zertifikat für nginx ausstellen?

Nur über DNS-01. Ein Wildcard wie *.example.com hat keinen einzelnen Hostnamen, von dem eine Challenge-Datei abgerufen werden kann. Daher entfallen --nginx, --webroot und --standalone. Installieren Sie das Plugin für Ihren DNS-Provider, hinterlegen Sie ein eingeschränktes API-Token in einer nur für root lesbaren Credentials-Datei und führen Sie certbot certonly --dns-cloudflare -d example.com -d '*.example.com' aus. Setzen Sie das Wildcard in Anführungszeichen, damit die Shell es nicht als Glob interpretiert.

Warum liefert nginx nach einer erfolgreichen Erneuerung weiterhin das alte Zertifikat aus?

nginx hält das Zertifikat im Speicher und erkennt die neue Datei auf der Festplatte erst nach einem Reload. certbot --nginx führt diesen Reload automatisch aus. --webroot und --standalone tun dies jedoch nicht. Daher kann eine Erneuerung erfolgreich sein, während der Browser weiterhin ein bald ablaufendes Zertifikat sieht. Legen Sie ein ausführbares Skript in /etc/letsencrypt/renewal-hooks/deploy/ ab, das nginx -t && systemctl reload nginx ausführt. Es wird nach jeder erfolgreichen Erneuerung gestartet.

Beweist certbot renew --dry-run, dass die Erneuerung funktionieren wird?

Überwiegend. Der Befehl führt die echte Challenge in der Staging-Umgebung aus. Dabei werden dieselbe Firewall, dasselbe DNS und derselbe Codepfad verwendet, ohne Ihre Produktions-Ratelimits zu beeinflussen oder Zertifikate auf der Festplatte zu speichern. Ein erfolgreicher Durchlauf zeigt daher, dass der Netzwerkteil funktioniert. Er beweist jedoch nicht zuverlässig, dass Ihr Deploy-Hook ausgeführt wird. Testen Sie dies separat: Führen Sie das Hook-Skript manuell aus und prüfen Sie sudo grep renew_hook /etc/letsencrypt/renewal/example.com.conf.