Webhosting 7 Min Lesezeit

Let's Encrypt SSL-Zertifikate 2026 – Automatisierung mit Certbot

Q: Was passiert, wenn ich das Rate Limit von Let's Encrypt reiße?

Ihr bekommt HTTP 429 mit einem Retry-After-Header. Das Duplicate-Certificate-Limit (5 pro Woche) ist am schmerzhaftesten, weil es eine volle Woche gilt. Nutzt zum Testen immer --dry-run oder --test-cert gegen das Staging-Environment, das eigene, deutlich höhere Limits hat.

Let's Encrypt 2026: Was sich geändert hat

Let's Encrypt ist mit mehreren hundert Millionen ausgestellten Zertifikaten pro Jahr die größte Certificate Authority der Welt und für praktisch jedes Webhosting-Setup der Standard. 2026 gibt es allerdings drei Änderungen, die die Automatisierung direkt betreffen: die verkürzte Standard-Laufzeit, ACME Renewal Information (ARI) und das endgültige Aus für OCSP.

Die wichtigste Neuerung: Let's Encrypt hat angekündigt, die Standard-Gültigkeit von 90 auf 45 Tage zu reduzieren. Zusätzlich stehen Short-Lived Certificates mit nur 6 Tagen Laufzeit zur Verfügung. Für Admins bedeutet das: manuelle Renewals sind endgültig Geschichte. Wer 2026 noch per Kalender-Eintrag verlängert, fällt spätestens nach sechs Wochen mit einer abgelaufenen Zertifikatskette aus.

Zweite Änderung ist ARI (ACME Renewal Information, RFC 9773). Statt stumpf alle 60 Tage zu erneuern, fragt der Client bei der CA nach, wann das konkrete Zertifikat erneuert werden soll. Let's Encrypt kann so bei Massen-Revocations Lastspitzen entzerren. Certbot unterstützt ARI seit Version 2.10, in Certbot 4.x ist es standardmäßig aktiv.

Dritte Änderung betrifft OCSP: Let's Encrypt hat den OCSP-Responder im Mai 2025 abgeschaltet. ssl_stapling on; in nginx ist damit für Let's-Encrypt-Zertifikate wirkungslos. Stattdessen setzt die CA auf CRL und kurze Laufzeiten — ein weiteres Argument für aggressive Automatisierung.

Voraussetzungen und Installation von Certbot

Certbot ist der Referenz-Client der EFF und läuft auf jedem Linux mit Python 3.9+. Der offizielle Weg ist 2026 Snap, weil die Distributions-Pakete oft Monate hinterherhängen.

# Debian 12 / Ubuntu 24.04
sudo apt update
sudo apt install -y certbot python3-certbot-nginx

# Empfohlen: aktuelle Version via Snap
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
certbot --version
# certbot 4.1.0

Für nginx- und Apache-Umgebungen gibt es Plugins, die die Serverkonfiguration selbst anpassen. python3-certbot-nginx bzw. python3-certbot-apache übernehmen das. Für DNS-01 braucht ihr zusätzlich das passende Provider-Plugin, etwa python3-certbot-dns-cloudflare.

Wichtig: Port 80 muss von außen erreichbar sein, wenn ihr HTTP-01 nutzt. Bei Cloudflare im Proxy-Modus ("orange cloud") schlägt die Validierung fehl, weil der ACME-Pfad nicht durchgereicht wird — entweder DNS-Only schalten oder DNS-01 verwenden.

Legt außerdem einen dedizierten ACME-Account-Key an und sichert /etc/letsencrypt mit chmod 700. Ein kompromittierter Account-Key erlaubt das Ausstellen beliebiger Zertifikate für alle Domains, die der Account je validiert hat.

Zertifikate ausstellen: Die drei Validierungsmethoden

Let's Encrypt unterstützt HTTP-01, DNS-01 und TLS-ALPN-01. Die Wahl bestimmt, wie gut sich euer Setup automatisieren lässt.

Methode	Port	Wildcard	Einsatz
HTTP-01	80	nein	Standard-Webserver, einfachster Weg
DNS-01	53	ja	Wildcards, interne Hosts, kein Port 80
TLS-ALPN-01	443	nein	Reverse-Proxy, Port 80 blockiert

Der klassische Weg mit nginx sieht so aus:

sudo certbot --nginx \
  -d example.com -d www.example.com \
  --email [email protected] \
  --agree-tos --no-eff-email \
  --redirect --hsts

Für reine Webroot-Setups, etwa hinter einem Loadbalancer, nutzt ihr:

