Let's Encrypt mit certbot ist für viele Linux-Server der schnellste und sauberste Weg zu einem gültigen TLS-Zertifikat. Das Ziel ist einfach: Ihre Website oder Ihr Dienst soll nicht mehr nur per HTTP, sondern per HTTPS erreichbar sein. Der eigentliche Stolperstein ist dabei selten certbot selbst, sondern fast immer die Vorbereitung: falscher DNS-Eintrag, geschlossener Port 80 oder ein anderer Dienst, der die Challenge blockiert.

Deshalb geht diese Anleitung in einer festen Reihenfolge vor: erst Domain und Erreichbarkeit prüfen, dann certbot installieren, das Zertifikat anfordern, die Dateien prüfen und zum Schluss die automatische Erneuerung testen. So versteht auch ein Einsteiger, was gerade passiert und wo ein Fehler wirklich herkommt.

Voraussetzungen

Ein Debian- oder Ubuntu-Server mit sudo-Rechten und öffentlicher IPv4- oder IPv6-Adresse. certbot selbst braucht kaum Ressourcen; 1 CPU-Kern und 1 GB RAM genügen, ein VPS mit 2 Kernen und 4 GB RAM (x86-64 oder ARM64) bietet Luft für den eigentlichen Webdienst
Eine Domain oder Subdomain, die auf Ihren Server zeigt
Von außen erreichbarer Port 80 für die HTTP-Challenge
Grundverständnis, dass TLS-Zertifikate immer an einen konkreten Domainnamen gebunden sind

Wichtig: Diese Anleitung nutzt bewusst den Standalone-Modus von certbot. Wenn Sie später Nginx oder Apache direkt in die Zertifikatsanforderung einbinden wollen, ist das ein eigener Folgeschritt.

Schritt 1: Domain, DNS und Ports sauber prüfen

Bevor Sie certbot installieren, muss klar sein: Zeigt die Domain wirklich auf Ihren Server? Und ist Port 80 erreichbar? Wenn diese beiden Punkte nicht stimmen, schlägt die Challenge später fehl, egal wie sauber Sie certbot bedienen.

ping example.com

nslookup example.com

curl -I http://example.com

Worauf Sie achten:

Die Domain sollte auf die öffentliche IP Ihres Servers zeigen
curl -I sollte zumindest irgendeine sinnvolle HTTP-Antwort liefern und nicht in einen Timeout laufen
Wenn Sie eine Firewall nutzen, muss Port 80 eingehend offen sein

Wenn Sie UFW einsetzen, passt als Grundlage unsere Anleitung Linux-Server absichern: UFW-Firewall und Fail2ban.

Verifizieren: Der Schritt ist erfolgreich, wenn Domain und Server-IP zusammenpassen und Sie über HTTP von außen grundsätzlich eine Verbindung zum Server bekommen. Ohne diese Basis geht es nicht weiter.

Schritt 2: certbot installieren

Jetzt installieren Sie certbot aus den Paketquellen Ihrer Distribution. Vorher aktualisieren Sie wie gewohnt die Paketlisten. Das certbot-Projekt empfiehlt alternativ das Snap-Paket, das neuere Versionen liefert; für den hier gezeigten Ablauf reicht das Distributionspaket.

sudo apt update
sudo apt install certbot

Danach prüfen Sie direkt, ob certbot sauber installiert wurde:

certbot --version

Damit stellen Sie sicher, dass nicht nur das Paket installiert ist, sondern das Kommando auch wirklich im Pfad verfügbar ist.

Verifizieren: Der Schritt ist erfolgreich, wenn certbot --version eine echte Versionsnummer ausgibt und keine Meldung wie command not found erscheint.

Schritt 3: Zertifikat mit Standalone-Modus anfordern

Im Standalone-Modus startet certbot kurz selbst einen kleinen Dienst auf Port 80, um die Challenge von Let's Encrypt zu beantworten. Genau deshalb darf in diesem Moment kein anderer Webserver auf Port 80 blockieren. Wenn dort schon Nginx oder Apache läuft, müssen Sie ihn für die Anforderung kurz anhalten.

Typische Befehle:

sudo systemctl stop nginx

sudo certbot certonly --standalone -d example.com -d www.example.com

sudo systemctl start nginx

Wenn Sie keinen Nginx-Dienst nutzen, lassen Sie den Stop/Start-Schritt weg oder ersetzt ihn passend. Am Ende fragt certbot unter anderem nach einer Kontakt-Mailadresse und nach der Zustimmung zu den Let's-Encrypt-Bedingungen.

Verifizieren: Der Schritt ist erfolgreich, wenn certbot ausdrücklich meldet, dass das Zertifikat erfolgreich ausgestellt wurde. Wenn stattdessen eine Challenge- oder Port-Fehlermeldung erscheint, prüfen Sie zuerst erneut DNS, Port 80 und laufende Dienste.

Schritt 4: Zertifikatsdateien und Pfade prüfen

Nach einer erfolgreichen Ausstellung legt certbot die Zertifikate unter /etc/letsencrypt/live/IHRE-DOMAIN/ ab. Für spätere Webserver-Konfigurationen müssen Sie wissen, welche Datei wofür gedacht ist.

sudo ls -l /etc/letsencrypt/live/example.com/

Typischerweise finden Sie dort unter anderem:

fullchain.pem für das Serverzertifikat plus Kette
privkey.pem für den privaten Schlüssel

