Let's Encrypt mit certbot ermöglicht es dir, kostenlose TLS-Zertifikate direkt am Dienst auszustellen und automatisch zu erneuern – ganz ohne Reverse-Proxy wie Caddy oder den Nginx-Proxy-Manager. Diese Anleitung zeigt dir die Installation via snap (offiziell empfohlen) sowie apt, die wichtigsten Challenge-Methoden (--standalone, --webroot, Nginx-/Apache-Plugin und DNS-01 für Wildcards) und wie du die automatische Erneuerung per systemd-Timer oder Cron zuverlässig betreibst.

Kurzfassung: certbot via sudo snap install --classic certbot installieren, Zertifikat mit sudo certbot certonly --standalone -d example.com oder --webroot ausstellen, Deploy-Hook für den Dienst-Reload anlegen und den automatischen Timer mit sudo certbot renew --dry-run testen.

Voraussetzungen

Ubuntu 20.04/22.04/24.04 oder Debian 11/12 (als root oder mit sudo)
Öffentliche IP-Adresse und ein DNS-A-Eintrag, der auf deinen Server zeigt
Port 80 (und optional 443) in der Firewall erreichbar
Kein anderer Prozess belegt Port 80, wenn du --standalone nutzt
snapd installiert (bei Ubuntu ab 16.04 standardmäßig vorhanden)

Schritt 1: certbot installieren

Die offiziell empfohlene Methode ist die Installation über snap. Snap bringt automatische Updates mit und stellt sicher, dass stets die aktuelle certbot-Version läuft. Die apt-Installation liefert dagegen die Paketstand-Version der Distribution, die oft älter ist.

Option A: snap (empfohlen)

# Altes certbot-Paket entfernen (falls vorhanden)
sudo apt remove certbot

# certbot via snap installieren
sudo snap install --classic certbot

# Symlink für einfachen Aufruf anlegen
sudo ln -s /snap/bin/certbot /usr/bin/certbot

# Version prüfen
certbot --version

Option B: apt (ältere Version)

sudo apt update
sudo apt install certbot

Hinweis zu Plugins: Wenn du certbot über snap installierst, musst du auch alle Plugins (z. B. für Nginx oder Apache) über snap beziehen – nicht per pip oder apt. Sonst meldet certbot „Plugin not found“.

# Nginx-Plugin für snap-certbot
sudo snap install certbot-nginx

# Apache-Plugin für snap-certbot
sudo snap install certbot-apache

Schritt 2: Zertifikat mit --standalone ausstellen

Der --standalone-Modus startet einen eigenen Mini-Webserver auf Port 80, um die HTTP-01-Challenge zu beantworten. Läuft auf deinem Server bereits ein Webserver (Nginx, Apache), musst du ihn während der Ausstellung kurz stoppen oder direkt --webroot verwenden (Schritt 3).

# Webserver stoppen (falls nötig)
sudo systemctl stop nginx

# Zertifikat ausstellen
sudo certbot certonly --standalone -d example.com -d www.example.com

# Webserver wieder starten
sudo systemctl start nginx

Nach erfolgreicher Ausstellung liegen die Dateien unter /etc/letsencrypt/live/example.com/:

/etc/letsencrypt/live/example.com/
  cert.pem       – Zertifikat (ohne Chain)
  chain.pem      – Intermediate-Zertifikate
  fullchain.pem  – cert.pem + chain.pem (für Nginx/Apache empfohlen)
  privkey.pem    – Privater Schlüssel (chmod 600)

/etc/letsencrypt/archive/example.com/
  – tatsächliche Dateien, /live/ sind Symlinks darauf

Schritt 3: Zertifikat mit --webroot ausstellen (Zero-Downtime)

Der --webroot-Modus schreibt die Challenge-Dateien in ein Verzeichnis, das dein laufender Webserver ausliefert. Port 80 bleibt belegt, es gibt keine Downtime. Du musst certbot das Document-Root-Verzeichnis mitteilen.

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

