Ein gültiges TLS-Zertifikat kostet 2026 keinen Cent mehr, und die Einrichtung dauert weniger als 15 Minuten. Let’s Encrypt hat das Web umgekrempelt: Wo Administratoren früher dreistellige Beträge pro Jahr und Domain zahlten, stellt die gemeinnützige Internet Security Research Group (ISRG) Zertifikate kostenlos, automatisiert und in Sekunden aus. Diese Anleitung führt Sie in 12 klar nummerierten Schritten durch die komplette Einrichtung mit Certbot, von der Installation über das erste Nginx- und Apache-Zertifikat bis zu Wildcard-Zertifikaten per DNS-01 und der vollautomatischen Erneuerung.
Wir nutzen ausschließlich Daten und Verfahren aus 2025 und 2026. Dazu gehören die neuen sechstägigen Kurzläufer-Zertifikate, die Zertifikate für reine IP-Adressen und die Umstellung von OCSP auf Sperrlisten (CRL). Am Ende steht ein vollständiges, lauffähiges Beispielprojekt: ein abgesicherter Nginx-Reverse-Proxy mit automatischer HTTPS-Erneuerung. Dazu kommen 6 typische Fehler, 8 Troubleshooting-Fälle und fortgeschrittene Tipps für den Produktivbetrieb.
Let’s Encrypt 2026: Was sich gerade geändert hat
Let’s Encrypt ist ein Projekt der gemeinnützigen Internet Security Research Group (ISRG) und zählt zu den größten Zertifizierungsstellen der Welt. Das Vertrauensanker-Zertifikat heißt ISRG Root X1, darunter rotiert die CA aktuell acht Zwischenzertifikate. Für Administratoren im DACH-Raum ist die Kernbotschaft simpel: Zertifikate sind kostenlos, automatisch erneuerbar und in allen gängigen Browsern und Betriebssystemen vorinstalliert.
2025 und 2026 brachten mehrere Änderungen, die Sie kennen sollten, bevor Sie loslegen. Die wichtigste betrifft die Lebensdauer: Neben dem klassischen 90-Tage-Zertifikat gibt es jetzt ein Profil für sechstägige Kurzläufer-Zertifikate. Solche Kurzläufer reduzieren das Risiko bei kompromittierten Schlüsseln drastisch, setzen aber zwingend eine funktionierende Automatisierung voraus. Wer noch manuell erneuert, sollte die Finger davon lassen.
Ebenfalls neu: Let’s Encrypt stellt seit 2025 Zertifikate für reine IP-Adressen aus. Das ist nützlich für interne Dienste, Mailgateways oder Hosts ohne Domainnamen. Auf der Betriebsseite hat die CA 2025 den OCSP-Dienst eingestellt und setzt nun auf Zertifikatssperrlisten (CRL). Auch die Ablauf-Erinnerungsmails wurden mitte 2025 abgeschaltet. Die klare Konsequenz: Verlassen Sie sich nie auf eine E-Mail, sondern auf eine robuste automatische Erneuerung. Genau die richten wir in dieser Anleitung ein.
| Eigenschaft | Klassisch | Kurzläufer (2025/26) | IP-Zertifikat (2025) |
|---|---|---|---|
| Gültigkeit | 90 Tage | 6 Tage | 6 Tage |
| Profilname | classic / tlsserver | shortlived | shortlived |
| Erneuerung empfohlen ab | Tag 60 | alle 2 bis 3 Tage | alle 2 bis 3 Tage |
| Automatisierung | dringend empfohlen | zwingend | zwingend |
| Anwendungsfall | Standard-Websites | Hochsicherheit | Dienste ohne Domain |
| Validierung | HTTP-01 / DNS-01 | HTTP-01 / DNS-01 | HTTP-01 / TLS-ALPN-01 |
Voraussetzungen: Diese Versionen brauchen Sie
Bevor Sie das erste Zertifikat ausstellen, müssen einige Grundlagen stimmen. Diese Anleitung geht von einem Linux-Server mit Root- oder sudo-Zugriff aus, weil das die häufigste Umgebung im DACH-Hosting ist. Die Befehle funktionieren analog auf macOS; für Windows-Server gibt es weiter unten einen eigenen Hinweis auf win-acme.
- Betriebssystem: Ubuntu 24.04 LTS oder 22.04 LTS, Debian 12, oder eine vergleichbare Linux-Distribution. macOS 14+ funktioniert ebenfalls.
- Webserver: Nginx (ab Version 1.18) oder Apache (ab 2.4). Den Webserver-Typ brauchen Sie für die passenden Certbot-Plugins.
- Certbot: die aktuelle Version, installiert über Snap. Snap liefert immer die neueste stabile Ausgabe inklusive automatischer Updates.
- Domain: eine registrierte Domain (zum Beispiel
beispiel.de), deren A- oder AAAA-Record auf die öffentliche IP des Servers zeigt. - Offene Ports: Port 80 (TCP) für die HTTP-01-Validierung und Port 443 (TCP) für HTTPS. Beide müssen aus dem Internet erreichbar sein.
- Gültige E-Mail: für Kontowarnungen, etwa bei dringenden Sicherheitsmeldungen der ISRG.
Prüfen Sie zuerst, ob Ihre Domain korrekt aufgelöst wird. Ein falscher DNS-Eintrag ist die mit Abstand häufigste Fehlerquelle. Der folgende Befehl zeigt, auf welche IP Ihre Domain zeigt:
# DNS-Auflösung prüfen
dig +short beispiel.de A
dig +short www.beispiel.de A
# Erwartete Ausgabe: die öffentliche IP Ihres Servers, z. B.
# 203.0.113.42
# Erreichbarkeit von Port 80 testen
curl -I http://beispiel.deStimmt die ausgegebene IP nicht mit der Server-IP überein, korrigieren Sie zuerst den DNS-Eintrag bei Ihrem Provider und warten Sie, bis die Änderung propagiert ist. Erst danach lohnt sich der nächste Schritt. Wer das überspringt, läuft direkt in eine fehlgeschlagene Validierung.
Wie das ACME-Protokoll und Certbot zusammenarbeiten
Die Automatisierung hinter Let’s Encrypt basiert auf dem ACME-Protokoll (Automatic Certificate Management Environment), standardisiert in RFC 8555. Certbot ist der offizielle ACME-Client der Electronic Frontier Foundation (EFF). Vereinfacht läuft der Ablauf so: Certbot erzeugt ein Schlüsselpaar, fordert bei Let’s Encrypt ein Zertifikat an und muss anschließend beweisen, dass Sie tatsächlich die Kontrolle über die Domain haben. Diesen Beweis nennt man Challenge.
Es gibt drei Challenge-Typen, und die Wahl entscheidet über den weiteren Verlauf. HTTP-01 legt eine Datei unter einem bestimmten Pfad ab, die Let’s Encrypt über Port 80 abruft. DNS-01 hinterlegt einen TXT-Record in Ihrer Zone und ist die einzige Methode für Wildcard-Zertifikate. TLS-ALPN-01 nutzt eine spezielle TLS-Erweiterung auf Port 443 und ist vor allem für Reverse-Proxys interessant. Die folgende Tabelle ordnet die Verfahren ein.
| Challenge | Port | Wildcard möglich | Ideal für | Nachteil |
|---|---|---|---|---|
| HTTP-01 | 80 | Nein | einzelne Websites | Port 80 muss offen sein |
| DNS-01 | 53 (DNS) | Ja | Wildcards, interne Hosts | API-Zugang zum DNS nötig |
| TLS-ALPN-01 | 443 | Nein | Reverse-Proxys | kein Webserver-Plugin |
Für die meisten Websites ist HTTP-01 die einfachste Wahl, weil Certbot mit den Nginx- und Apache-Plugins alles automatisch erledigt: Validierung, Eintrag in die Serverkonfiguration und Neustart. Wildcard-Zertifikate wie *.beispiel.de erfordern dagegen zwingend DNS-01. Behalten Sie außerdem die Limits im Blick: Let’s Encrypt erlaubt 50 Zertifikate pro registrierter Domain in 7 Tagen, und ein einzelnes Zertifikat darf bis zu 100 Identifier (DNS-Namen oder IP-Adressen) enthalten. Wer beim Testen zu oft wiederholt, sperrt sich selbst aus. Nutzen Sie dafür die Staging-Umgebung, dazu später mehr.
Schritt 1 bis 3: Certbot über Snap installieren
Schritt 1: System aktualisieren und alte Pakete entfernen. Auf Ubuntu und Debian wird Certbot offiziell über Snap installiert, nicht mehr über apt. Entfernen Sie zuerst eventuell vorhandene apt-Pakete, damit es keine Versionskonflikte gibt.
# Schritt 1: System aktualisieren
sudo apt update && sudo apt upgrade -y
# Alte apt-Version von Certbot entfernen, falls vorhanden
sudo apt remove certbot -y
# snapd installieren (auf Ubuntu meist vorhanden)
sudo apt install snapd -y
sudo snap install core
sudo snap refresh coreSchritt 2: Certbot per Snap installieren. Der folgende Befehl holt die aktuelle stabile Version und hält sie über die Snap-Automatik selbstständig aktuell. Mit dem Symlink wird der Befehl certbot systemweit verfügbar.
# Schritt 2: Certbot installieren
sudo snap install --classic certbot
# Symlink anlegen, damit "certbot" im PATH liegt
sudo ln -s /snap/bin/certbot /usr/bin/certbot
# Version prüfen
certbot --version
# Beispielausgabe: certbot 3.x.xSchritt 3: Webserver-Plugin freigeben. Die Plugins für Nginx und Apache sind im Snap bereits enthalten. Falls Sie ein DNS-Plugin für Wildcard-Zertifikate brauchen, installieren Sie es separat und verbinden es mit Certbot. Beispiel für Cloudflare:
# Schritt 3: DNS-Plugin (Beispiel Cloudflare) installieren
sudo snap set certbot trust-plugin-with-root=ok
sudo snap install certbot-dns-cloudflare
# Verfügbare Plugins anzeigen
certbot pluginsDie Ausgabe von certbot plugins listet unter anderem nginx, apache und das eben installierte dns-cloudflare auf. Damit ist die Werkzeugkette komplett. In den nächsten Schritten stellen wir das erste echte Zertifikat aus.
Schritt 4 bis 6: Erstes Nginx-Zertifikat ausstellen
Schritt 4: Mit der Staging-Umgebung testen. Bevor Sie ein echtes Zertifikat anfordern, sollten Sie den Ablauf gegen das Staging-System testen. Staging hat großzügige Limits und schützt Sie vor einer Sperre durch zu viele Fehlversuche. Das Zertifikat ist nicht öffentlich vertrauenswürdig, der Ablauf ist aber identisch.
# Schritt 4: Testlauf gegen die Staging-Umgebung
sudo certbot --nginx \
--staging \
-d beispiel.de -d www.beispiel.de \
--agree-tos \
-m [email protected] \
--no-eff-email
# Erfolg sieht so aus:
# The dry run was successful.
# Congratulations! Your certificate (staging) has been issued.Schritt 5: Das echte Zertifikat anfordern. Lief der Staging-Test sauber durch, entfernen Sie das Flag --staging und fordern das produktive Zertifikat an. Certbot trägt es automatisch in die Nginx-Konfiguration ein, richtet die Weiterleitung von HTTP auf HTTPS ein und lädt Nginx neu.
# Schritt 5: Produktives Zertifikat ausstellen
sudo certbot --nginx \
-d beispiel.de -d www.beispiel.de \
--agree-tos \
-m [email protected] \
--no-eff-email \
--redirect
# Ergebnis:
# Successfully received certificate.
# Certificate is saved at: /etc/letsencrypt/live/beispiel.de/fullchain.pem
# Key is saved at: /etc/letsencrypt/live/beispiel.de/privkey.pem
# This certificate expires on 2026-09-12.Schritt 6: Das Ergebnis prüfen. Rufen Sie Ihre Domain im Browser per https:// auf. Sie sollten ein gültiges Schloss-Symbol sehen. Auf der Kommandozeile prüfen Sie das Zertifikat so:
# Schritt 6: Zertifikat und Kette prüfen
echo | openssl s_client -connect beispiel.de:443 -servername beispiel.de 2>/dev/null \
| openssl x509 -noout -issuer -subject -dates
# Beispielausgabe:
# issuer=C=US, O=Let's Encrypt, CN=R11
# subject=CN=beispiel.de
# notBefore=Jun 14 09:00:00 2026 GMT
# notAfter=Sep 12 09:00:00 2026 GMTSehen Sie als Aussteller (issuer) Let’s Encrypt und eine Restlaufzeit von rund 90 Tagen, ist alles korrekt. Für eine ausführliche externe Bewertung der TLS-Konfiguration nutzen Sie den kostenlosen SSL Labs Server Test, der Ihnen eine Note von A+ bis F gibt.
Schritt 7 bis 9: Apache-Zertifikat einrichten
Apache funktioniert nach demselben Prinzip, nutzt aber das Apache-Plugin. Voraussetzung ist ein konfigurierter VirtualHost mit dem korrekten ServerName, denn Certbot liest diesen Wert aus, um die passende Konfigurationsdatei zu finden.
Schritt 7: Apache und das Plugin vorbereiten. Stellen Sie sicher, dass die Module für SSL und Header aktiv sind. Das Apache-Plugin steuert Apache anschließend selbst.
# Schritt 7: Apache-Module aktivieren
sudo a2enmod ssl
sudo a2enmod headers
sudo systemctl restart apache2
# Prüfen, ob der VirtualHost den richtigen ServerName hat
sudo apache2ctl -SSchritt 8: Zertifikat für Apache ausstellen. Der Aufruf ist nahezu identisch zu Nginx, nur das Plugin wechselt von --nginx auf --apache.
# Schritt 8: Zertifikat über das Apache-Plugin
sudo certbot --apache \
-d beispiel.de -d www.beispiel.de \
--agree-tos \
-m [email protected] \
--no-eff-email \
--redirectSchritt 9: Nur Zertifikat holen, Konfiguration selbst pflegen. Wer die Webserver-Konfiguration manuell verwaltet, etwa in einer Versionsverwaltung, nutzt den Modus certonly. Certbot stellt dann nur das Zertifikat aus und fasst die Server-Dateien nicht an.
# Schritt 9: Nur Zertifikat ausstellen (webroot-Methode)
sudo certbot certonly --webroot \
-w /var/www/beispiel \
-d beispiel.de -d www.beispiel.de \
--agree-tos -m [email protected] --no-eff-email
# Die Pfade danach manuell in die Konfiguration eintragen:
# SSLCertificateFile /etc/letsencrypt/live/beispiel.de/fullchain.pem
# SSLCertificateKeyFile /etc/letsencrypt/live/beispiel.de/privkey.pemDie certonly-Methode ist die robusteste Variante für komplexe Setups, weil sie Certbot von der Webserver-Konfiguration entkoppelt. Sie eignet sich auch für Dienste, die kein Webserver-Plugin haben, etwa Mailserver oder Datenbanken mit TLS.
Schritt 10 bis 12: Wildcard-Zertifikat per DNS-01
Ein Wildcard-Zertifikat wie *.beispiel.de deckt alle Subdomains mit einem einzigen Zertifikat ab. Das spart Verwaltungsaufwand und schont das Limit von 50 Zertifikaten pro Woche. Der Haken: Wildcards erfordern zwingend die DNS-01-Validierung, also einen TXT-Record in Ihrer Zone. Vollautomatisch geht das nur mit einem DNS-Plugin und API-Zugang zu Ihrem DNS-Provider.
Schritt 10: API-Zugangsdaten hinterlegen. Erstellen Sie bei Ihrem DNS-Provider einen API-Token mit Schreibrechten für die Zone und speichern ihn in einer geschützten Datei. Beispiel für Cloudflare:
# Schritt 10: Cloudflare-Token sicher ablegen
sudo mkdir -p /etc/letsencrypt/secrets
echo "dns_cloudflare_api_token = IHR_API_TOKEN" \
| sudo tee /etc/letsencrypt/secrets/cloudflare.ini
# Strenge Rechte setzen (nur root darf lesen)
sudo chmod 600 /etc/letsencrypt/secrets/cloudflare.iniSchritt 11: Wildcard-Zertifikat anfordern. Geben Sie sowohl die Wildcard als auch die nackte Domain an, da *.beispiel.de die Domain beispiel.de selbst nicht einschließt.
# Schritt 11: Wildcard-Zertifikat per DNS-01
sudo certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/secrets/cloudflare.ini \
-d "beispiel.de" -d "*.beispiel.de" \
--agree-tos -m [email protected] --no-eff-email
# Certbot setzt den TXT-Record automatisch:
# _acme-challenge.beispiel.de TXT "abc123..."
# und entfernt ihn nach der Prüfung wieder.Schritt 12: DNS-Propagation berücksichtigen. Manche Provider brauchen länger, bis der TXT-Record sichtbar ist. Mit --dns-cloudflare-propagation-seconds geben Sie Certbot mehr Zeit. Bei langsamen Zonen helfen 60 Sekunden.
# Schritt 12: Längere Wartezeit für die DNS-Propagation
sudo certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/secrets/cloudflare.ini \
--dns-cloudflare-propagation-seconds 60 \
-d "beispiel.de" -d "*.beispiel.de" \
--agree-tos -m [email protected] --no-eff-emailOhne API-Plugin lässt sich DNS-01 auch manuell durchführen (--manual --preferred-challenges dns). Certbot zeigt dann den zu setzenden TXT-Record an und wartet, bis Sie ihn eingetragen haben. Das ist für einmalige Zertifikate in Ordnung, eignet sich aber nicht für die automatische Erneuerung, weil bei jedem Lauf manuelle Eingriffe nötig wären.
Automatische Erneuerung mit systemd-Timer einrichten
Da Let’s Encrypt keine Ablauf-Erinnerungen mehr verschickt, ist die automatische Erneuerung kein Komfort, sondern Pflicht. Bei einer Snap-Installation richtet Certbot den Erneuerungsmechanismus selbst ein. Mit dem folgenden Befehl prüfen Sie, ob der Timer aktiv ist:
# Aktive Certbot-Timer anzeigen
systemctl list-timers | grep certbot
# Beispielausgabe:
# snap.certbot.renew.timer ... snap.certbot.renew.service
# Erneuerung testen, ohne wirklich zu erneuern (Trockenlauf)
sudo certbot renew --dry-runDer Befehl certbot renew erneuert nur Zertifikate, deren Restlaufzeit unter 30 Tage fällt. Er ist absichtlich idempotent: Sie können ihn beliebig oft laufen lassen, ohne unnötig neue Zertifikate anzufordern. Genau deshalb läuft er zweimal täglich, ohne das Wochenlimit zu sprengen. Verlief der Trockenlauf erfolgreich, ist Ihr Server für Jahre versorgt.
Auf Systemen ohne systemd, etwa in manchen Containern, richten Sie die Erneuerung per Cron ein. Wichtig ist der zufällige Versatz (sleep), damit nicht alle Server der Welt gleichzeitig anfragen:
# Cron-Job als root: /etc/cron.d/certbot
# Zweimal täglich, mit zufälligem Versatz bis 8 Stunden
0 */12 * * * root sleep $(( RANDOM \% 28800 )) && certbot renew --quiet \
--deploy-hook "systemctl reload nginx"Der --deploy-hook ist entscheidend: Er lädt den Webserver nur dann neu, wenn tatsächlich ein neues Zertifikat ausgestellt wurde. Ohne diesen Schritt würde der Server weiter das alte Zertifikat aus dem Speicher servieren, obwohl auf der Platte längst ein neues liegt. Das ist ein klassischer Fehler, der erst beim Ablauf auffällt, also im schlechtesten Moment.
Vollständiges Beispielprojekt: Nginx-Reverse-Proxy mit TLS
Jetzt fügen wir alles zu einem lauffähigen Projekt zusammen: ein Nginx-Reverse-Proxy, der eine im Hintergrund laufende Anwendung (etwa eine Node.js-App auf Port 3000) per HTTPS nach außen anbietet, inklusive moderner TLS-Einstellungen und Sicherheits-Header. Legen Sie zuerst die Serverkonfiguration an.
# /etc/nginx/sites-available/beispiel.de
server {
listen 80;
server_name beispiel.de www.beispiel.de;
# Let's Encrypt HTTP-01 Challenge zulassen
location /.well-known/acme-challenge/ { root /var/www/html; }
# alles andere auf HTTPS umleiten
location / { return 301 https://$host$request_uri; }
}
server {
listen 443 ssl http2;
server_name beispiel.de www.beispiel.de;
ssl_certificate /etc/letsencrypt/live/beispiel.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/beispiel.de/privkey.pem;
# Moderne TLS-Einstellungen
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m;
# Sicherheits-Header
add_header Strict-Transport-Security "max-age=63072000" always;
add_header X-Content-Type-Options nosniff always;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
}
}Aktivieren Sie die Konfiguration, prüfen Sie die Syntax und laden Sie Nginx neu. Der Syntaxtest vor dem Reload verhindert, dass ein Tippfehler den gesamten Webserver lahmlegt.
# Konfiguration aktivieren
sudo ln -s /etc/nginx/sites-available/beispiel.de \
/etc/nginx/sites-enabled/
# Syntax prüfen, dann neu laden
sudo nginx -t
sudo systemctl reload nginx
# Zertifikat ausstellen (HTTP-01 nutzt den well-known-Pfad oben)
sudo certbot --nginx -d beispiel.de -d www.beispiel.de \
--agree-tos -m [email protected] --no-eff-email --redirectDamit haben Sie einen produktionsreifen Reverse-Proxy: HTTP-Anfragen werden auf HTTPS umgeleitet, die Verbindung nutzt TLS 1.2 und 1.3, HSTS erzwingt verschlüsselte Folgeaufrufe, und die automatische Erneuerung hält das Zertifikat dauerhaft gültig. Diese Vorlage lässt sich für beliebige Backend-Dienste anpassen, indem Sie den proxy_pass-Zielport ändern. Wenn Sie tiefer verstehen wollen, was hinter dem Schloss-Symbol passiert, lesen Sie unseren Beitrag zu HTTPS und TLS.
6 häufige Fehler und wie Sie sie vermeiden
Die meisten Probleme mit Let’s Encrypt entstehen nicht durch Certbot selbst, sondern durch das Umfeld: DNS, Firewall, Limits. Diese sechs Fehler sehen wir am häufigsten.
- Port 80 geschlossen: HTTP-01 braucht Port 80, auch wenn die Seite nur über HTTPS läuft. Eine Cloud-Firewall oder ein Security-Group-Eintrag, der Port 80 blockt, lässt die Validierung scheitern. Öffnen Sie 80 und 443 eingehend.
- DNS zeigt woanders hin: Wenn der A-Record auf einen CDN oder eine alte IP zeigt, validiert Let’s Encrypt den falschen Server. Prüfen Sie immer zuerst mit
dig. - Limit überschritten: Wer beim Testen das Flag
--stagingvergisst, brennt schnell die 50 Zertifikate pro Woche durch und wird gesperrt. Testen Sie ausschließlich im Staging. - Wildcard ohne DNS-01: Ein Wildcard-Zertifikat per HTTP-01 anzufordern, schlägt zwangsläufig fehl. Wildcards gehen nur über DNS-01.
- Reload vergessen: Nach manueller Erneuerung ohne
--deploy-hookserviert der Webserver weiter das alte Zertifikat. Immer einen Reload-Hook setzen. - Privater Schlüssel im Repo: Niemals
/etc/letsencrypt/oderprivkey.pemin eine Versionsverwaltung einchecken. Der private Schlüssel gehört nur auf den Server.
Ein siebter, oft unterschätzter Punkt: Zeitsynchronisation. Stimmt die Serveruhr nicht, lehnt Let’s Encrypt die Anfrage ab, weil Zeitstempel im ACME-Protokoll geprüft werden. Aktivieren Sie NTP mit sudo timedatectl set-ntp true. Mehr Hintergrund zu Angriffsflächen falsch konfigurierter Server finden Sie in unserem Beitrag zu Datenlecks und ihren Ursachen.
Troubleshooting: 8 typische Probleme lösen
Wenn Certbot abbricht, liefert es meist eine aussagekräftige Fehlermeldung. Diese acht Fälle decken die große Mehrheit aller Supportanfragen ab.
| Fehlermeldung / Symptom | Ursache | Lösung |
|---|---|---|
| Timeout during connect (port 80) | Firewall blockt Port 80 | Port 80/443 eingehend öffnen |
| DNS problem: NXDOMAIN | A-Record fehlt oder falsch | DNS-Eintrag korrigieren, propagieren lassen |
| too many certificates already issued | Wochenlimit erreicht | bis zu 7 Tage warten, Staging nutzen |
| Challenge failed for domain | well-known-Pfad nicht erreichbar | webroot prüfen, Reverse-Proxy anpassen |
| Incorrect TXT record | DNS-Propagation zu langsam | propagation-seconds erhöhen |
| certbot: command not found | Symlink fehlt | ln -s /snap/bin/certbot /usr/bin/certbot |
| nginx: configuration test failed | Syntaxfehler in Konfig | nginx -t, Fehler beheben |
| Cert expired trotz renew | Reload-Hook fehlt | –deploy-hook setzen |
Für eine tiefere Analyse hilft das Logfile. Certbot protokolliert jeden Lauf detailliert, inklusive der genauen ACME-Antworten von Let’s Encrypt:
# Detailliertes Log einsehen
sudo tail -n 50 /var/log/letsencrypt/letsencrypt.log
# Status aller verwalteten Zertifikate anzeigen
sudo certbot certificates
# Ausgabe zeigt Domains, Ablaufdatum und Pfade:
# Certificate Name: beispiel.de
# Expiry Date: 2026-09-12 (VALID: 89 days)Tritt ein Fehler trotz korrektem DNS auf, prüfen Sie mit einem externen Dienst, ob Port 80 wirklich von außen erreichbar ist. Oft blockt eine vorgelagerte Cloud-Firewall, die in der lokalen iptables-Ansicht gar nicht auftaucht. Bei wiederholten Sperren wegen Limits ist Geduld der einzige Ausweg, denn die Zählung läuft über ein gleitendes 7-Tage-Fenster.
Fortgeschrittene Tipps für den Produktivbetrieb
Kurzläufer-Zertifikate und das ACME-Profil wählen
Die 2025 eingeführten sechstägigen Kurzläufer-Zertifikate verkürzen das Risikofenster bei einem kompromittierten Schlüssel von 90 auf 6 Tage. Voraussetzung ist eine bombenfeste Automatisierung, denn die Erneuerung muss alle zwei bis drei Tage laufen. Setzen Sie das gewünschte Profil über den Parameter --preferred-profile beim Ausstellen. Für die meisten Standard-Websites bleibt das 90-Tage-Profil die pragmatischere Wahl. Kurzläufer lohnen sich dort, wo maximale Sicherheit zählt und die Pipeline bereits vollautomatisch läuft.
OCSP, CRL und Must-Staple verstehen
2025 hat Let’s Encrypt den OCSP-Dienst eingestellt und nutzt nun Sperrlisten (CRL) zur Widerrufsprüfung. Praktisch bedeutet das: Die früher übliche OCSP-Stapling-Konfiguration in Nginx läuft ins Leere und sollte entfernt werden, um unnötige Verzögerungen zu vermeiden. Die Widerrufsprüfung übernehmen Browser jetzt über ihre eigenen, regelmäßig aktualisierten Sperrlisten. Für Betreiber ändert sich am Tagesgeschäft wenig, alte Stapling-Direktiven sollten Sie aber bereinigen.
Mehrere Server mit einem Wildcard versorgen
In Cluster-Umgebungen lohnt es sich, ein Wildcard-Zertifikat zentral auszustellen und per sicherem Kanal an alle Knoten zu verteilen, etwa über ein Secrets-Management-System. So sparen Sie Limits und vermeiden, dass jeder Knoten einzeln validiert. Der private Schlüssel muss dabei verschlüsselt übertragen und mit strengen Dateirechten (chmod 600) abgelegt werden. Wer sich generell für sichere Schlüsselverwaltung interessiert, findet weitere Grundlagen in unserem Tutorial zur GPG-Verschlüsselung mit GnuPG.
Ein letzter Tipp für Hochverfügbarkeit: Überwachen Sie die Restlaufzeit aktiv mit einem Monitoring-Check, der täglich das Ablaufdatum prüft und Alarm schlägt, falls die Restlaufzeit unter 20 Tage fällt. So fangen Sie eine kaputte Automatisierung ab, bevor das Zertifikat tatsächlich abläuft. Verlassen Sie sich nicht allein auf den Timer, sondern verifizieren Sie das Ergebnis.
Certbot-Alternativen im Vergleich
Certbot ist der offizielle und am besten dokumentierte ACME-Client, aber nicht der einzige. Je nach Umgebung kann eine Alternative besser passen. Caddy etwa bringt ACME-Automatik von Haus aus mit und stellt Zertifikate ohne jede Zusatzkonfiguration aus. acme.sh ist ein schlankes Shell-Skript ohne Python-Abhängigkeiten, ideal für minimalistische Systeme. Auf Windows-Servern ist win-acme die Standardlösung.
| Client | Sprache | Stärke | Plattform | Ideal für |
|---|---|---|---|---|
| Certbot | Python | offiziell, Plugins | Linux, macOS | Standard-Setups |
| acme.sh | Shell | keine Abhängigkeiten | Linux, BSD | minimale Systeme |
| Caddy | Go | ACME eingebaut | plattformübergreifend | neue Projekte |
| win-acme | .NET | IIS-Integration | Windows | Windows-Server |
| lego | Go | viele DNS-Provider | plattformübergreifend | DNS-01-Automatik |
Für klassische Linux-Server mit Nginx oder Apache bleibt Certbot die sicherste Wahl, weil die Webserver-Plugins die Konfiguration automatisch pflegen. Wer ein neues Projekt von Grund auf aufsetzt und ohnehin einen modernen Webserver sucht, sollte Caddy ernsthaft prüfen, da HTTPS dort der Standard ohne Mehraufwand ist. Alle genannten Clients sprechen dasselbe ACME-Protokoll und nutzen dieselben Let’s-Encrypt-Server.
Let’s Encrypt im Docker-Container betreiben
In containerisierten Umgebungen läuft die Zertifikatsverwaltung etwas anders, weil ein Container idealerweise zustandslos bleibt. Die bewährte Lösung: ein dediziertes Certbot-Volume, das die Zertifikate persistent speichert und von mehreren Containern gelesen werden kann. So überlebt das Zertifikat einen Neustart oder ein Update des Webserver-Containers. Das folgende Beispiel zeigt einen typischen Docker-Compose-Aufbau mit Nginx und Certbot.
# docker-compose.yml (Auszug)
services:
nginx:
image: nginx:1.27
ports: ["80:80", "443:443"]
volumes:
- ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
- letsencrypt:/etc/letsencrypt:ro
- certbot-www:/var/www/certbot:ro
certbot:
image: certbot/certbot:latest
volumes:
- letsencrypt:/etc/letsencrypt
- certbot-www:/var/www/certbot
# alle 12 Stunden Erneuerung versuchen
entrypoint: sh -c 'trap exit TERM; while :; do
certbot renew --webroot -w /var/www/certbot --quiet;
sleep 12h; done'
volumes:
letsencrypt:
certbot-www:Das erste Zertifikat stellen Sie einmalig mit einem separaten docker compose run-Aufruf aus, danach übernimmt der dauerhaft laufende Certbot-Container die Erneuerung. Wichtig ist, dass Nginx nach einer Erneuerung die neue Datei lädt. In Containern erreichen Sie das am saubersten, indem der Nginx-Container regelmäßig die Konfiguration neu lädt oder ein Hook den Reload auslöst. Wer Kubernetes einsetzt, greift in der Regel zu cert-manager, das ACME-Zertifikate als native Ressourcen verwaltet und die Erneuerung vollständig automatisiert. Das Prinzip bleibt identisch: ein ACME-Client, das HTTP-01- oder DNS-01-Verfahren und persistente Speicherung des privaten Schlüssels.
Ein häufiger Stolperstein in Containern ist Port 80. Während der HTTP-01-Validierung muss der Pfad /.well-known/acme-challenge/ erreichbar sein, bevor das Zertifikat existiert. Lösen Sie das, indem Nginx zunächst nur auf Port 80 lauscht und diesen Pfad ausliefert. Erst nach erfolgreicher Ausstellung aktivieren Sie den HTTPS-Block. Andernfalls entsteht ein Henne-Ei-Problem: Nginx startet nicht ohne Zertifikat, das Zertifikat kommt aber nicht ohne laufenden Nginx.
Let’s Encrypt gegen kostenpflichtige Zertifikate
Eine häufige Frage im DACH-Mittelstand lautet, ob ein kostenloses Zertifikat für geschäftskritische Seiten ausreicht oder ob es ein gekauftes sein sollte. Die technische Antwort ist eindeutig: Für die Verschlüsselung selbst gibt es keinen Unterschied. Ein Let’s-Encrypt-Zertifikat nutzt dieselben Algorithmen und bietet dieselbe Transportsicherheit wie ein DV-Zertifikat für mehrere hundert Euro im Jahr. Browser behandeln beide gleichwertig, und das Schloss-Symbol sieht identisch aus.
Unterschiede gibt es bei der Validierungsstufe. Let’s Encrypt stellt ausschließlich domainvalidierte (DV) Zertifikate aus. Wer Organisationsvalidierung (OV) oder Extended Validation (EV) benötigt, etwa aus regulatorischen Gründen im Finanzsektor, muss zu einer kommerziellen CA greifen. Auch eine vertragliche Haftungszusage oder ein deutschsprachiger Support rund um die Uhr sind bei kostenpflichtigen Anbietern üblich, bei Let’s Encrypt nicht. Für den überwiegenden Teil aller Websites, Webshops und APIs ist das aber irrelevant.
| Kriterium | Let’s Encrypt | Kommerzielle CA (DV) | Kommerzielle CA (OV/EV) |
|---|---|---|---|
| Preis pro Jahr | 0 € | ca. 5 bis 50 € | ca. 100 bis 400 € |
| Verschlüsselungsstärke | identisch | identisch | identisch |
| Validierung | nur DV | DV | OV oder EV |
| Laufzeit | 90 oder 6 Tage | bis 1 Jahr | bis 1 Jahr |
| Automatisierung | nativ (ACME) | oft manuell | meist manuell |
| Support / Haftung | Community | begrenzt | vertraglich |
Die kurze Laufzeit von Let’s Encrypt wird gelegentlich als Nachteil dargestellt, ist in der Praxis aber ein Sicherheitsgewinn: Kurzlebige Zertifikate begrenzen den Schaden, falls ein privater Schlüssel je in falsche Hände gerät. Genau deshalb bewegt sich die gesamte Branche in Richtung kürzerer Laufzeiten. Wer die Automatisierung einmal sauber aufgesetzt hat, merkt von der Erneuerung ohnehin nichts mehr. Der vermeintliche Nachteil verschwindet hinter dem Timer.
Sicherheit und Best Practices nach der Einrichtung
Ein gültiges Zertifikat allein macht eine Website nicht sicher. Es verschlüsselt die Verbindung, sagt aber nichts über die Konfiguration dahinter aus. Nach der Ausstellung sollten Sie die TLS-Einstellungen härten und regelmäßig prüfen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) veröffentlicht dazu konkrete Cyber-Sicherheitsempfehlungen.
- Nur TLS 1.2 und 1.3: Deaktivieren Sie SSLv3, TLS 1.0 und 1.1. Diese Protokolle gelten als unsicher.
- HSTS aktivieren: Der Strict-Transport-Security-Header zwingt Browser auf HTTPS und schützt vor Downgrade-Angriffen.
- Starke Cipher-Suites: Orientieren Sie sich an den Mozilla-Empfehlungen für die Konfiguration moderner Verschlüsselung.
- Schlüsselrechte prüfen:
privkey.pemdarf nur für root lesbar sein (chmod 600). - Regelmäßig testen: Lassen Sie SSL Labs monatlich gegen Ihre Domain laufen und streben Sie mindestens Note A an.
Behalten Sie außerdem im Hinterkopf, dass ein TLS-Zertifikat nur einen Teil der Angriffsfläche abdeckt. Schwache Passwörter, fehlende Updates oder offene Admin-Oberflächen bleiben unabhängig davon ein Risiko. TLS schützt die Daten auf dem Transportweg, nicht den Server selbst. Eine ganzheitliche Sicht auf Server-Härtung lohnt sich, denn Verschlüsselung ist die Basis, nicht das ganze Gebäude.
Häufige Fragen zu Let’s Encrypt und Certbot
Ist Let’s Encrypt wirklich kostenlos?
Ja, vollständig. Let’s Encrypt ist ein Projekt der gemeinnützigen ISRG und finanziert sich über Spenden und Sponsoren. Es fallen keine Gebühren an, weder für die Ausstellung noch für die Erneuerung. Die Zertifikate sind technisch und rechtlich gleichwertig mit kostenpflichtigen DV-Zertifikaten anderer Anbieter.
Wie lange sind die Zertifikate gültig?
Standardmäßig 90 Tage. Seit 2025 gibt es zusätzlich ein Profil für sechstägige Kurzläufer. Die kurze Laufzeit ist Absicht: Sie erzwingt Automatisierung und begrenzt den Schaden bei kompromittierten Schlüsseln. Mit certbot renew und einem aktiven Timer erneuern sich Zertifikate automatisch ab etwa 30 Tagen Restlaufzeit.
Bekomme ich noch E-Mails vor dem Ablauf?
Nein. Let’s Encrypt hat die Ablauf-Erinnerungsmails 2025 abgeschaltet. Verlassen Sie sich ausschließlich auf die automatische Erneuerung plus ein eigenes Monitoring, das die Restlaufzeit überwacht. Eine fehlende E-Mail darf nie der einzige Schutz vor einem abgelaufenen Zertifikat sein.
Brauche ich für jede Subdomain ein eigenes Zertifikat?
Nein. Ein Zertifikat kann bis zu 100 Identifier enthalten, also viele Subdomains gleichzeitig abdecken. Alternativ stellen Sie ein Wildcard-Zertifikat für *.beispiel.de aus, das alle Subdomains einer Ebene umfasst. Wildcards erfordern allerdings zwingend die DNS-01-Validierung.
Funktioniert Let’s Encrypt auch hinter einem CDN?
Das hängt vom CDN ab. Bei einem aktiven Cloudflare-Proxy zeigt der A-Record auf Cloudflare, nicht auf Ihren Server, sodass HTTP-01 scheitern kann. Die Lösung ist DNS-01 über das passende DNS-Plugin, weil diese Methode die TXT-Validierung in der Zone nutzt und vom CDN unabhängig ist.
Kann ich ein Zertifikat für eine IP-Adresse bekommen?
Seit 2025 ja. Let’s Encrypt stellt Zertifikate für reine IP-Adressen aus, die als Kurzläufer mit sechs Tagen Laufzeit kommen. Das ist nützlich für interne Dienste oder Hosts ohne Domainnamen. Auch hier gilt: Ohne Automatisierung ist der Betrieb wegen der kurzen Laufzeit kaum praktikabel.
Was passiert, wenn die Erneuerung fehlschlägt?
Solange die Restlaufzeit über null liegt, bleibt das alte Zertifikat gültig, und der nächste Timer-Lauf versucht es erneut. Da die Erneuerung schon ab 30 Tagen Restlaufzeit startet, bleibt ein großzügiges Zeitfenster zum Eingreifen. Prüfen Sie das Logfile unter /var/log/letsencrypt/, um die genaue Fehlerursache zu finden.
Related Coverage
- HTTPS und TLS: Wie das Schloss im Browser Sie schützt
- GPG Verschlüsselung: 12 Schritte mit GnuPG
- SSH-Key erstellen: Ed25519 in 8 Schritten
- ECDSA in Node.js: Signaturen in 11 Schritten
- Datenlecks: Wie sie entstehen und wie Sie sich schützen
- Online-Sicherheit verständlich erklärt
Quellen und weiterführende Links: letsencrypt.org, certbot.eff.org, RFC 8555 (ACME), Let’s Encrypt Rate Limits, Ankündigung 6-Tage- und IP-Zertifikate.