Diese Pfade brauchen Sie später zum Beispiel für eine Nginx-Konfiguration. Genau dafür passt anschließend unsere Anleitung Nginx als Reverse Proxy mit TLS manuell einrichten.

Verifizieren: Der Schritt ist erfolgreich, wenn das Verzeichnis für Ihre Domain existiert und dort mindestens fullchain.pem und privkey.pem sichtbar sind.

Schritt 5: Automatische Erneuerung testen

Let's-Encrypt-Zertifikate laufen bewusst kurz. Genau deshalb ist nicht nur die Erstausstellung wichtig, sondern vor allem die saubere Erneuerung. certbot bringt dafür meist schon einen Timer oder Cron-Mechanismus mit.

Den eigentlichen Funktionstest machen Sie mit:

sudo certbot renew --dry-run

Damit wird keine echte neue Live-Ausstellung verbraucht, sondern ein Testlauf gegen die Erneuerungslogik gemacht. Wenn auf Ihrem Server Timer genutzt werden, können Sie zusätzlich prüfen:

systemctl list-timers | grep certbot

Wenn Sie die dazugehörigen Logs später nachvollziehen wollen, ist unser Grundlagenartikel Logs lesen mit journalctl und /var/log die richtige Ergänzung.

Wichtig bei laufendem Webserver: certbot merkt sich den Standalone-Modus für die Erneuerung. Belegt Nginx dann Port 80, schlägt die automatische Erneuerung fehl. Hinterlegen Sie deshalb Hooks, die den Dienst kurz anhalten; certbot speichert sie nach einem erfolgreichen Lauf für künftige Erneuerungen:

sudo certbot renew --dry-run --pre-hook "systemctl stop nginx" --post-hook "systemctl start nginx"

Verifizieren: Der Schritt ist erfolgreich, wenn certbot renew --dry-run ohne Fehler endet und systemctl list-timers | grep certbot einen Timer mit nächstem Ausführungszeitpunkt zeigt. Genau dieser Test trennt ein scheinbar fertiges Setup von einem wirklich wartbaren Setup.

Schritt 6: Firewall und Erreichbarkeit sauber absichern

Wenn das Zertifikat einmal ausgestellt ist, vergessen viele Nutzer die Rahmenbedingungen. Dabei muss Port 80 in der Praxis häufig weiterhin erreichbar bleiben, damit spätere HTTP-Challenges funktionieren. Port 443 brauchen Sie ohnehin für den eigentlichen HTTPS-Betrieb.

Bei UFW sieht das typischerweise so aus:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status

Wenn Sie später sehr restriktiv arbeiten, müssen Sie trotzdem sicherstellen, dass Zertifikatsverlängerungen nicht an der Firewall scheitern.

Verifizieren: sudo ufw status listet 80/tcp und 443/tcp mit ALLOW, und curl -I http://example.com von einem anderen Rechner liefert eine HTTP-Antwort statt eines Timeouts.

Troubleshooting

certbot meldet eine fehlgeschlagene HTTP-Challenge: Dann stimmt meist DNS, Port 80 oder die Erreichbarkeit von außen noch nicht.
Port 80 ist bereits belegt: Dann läuft dort wahrscheinlich schon Nginx oder Apache. Für den Standalone-Modus müssen Sie den blockierenden Dienst kurz anhalten, bei der Erneuerung per Pre- und Post-Hook.
renew --dry-run schlägt fehl: Dann ist das Setup nicht wirklich wartbar. Erst die Ursache klären, dann dem Live-Betrieb vertrauen.
Die Zertifikatsdateien fehlen: Prüfen Sie den echten Domainordner unter /etc/letsencrypt/live/ und achten Sie darauf, dass Sie den exakten Domainnamen verwenden.

Häufige Fragen

Brauche ich für Let's Encrypt immer Port 80?

Für die klassische HTTP-Challenge ja. Es gibt auch andere Challenge-Arten, aber für den hier gezeigten certbot-Standardweg ist Port 80 wichtig.

Warum nutze ich hier certonly statt einer direkten Webserver-Integration?

Weil dieser Artikel das Zertifikat selbst als Grundlagenbaustein erklärt. Die eigentliche Einbindung in Nginx oder Apache ist ein eigener, klarerer Schritt danach.

Was passiert bei renew --dry-run?

Sie testen die Erneuerungslogik gegen die Test-Umgebung von Let's Encrypt, ohne ein echtes Zertifikat auszustellen oder auf die Ablauffrist warten zu müssen. Das ist der wichtigste Wartungstest des ganzen Setups.

Wo liegen Zertifikat und Schlüssel?

Normalerweise unter /etc/letsencrypt/live/IHRE-DOMAIN/, typischerweise als fullchain.pem und privkey.pem.

Fazit

Ein funktionierendes Let's-Encrypt-Setup besteht nicht nur aus einem einzelnen certbot-Befehl. Die eigentliche Grundlage ist die saubere Vorbereitung: richtige Domain, offene Ports, freier Standalone-Zugriff, danach ein erfolgreicher Erneuerungstest. Wenn diese Kette sauber steht, haben Sie eine belastbare TLS-Basis für fast jede spätere Webserver- oder Reverse-Proxy-Konfiguration.

Als nächster sinnvoller Schritt passt dazu besonders Nginx als Reverse Proxy mit TLS manuell einrichten.

Weiterführende Anleitungen und Quellen

Quellen: Certbot-Dokumentation, Let's Encrypt Dokumentation, Certbot EFF Instructions.