Wenn du mehrere Domains mit unterschiedlichen Webroot-Pfaden hast:

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

Nginx-Konfiguration für .well-known: Stelle sicher, dass dein Nginx-VHost das Verzeichnis .well-known/acme-challenge/ ausliefert. Standardmäßig ist das bei einem normalen root-Eintrag bereits der Fall. Falls du einen Catch-All-Redirect von HTTP auf HTTPS hast, musst du diesen für den Challenge-Pfad ausklammern:

server {
    listen 80;
    server_name example.com www.example.com;

    # Challenge-Pfad ausklammern
    location /.well-known/acme-challenge/ {
        root /var/www/html;
    }

    # Alle anderen Requests auf HTTPS umleiten
    location / {
        return 301 https://$host$request_uri;
    }
}

Schritt 4: Nginx- und Apache-Plugins nutzen

Die Plugins --nginx und --apache erledigen zwei Dinge auf einmal: Sie stellen das Zertifikat aus und passen die Serverkonfiguration automatisch an. Das ist praktisch für eine schnelle Einrichtung, ändert aber deine bestehenden Konfigurationsdateien.

# Nginx: Zertifikat ausstellen + Konfiguration anpassen
sudo certbot --nginx -d example.com -d www.example.com

# Apache: Zertifikat ausstellen + Konfiguration anpassen
sudo certbot --apache -d example.com -d www.example.com

Wenn du nur das Zertifikat willst, die Konfiguration aber selbst verwaltest, nutze stattdessen certonly --nginx bzw. certonly --apache – dann wird die Konfiguration nicht verändert, aber der Plugin-Webserver-Kontext wird für die Challenge genutzt.

Schritt 5: Wildcard-Zertifikate mit DNS-01-Challenge

Wildcard-Zertifikate (*.example.com) sind ausschließlich über die DNS-01-Challenge möglich – HTTP-01 funktioniert dafür nicht. Im --manual-Modus musst du den TXT-Eintrag manuell setzen; eine automatische Erneuerung ist dann nicht möglich. Für vollautomatische Wildcard-Erneuerung benötigst du ein DNS-API-Plugin deines DNS-Anbieters.

# Wildcard + Apex-Domain mit DNS-Challenge (manuell)
sudo certbot certonly \
  --manual \
  --preferred-challenges dns \
  -d example.com \
  -d '*.example.com'

certbot gibt dir einen TXT-Eintrag vor, den du bei deinem DNS-Anbieter als _acme-challenge.example.com einträgst. Warte nach dem Setzen 1–2 Minuten auf die DNS-Propagation, bevor du bei certbot bestätigst.

Wichtig: Im --manual-Modus läuft keine automatische Erneuerung. Für produktive Systeme empfiehlt sich ein DNS-Plugin, z. B. certbot-dns-cloudflare oder certbot-dns-route53, das die TXT-Einträge per API setzt.

Schritt 6: Deploy-Hook für automatischen Dienst-Reload

Nach einer erfolgreichen Erneuerung muss dein Dienst (Nginx, Apache, Postfix, Dovecot …) neu geladen werden, damit er das neue Zertifikat einliest. Dafür dienen Deploy-Hooks. Lege ein ausführbares Shell-Skript in /etc/letsencrypt/renewal-hooks/deploy/ ab.

# Deploy-Hook für Nginx anlegen
sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh <<'EOF'
#!/bin/bash
systemctl reload nginx
EOF

# Ausführbar machen (Pflicht!)
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Für Postfix und Dovecot auf einem Mailserver:

sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-mail.sh <<'EOF'
#!/bin/bash
systemctl reload postfix
systemctl reload dovecot
EOF

sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-mail.sh

Die Hooks in renewal-hooks/pre/ laufen vor der Erneuerung, in deploy/ nach erfolgreicher Erneuerung und in post/ immer nach dem Renewal-Versuch (auch bei Fehlern).

Achtung: Deploy-Hooks laufen bei --dry-run absichtlich nicht – das ist kein Fehler, sondern beabsichtigt.