sudo certbot certonly --webroot \
  -w /var/www/html -d example.com -d www.example.com

Die Zertifikate landen unter /etc/letsencrypt/live/example.com/ mit vier Dateien: cert.pem (nur Leaf), chain.pem (Intermediate), fullchain.pem (beides, das braucht der Webserver) und privkey.pem. Verlinkt niemals die archive/-Verzeichnisse direkt — live/ ist ein Symlink-Set, das Certbot bei jedem Renewal atomar umbiegt.

Automatisierung: systemd-Timer statt Cron

Certbot bringt seit Version 1.x einen systemd-Timer mit, der zweimal täglich mit zufälligem Delay läuft. Prüft das mit:

systemctl list-timers | grep certbot
# certbot.timer  ... 2h 13min  ... certbot.service

Der Timer startet certbot renew, das nur Zertifikate erneuert, die innerhalb der nächsten 30 Tage ablaufen. Bei kürzeren Laufzeiten greift ARI zusätzlich und verschiebt den Zeitpunkt dynamisch.

Ein Dry-Run gehört in jeden Deploy-Prozess:

sudo certbot renew --dry-run
# Congratulations, all simulated renewals succeeded

Wenn ihr wirklich Cron braucht, etwa in Containern ohne systemd, nehmt einen zufälligen Delay, um die CA nicht zu hämmern:

# /etc/cron.d/certbot
0 */12 * * * root perl -e 'sleep int(rand(43200))' && certbot -q renew

Für Container-Setups ist ein eigener Sidecar-Container oft die bessere Wahl: Certbot schreibt in ein Volume, nginx liest von dort und lädt per nginx -s reload neu.

Renewal-Hooks: Reload, Deployment und DNS-API

Ein Renewal ohne Reload ist wertlos. Certbot kennt drei Hook-Typen: --pre-hook (vor der Validierung), --post-hook (nach jedem Versuch) und --deploy-hook (nur nach erfolgreichem Renewal).

sudo certbot renew \
  --pre-hook "systemctl stop nginx" \
  --post-hook "systemctl start nginx" \
  --deploy-hook "systemctl reload nginx"

Für den Standalone-Modus ist der --pre-hook zwingend, weil Port 80 freigehalten werden muss. Bei nginx/Apache-Plugins reicht der Reload.

Dauerhaft setzt ihr die Hooks in der Renewal-Config:

# /etc/letsencrypt/renewal/example.com.conf
[renewalparams]
authenticator = nginx
installer = nginx
key_type = ecdsa
renew_hook = systemctl reload nginx

Für Kubernetes ist ein Deploy-Hook sinnvoll, der ein Secret aktualisiert:

--deploy-hook "kubectl create secret tls example-tls \
  --cert=/etc/letsencrypt/live/example.com/fullchain.pem \
  --key=/etc/letsencrypt/live/example.com/privkey.pem \
  --dry-run=client -o yaml | kubectl apply -f -"

Wildcard-Zertifikate mit der DNS-01-Challenge

Wildcards gibt es bei Let's Encrypt nur über DNS-01. Der Client legt einen TXT-Record _acme-challenge.example.com an, Let's Encrypt prüft ihn, danach wird er gelöscht. Das erfordert API-Zugriff auf euren DNS-Provider.

Für Cloudflare sieht das so aus:

sudo apt install python3-certbot-dns-cloudflare
sudo mkdir -p /etc/letsencrypt
cat > /etc/letsencrypt/cloudflare.ini <<'EOF'
dns_cloudflare_api_token = DEIN_API_TOKEN
EOF
sudo chmod 600 /etc/letsencrypt/cloudflare.ini

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  --dns-cloudflare-propagation-seconds 30 \
  -d example.com -d '*.example.com'

Der API-Token sollte auf Zone:DNS:Edit für genau eine Zone beschränkt sein — nicht der Global API Key. Bei Hetzner, Netcup, INWX, Route 53 und deSEC gibt es analoge Plugins bzw. acme.sh-Hooks.

Wildcards sind praktisch für Subdomain-Farmen, haben aber einen Nachteil: Ein kompromittierter DNS-Zugang erlaubt Zertifikate für jede Subdomain. Bei sicherheitskritischen Umgebungen ist ein Zertifikat pro Hostname mit HTTP-01 die kleinere Angriffsfläche.

Schlüsseltypen: ECDSA vs. RSA und TLS-1.3-Härtung

