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: Deine Website oder dein 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.

Genau deshalb arbeiten wir uns hier bewusst in einer sicheren Reihenfolge vor. Erst prüfen wir Domain und Erreichbarkeit, dann installieren wir certbot, dann fordern wir das Zertifikat an, danach prüfen wir die Dateien und zum Schluss testen wir die automatische Erneuerung. So versteht auch ein Einsteiger, was gerade passiert und wo ein Fehler wirklich herkommt.

Voraussetzungen

Ein Debian- oder Ubuntu-Server mit sudo-Rechten
Eine Domain oder Subdomain, die auf deinen 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 du später Nginx oder Apache direkt in die Zertifikatsanforderung einbinden willst, ist das ein eigener Folgeschritt.

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

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

ping example.com

nslookup example.com

curl -I http://example.com

Worauf du achtest:

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

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

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

Schritt 2: certbot installieren

Jetzt installierst du certbot aus den Paketquellen deiner Distribution. Vorher aktualisierst du wie gewohnt die Paketlisten.

sudo apt update
sudo apt install certbot

Danach prüfst du direkt, ob certbot sauber installiert wurde:

certbot --version

Damit stellst du 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, musst du 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 du keinen Nginx-Dienst nutzt, lässt du den Stop/Start-Schritt natürlich 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, gehst du zuerst zu DNS, Port 80 oder laufenden Diensten zurück.

Schritt 4: Zertifikatsdateien und Pfade prüfen

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

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

Typischerweise findest du dort unter anderem:

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

Diese Pfade brauchst du 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 deine 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 machst du mit:

sudo certbot renew --dry-run

Damit wird keine echte neue Live-Ausstellung verbraucht, sondern ein Testlauf gegen die Erneuerungslogik gemacht. Wenn auf deinem Server Timer genutzt werden, kannst du zusätzlich prüfen:

systemctl list-timers | grep certbot

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

Verifizieren: Der Schritt ist erfolgreich, wenn certbot renew --dry-run ohne Fehler endet. 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 brauchst du 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 du später sehr restriktiv arbeitest, musst du trotzdem sicherstellen, dass Zertifikatsverlängerungen nicht an der Firewall scheitern.

Verifizieren: Der Schritt ist erfolgreich, wenn die Firewall-Regeln nachvollziehbar gesetzt sind und du verstehst, warum Port 80 nicht nur für die erste Anforderung, sondern oft auch für die spätere Erneuerung wichtig bleibt.

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 musst du den blockierenden Dienst kurz anhalten.
renew --dry-run schlägt fehl: Dann ist das Setup nicht wirklich wartbar. Erst die Ursache klären, dann dem Live-Betrieb vertrauen.
Du findest die Zertifikatsdateien nicht: Prüfe den echten Domainordner unter /etc/letsencrypt/live/ und achte darauf, dass du den exakten Domainnamen verwendest.

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?

Du testest die Erneuerungslogik, ohne dich auf eine echte Ablauffrist verlassen zu müssen. Das ist der wichtigste Wartungstest des ganzen Setups.

Wo liegen Zertifikat und Schlüssel?

Normalerweise unter /etc/letsencrypt/live/DEINE-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, hast du 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.