Schritt 7: Auto-Renewal prüfen und testen

certbot erneuert Zertifikate automatisch, sobald weniger als ein Drittel ihrer Laufzeit (90 Tage → Erneuerung ab Tag 60) verbleibt. Der systemd-Timer läuft zweimal täglich und überprüft alle verwalteten Zertifikate.

Timer-Status prüfen

# Bei snap-Installation
sudo systemctl status snap.certbot.renew.timer

# Bei apt-Installation
sudo systemctl status certbot.timer

# Nächste geplante Ausführung anzeigen
sudo systemctl list-timers | grep certbot

Dry-Run: Erneuerung testen ohne echte Änderungen

sudo certbot renew --dry-run

Gibt certbot Congratulations, all simulated renewals succeeded aus, ist alles korrekt konfiguriert. Rate Limits greifen bei --dry-run nicht.

Zertifikate auflisten

sudo certbot certificates

Ausgabe enthält Domainname, Ablaufdatum, Pfade und den Status (VALID / EXPIRED).

Fallback: Cron-Job statt systemd-Timer

Wenn du lieber Cron verwendest oder kein systemd nutzt, kannst du einen Cron-Job anlegen. Weitere Grundlagen dazu findest du in der Anleitung zu cron und crontab unter Linux.

# Crontab für root öffnen
sudo crontab -e
# certbot Renewal täglich um 03:17 und 15:17 Uhr
17 3,15 * * * certbot renew --quiet

Hinweis bei snap + Timer: Snap richtet automatisch snap.certbot.renew.timer ein. Wenn du zusätzlich einen Cron-Job anlegst, laufen beide parallel. Deaktiviere dann den Timer oder den Cron-Job, um doppelte Ausführungen zu vermeiden.

Troubleshooting

Port 80 belegt bei --standalone: Ein laufender Webserver blockiert den Port. Nginx/Apache vor der Ausstellung stoppen (sudo systemctl stop nginx) oder auf --webroot wechseln.
Plugin not found (snap + apt-Plugin): certbot via snap verlangt snap-Plugins. pip- oder apt-installierte Plugins werden nicht erkannt. Plugin über sudo snap install certbot-nginx nachinstallieren.
DNS-Propagation zu langsam (DNS-01): TXT-Eintrag gesetzt, aber certbot schlägt fehl. Mindestens 1–2 Minuten warten und mit dig TXT _acme-challenge.example.com prüfen, bevor du fortfährst.
Wildcard --manual: keine automatische Erneuerung: Der manuelle DNS-01-Modus erfordert bei jeder Erneuerung manuellen Eingriff. Für Automatisierung DNS-API-Plugin des Anbieters verwenden.
Firewall blockiert Port 80/443: HTTP-01-Challenge schlägt mit Timeout fehl. sudo ufw allow 80 bzw. Firewall-Regel prüfen.
Deploy-Hook läuft nicht: Skript nicht ausführbar. sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/SKRIPTNAME.sh ausführen und Berechtigungen mit ls -la /etc/letsencrypt/renewal-hooks/deploy/ prüfen.
Falsche Webroot-Pfade: certbot-Pfad und Nginx/Apache-root-Direktive stimmen nicht überein. Challenge-Datei ist nicht erreichbar. Pfade abgleichen.
Rate Limiting (7-Tage-Sperre): Zu viele echte Ausstellungsversuche. Für Tests immer --dry-run verwenden oder den Staging-Server mit --staging nutzen.
Doppelter Timer (snap + apt parallel): Wenn beide Installationen vorhanden sind, laufen beide Timer. Einen deaktivieren: sudo systemctl disable --now certbot.timer.

Häufige Fragen

Was ist der Unterschied zwischen --standalone und --webroot?

--standalone startet einen eigenen temporären Webserver auf Port 80 und benötigt, dass kein anderer Prozess diesen Port belegt. --webroot arbeitet mit deinem laufenden Webserver zusammen, schreibt die Challenge-Dateien in das Document-Root-Verzeichnis und verursacht keine Downtime. Für produktive Server mit laufendem Webserver ist --webroot oder das Nginx-/Apache-Plugin die bessere Wahl.