Let's Encrypt stellt seit 2020 standardmäßig RSA-2048 aus, unterstützt aber ECDSA mit P-256. ECDSA ist schneller, kleiner und 2026 die bessere Wahl.

sudo certbot certonly --nginx \
  -d example.com \
  --key-type ecdsa --elliptic-curve secp256r1

Prüft danach, was euer Server ausliefert:

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null \
  | openssl x509 -noout -text | grep -E "Public Key Algorithm|Signature Algorithm"
# Public Key Algorithm: id-ecPublicKey
# Signature Algorithm: ecdsa-with-SHA256

Eine gehärtete nginx-Konfiguration für 2026:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_protocols       TLSv1.2 TLSv1.3;
ssl_ciphers         ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
ssl_session_cache   shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Beachtet: ssl_stapling on; bringt bei Let's Encrypt seit der OCSP-Abschaltung 2025 nichts mehr und kann entfernt werden. Wer TLS-1.3-only fährt, schließt Clients aus, die noch TLS 1.2 brauchen — bei Gameservern und älteren APIs ist das oft noch relevant.

Rate Limits von Let's Encrypt im Detail

Die Limits sind 2026 unverändert streng. Wer sie reißt, bekommt HTTP 429 und muss bis zu einer Woche warten.

Limit	Wert	Geltungsbereich
Zertifikate pro registrierter Domain	50 / Woche	exakte Domain, Subdomains separat
Duplicate Certificates	5 / Woche	identische SAN-Liste
Neue Orders	300 / 3 h	pro ACME-Account
Failed Validations	5 / Stunde	pro Account + Hostname
Accounts pro IP	10 / 3 h	Registrierungen

Das Duplicate-Limit ist die häufigste Falle: Wer beim Debuggen zehnmal dasselbe Zertifikat anfordert, ist für eine Woche gesperrt. Nutzt stattdessen --dry-run oder das Staging-Environment:

sudo certbot certonly --nginx -d example.com --test-cert

Staging-Zertifikate sind nicht vertrauenswürdig, aber die Validierung ist identisch — perfekt zum Testen von DNS-Plugins und Hooks. Vor dem Produktivgang löscht ihr sie mit certbot delete --cert-name example.com.

Prüft euren Bestand jederzeit mit:

sudo certbot certificates
# Certificate Name: example.com
#   Domains: example.com www.example.com
#   Expiry Date: 2026-04-12 (VALID: 44 days)
#   Key Type: ECDSA

Monitoring, Logs und Troubleshooting

Automatisierung ohne Monitoring ist ein Blindflug. Der einfachste Check ist ein externer Uptime-Monitor, der das Ablaufdatum per TLS-Handshake liest — Uptime Kuma, Better Stack und Pingdom können das alle.

Alternativ ein eigener Check mit openssl:

