Let's-Encrypt-Zertifikat mit certbot einrichten und erneuern

Das Zertifikat zu holen ist der leichte Teil. Die Probleme kommen später: wenn der Renew-Timer nicht läuft, wenn nach einem Umzug die Validierung scheitert oder wenn man beim Herumprobieren in ein Rate-Limit läuft und eine Woche warten muss. Diese Anleitung geht deshalb über den einen certbot-Befehl hinaus.

Was du vor dem Let’s-Encrypt-Zertifikat brauchst

Let’s Encrypt prüft, ob du die Domain kontrollierst. Beim Standardverfahren HTTP-01 legt certbot eine Datei unter /.well-known/acme-challenge/ ab, und die Server von Let’s Encrypt rufen sie über Port 80 ab. Dafür müssen drei Dinge stimmen:

• Die Domain zeigt per A-Record auf deinen Server, und falls ein AAAA-Record existiert, ist der Server auch über IPv6 erreichbar.
• Port 80 ist offen, auch wenn deine Seite später nur HTTPS spricht.
• Der Webserver beantwortet Anfragen für genau diesen Namen.

dig +short example.com A
dig +short example.com AAAA
curl -I http://example.com

Wenn curl eine Antwort von deinem Server liefert, kann es losgehen.

Zertifikat mit certbot und nginx holen

Auf Debian 12 und Ubuntu 24.04 ist certbot im Paketarchiv:

apt update
apt install certbot python3-certbot-nginx

Erst gegen die Staging-Umgebung testen. Die stellt Zertifikate ohne gültige Kette aus, hat aber großzügigere Limits:

certbot --nginx --test-cert -d example.com -d www.example.com

Läuft das durch, das echte Zertifikat:

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

certbot fragt, ob es das Testzertifikat ersetzen soll, und trägt ssl_certificate und ssl_certificate_key in deinen Server-Block ein. Die Dateien liegen unter /etc/letsencrypt/live/example.com/:

Willst du nicht, dass certbot deine nginx-Konfiguration anfasst, nimm das Webroot-Verfahren:

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

Den Pfad zu den Zertifikaten trägst du dann selbst ein.

Automatische Erneuerung prüfen

Das Debian-Paket bringt einen systemd-Timer mit, der zweimal täglich certbot renew aufruft. certbot erneuert nur Zertifikate, die bald ablaufen, bei 90-Tage-Zertifikaten etwa 30 Tage vor Ende.

systemctl list-timers | grep certbot
certbot renew --dry-run

Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/example.com/fullchain.pem (success)

Hast du certbot per Snap installiert, heißt der Timer snap.certbot.renew.timer. Zwei parallel installierte certbots, einer aus apt und einer aus Snap, sind eine beliebte Fehlerquelle.

Nach der Erneuerung muss nginx die neue Datei laden. Beim nginx-Plugin passiert das automatisch, beim Webroot-Verfahren über den --deploy-hook. Der Hook wird in /etc/letsencrypt/renewal/example.com.conf gespeichert und bei jeder Erneuerung ausgeführt.

Let’s Encrypt verschickt keine Warnmails mehr vor dem Ablauf. Wenn die Erneuerung still scheitert, merkst du es erst, wenn Browser warnen. Ein einfacher Check per Cron oder Monitoring hilft:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

Laufzeit: von 90 auf 45 Tage

Let’s Encrypt hat angekündigt, die Laufzeit schrittweise zu verkürzen (Quelle: Let’s Encrypt, Certificate Lifetimes):

Seit Mai 2026 gibt es das optionale Profil tlsserver mit 45 Tagen schon jetzt, dazu ein Profil shortlived mit 6 Tagen. Für dich heißt das vor allem: Feste Erneuerungsintervalle wie „alle 60 Tage per Cron“ funktionieren bald nicht mehr. Lass den Client entscheiden, wann er erneuert.

Die Rate-Limits, die in der Praxis zählen

Stand der offiziellen Rate-Limit-Doku:

Das Limit mit den fünf identischen Zertifikaten trifft Leute, die ihren Container immer wieder neu bauen und dabei /etc/letsencrypt nicht als Volume behalten. Jeder Neustart holt ein neues Zertifikat, und nach dem fünften ist eine Woche Schluss. Erneuerungen, die über ARI (ACME Renewal Information) koordiniert sind, fallen laut Let’s Encrypt unter keines der Limits.

Ein Zertifikat für viele Namen oder viele Zertifikate?

Ein Let’s-Encrypt-Zertifikat kann bis zu 100 Namen enthalten. Verlockend, alle Domains des Servers in eins zu packen. Der Haken: Fällt die Validierung für einen einzigen Namen aus, etwa weil eine Domain ausgelaufen ist oder woandershin zeigt, scheitert die Erneuerung für alle. Außerdem steht jeder Name im Zertifikat und damit in den öffentlichen Certificate-Transparency-Logs nebeneinander.

Besser: ein Zertifikat pro Website, also example.com plus www.example.com. certbot verwaltet beliebig viele davon, jedes mit eigener Datei unter /etc/letsencrypt/renewal/. Welche existieren und wann sie ablaufen, zeigt:

certbot certificates

Typische Fehlermeldungen

Timeout during connect (likely firewall problem): Port 80 ist zu oder die IP stimmt nicht. Steht eine IPv6-Adresse in der Meldung, ist es fast immer ein AAAA-Record ohne funktionierendes IPv6.

Invalid response from http://example.com/.well-known/acme-challenge/...: 404: Die Anfrage kommt an, aber ein anderer Server-Block oder eine Weiterleitung fängt sie ab. Prüfe Rewrites und ob ein Reverse Proxy davor sitzt.

DNS problem: NXDOMAIN looking up A for www.example.com: Für www gibt es keinen Eintrag. Entweder anlegen oder -d www.example.com weglassen.

Brauchst du ein Zertifikat für *.example.com, geht das nur per DNS-01. Das beschreibt der Artikel zum Wildcard-Zertifikat. Und wer statt nginx lieber Caddy oder Traefik nutzt, bekommt die Zertifikate dort ohne certbot, siehe Reverse Proxy für mehrere Domains.

Nächster Schritt

Wenn certbot renew --dry-run durchläuft, bist du fertig. Für ein weiteres Projekt kannst du freie Domains bei betadomain finden. Endungen wie .dev (22,99 €) und .app (22,99 €) stehen auf der HSTS-Preload-Liste und funktionieren im Browser nur mit HTTPS, ein Zertifikat ist dort also Pflicht.

Schritt für Schritt

1. DNS und Port 80 prüfenMit dig +short example.com A und AAAA prüfen, dass die Domain auf den Server zeigt, und mit curl -I http://example.com, dass Port 80 antwortet.
2. certbot installierenapt install certbot python3-certbot-nginx ausführen, bei Apache stattdessen python3-certbot-apache.
3. Mit Staging testencertbot --nginx --test-cert -d example.com -d www.example.com ausführen, um Fehler ohne Rate-Limit-Risiko zu finden.
4. Echtes Zertifikat holenDenselben Befehl ohne --test-cert ausführen und die Frage nach dem Ersetzen des Testzertifikats bestätigen.
5. Erneuerung testencertbot renew --dry-run ausführen und mit systemctl list-timers prüfen, dass der certbot-Timer aktiv ist.