Wo liegen die Zertifikatsdateien?

Unter /etc/letsencrypt/live/DEIN-DOMAIN/ findest du Symlinks auf die aktuellen Zertifikate. Die tatsächlichen Dateien liegen in /etc/letsencrypt/archive/DEIN-DOMAIN/ und werden bei jeder Erneuerung versioniert. Für Webserver-Konfigurationen immer den /live/-Pfad verwenden, da certbot die Symlinks bei der Erneuerung automatisch aktualisiert.

Wie oft wird ein Zertifikat erneuert?

Let's Encrypt-Zertifikate sind 90 Tage gültig. certbot erneuert sie automatisch, wenn weniger als ein Drittel der Laufzeit verbleibt – also ab etwa Tag 60. Der systemd-Timer läuft standardmäßig zweimal täglich und prüft, ob eine Erneuerung fällig ist.

Kann ich mehrere Domains in einem Zertifikat bündeln?

Ja. Du kannst beliebig viele -d-Parameter angeben, z. B. -d example.com -d www.example.com -d mail.example.com. Das erzeugt ein SAN-Zertifikat (Subject Alternative Names). Alle Domains müssen auf deinen Server zeigen und über HTTP erreichbar sein (bei HTTP-01).

Funktioniert certbot ohne Reverse-Proxy wie Caddy?

Ja, genau dafür ist diese Anleitung gedacht. Caddy und der Nginx-Proxy-Manager erledigen TLS intern automatisch. Wenn du certbot eigenständig nutzt, hast du die volle Kontrolle über Zertifikate und kannst sie für beliebige Dienste (Webserver, Mailserver, VPN) verwenden.

Was passiert, wenn die automatische Erneuerung fehlschlägt?

certbot protokolliert Fehler in /var/log/letsencrypt/letsencrypt.log. Let's Encrypt schickt außerdem Warn-E-Mails an die bei der Ausstellung angegebene Adresse, wenn das Zertifikat in 20 bzw. 7 Tagen abläuft. Logs kannst du mit journalctl und /var/log lesen analysieren.

Fazit

Mit certbot hast du eine ausgereifte, offiziell unterstützte Lösung, um TLS-Zertifikate von Let's Encrypt eigenständig zu verwalten. Die snap-Installation sorgt für aktuelle Versionen und automatische Updates. Die Challenge-Methode wählst du nach deiner Serverumgebung: --standalone für einfache Setups ohne laufenden Webserver, --webroot für Zero-Downtime mit bestehendem Webserver, und die Nginx-/Apache-Plugins für eine vollautomatische Konfigurationsanpassung. Deploy-Hooks sorgen dafür, dass dein Dienst nach jeder Erneuerung das neue Zertifikat einliest. Teste die Erneuerungskette regelmäßig mit certbot renew --dry-run und prüfe den systemd-Timer-Status – dann läuft die Zertifikatverwaltung dauerhaft wartungsfrei.

Weiterführende Anleitungen und Quellen

systemd-Service erstellen und verwalten – Hintergründe zu systemd-Timern, die certbot für das automatische Renewal nutzt
cron und crontab unter Linux – Cron als Alternative zum systemd-Timer für certbot renew
Logs lesen mit journalctl und /var/log – certbot-Logs bei Renewal-Fehlern auswerten
Benutzer, Gruppen, Rechte: chmod, chown und sudo – Dateiberechtigungen für Zertifikatsdateien und Hook-Skripte

Quellen: Certbot User Guide 5.6.0 (eff-certbot.readthedocs.io), EFF Certbot Instructions für Ubuntu/Debian (certbot.eff.org), Snapcraft Certbot Installation (snapcraft.io), OneUptime Blog – Certbot Auto-Renewal & Systemd Timers 2026 (oneuptime.com).