#!/bin/bash
EXPIRY=$(echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
DAYS=$(( ( $(date -d "$EXPIRY" +%s) - $(date +%s) ) / 86400 ))
[ "$DAYS" -lt 14 ] && echo "WARNUNG: Zertifikat laeuft in $DAYS Tagen ab"

Logs liegen unter /var/log/letsencrypt/letsencrypt.log. Bei Problemen hilft certbot renew --dry-run -v mit vollständigem Traceback.

Die drei häufigsten Fehlerquellen:

DNS-Propagation: Der _acme-challenge-TXT ist noch nicht sichtbar — --dns-cloudflare-propagation-seconds auf 60 erhöhen.
Port 80 blockiert: Firewall oder Cloudflare-Proxy — ufw allow 80/tcp oder auf DNS-01 wechseln.
Dateirechte: privkey.pem ist root:root 600 — der Webserver-User braucht Zugriff über eine Gruppe oder einen Kopierschritt.

Bei "too many failed authorizations" wartet eine Stunde, statt weiter zu probieren. Prüft zuerst die DNS-Auflösung mit dig +short example.com und ob euer Webserver auf Port 80 tatsächlich den Pfad /.well-known/acme-challenge/ ausliefert.

Alternativen: acme.sh, Caddy, Traefik und lego

Certbot ist nicht mehr die einzige gute Option. Je nach Stack ist ein anderer Client deutlich angenehmer.

Client	Sprache	Stärke	DNS-Provider
Certbot	Python	nginx/Apache-Integration, Referenz	~20 Plugins
acme.sh	Shell	kein Root nötig, sehr viele DNS-APIs	150+
lego	Go	Single Binary, CI/CD-freundlich	100+
Caddy	Go	Zertifikate komplett automatisch	integriert
Traefik	Go	Labels im Docker-Compose	integriert

acme.sh ist der Favorit für Shared-Hosting und Non-Root-Setups:

curl https://get.acme.sh | sh -s [email protected]
~/.acme.sh/acme.sh --issue --dns dns_cf -d example.com -d '*.example.com'
~/.acme.sh/acme.sh --install-cert -d example.com \
  --key-file /etc/nginx/ssl/example.key \
  --fullchain-file /etc/nginx/ssl/example.crt \
  --reloadcmd "systemctl reload nginx"

Traefik und Caddy verwalten Zertifikate ohne jede Konfiguration — bei Caddy reicht example.com { reverse_proxy localhost:3000 }. Für Gameserver-Panels mit Reverse-Proxy ist das oft die schnellste Lösung. Nachteil: weniger Kontrolle über Key-Typ und Renewal-Zeitpunkt, was bei ARI-basierten kurzen Laufzeiten an Bedeutung gewinnt.

Kosten-Vergleich: Let's Encrypt vs. kommerzielle CAs

Let's Encrypt kostet 0 € — auch 2026, finanziert durch Sponsoren der ISRG. Es gibt keine versteckten Limits außer den Rate Limits, keine Registrierungspflicht, keine Abo-Falle.

Zertifikatstyp	Let's Encrypt	Kommerziell
DV Single Domain	0 €	10–40 €/Jahr
DV Wildcard	0 €	50–150 €/Jahr
OV Single Domain	nicht verfügbar	80–200 €/Jahr
EV	nicht verfügbar	200–500 €/Jahr
Multi-Domain (SAN)	0 € (bis 100 SANs)	150–400 €/Jahr

Wann sich eine kommerzielle CA trotzdem lohnt: bei OV- und EV-Zertifikaten für Banken, Behörden oder Enterprise-Beschaffung, wo eine organisatorische Validierung gefordert wird. Ebenso bei sehr langen Laufzeiten — kommerzielle CAs bieten bis zu zwei Jahre, was bei starren Change-Prozessen hilft.

Für die überwiegende Mehrheit aller Webhosting-, Gameserver- und DevOps-Setups ist Let's Encrypt 2026 die richtige Wahl. Der einzige echte Nachteil bleibt die kurze Laufzeit — und die ist mit Certbot, systemd-Timer und ARI in unter zehn Minuten gelöst.

FAQ

Wie lange sind Let's Encrypt Zertifikate 2026 gültig?

Standardmäßig 90 Tage, aber Let's Encrypt hat angekündigt, die Standard-Laufzeit auf 45 Tage zu senken. Zusätzlich gibt es Short-Lived Certificates mit 6 Tagen Laufzeit. In allen Fällen ist automatisches Renewal Pflicht — Certbot erneuert standardmäßig 30 Tage vor Ablauf und nutzt ARI, um den Zeitpunkt dynamisch anzupassen.

Kostet Let's Encrypt 2026 etwas?

Nein. Let's Encrypt stellt DV-Zertifikate inklusive Wildcards kostenlos aus. Die Finanzierung läuft über Spenden und Sponsoren der ISRG. Es gibt keine Premium-Tier, keine Zertifikatsgebühren und keine versteckten Kosten — lediglich die dokumentierten Rate Limits.

Brauche ich für ein Wildcard-Zertifikat zwingend DNS-01?

Ja. Let's Encrypt stellt Wildcards ausschließlich über die DNS-01-Challenge aus, weil HTTP-01 technisch nicht zwischen Subdomains unterscheiden kann. Ihr braucht dafür API-Zugang zu eurem DNS-Provider, etwa Cloudflare, Hetzner, INWX oder Route 53.

Warum funktioniert OCSP Stapling mit Let's Encrypt nicht mehr?

Let's Encrypt hat den OCSP-Responder im Mai 2025 abgeschaltet und setzt stattdessen auf CRL und kurze Zertifikatslaufzeiten. ssl_stapling on; in nginx ist damit wirkungslos und kann entfernt werden — ein Sicherheitsverlust entsteht dadurch nicht, da die kurzen Laufzeiten den Revocation-Bedarf ohnehin reduzieren.

Was passiert, wenn ich das Rate Limit von Let's Encrypt reiße?

Ihr bekommt HTTP 429 mit einem Retry-After-Header. Das Duplicate-Certificate-Limit (5 pro Woche) ist am schmerzhaftesten, weil es eine volle Woche gilt. Nutzt zum Testen immer --dry-run oder --test-cert gegen das Staging-Environment, das eigene, deutlich höhere Limits hat.