Certbot auf Ubuntu - Dein Guide für fehlerfreies HTTPS

Ich setze auf Ubuntu fast immer auf Certbot, wenn ein Server schnell und sauber HTTPS bekommen soll. In diesem Artikel zeige ich, wie ich das Werkzeug installiere, welches Verfahren ich für Apache, Nginx, Webroot oder Standalone nehme, wie die automatische Erneuerung funktioniert und welche Fehler in der Praxis am häufigsten auftreten. So sparst du dir Experimente an der falschen Stelle und kommst direkt zu einem belastbaren SSL-Setup.

Warum Certbot auf Ubuntu in den meisten Fällen der richtige Weg ist

Für öffentliche Websites ist Zertifikatsverwaltung kein Randthema, sondern Basisbetrieb. Let’s Encrypt liefert kostenlose, vertrauenswürdige TLS-Zertifikate, und Certbot nimmt dir den nervigen Teil ab: Validierung der Domain, Ausstellung des Zertifikats und spätere Verlängerung. Technisch läuft das über ACME, also ein Protokoll, das die Domainkontrolle automatisiert nachweist und den gesamten Ablauf standardisiert.

Ich bevorzuge diesen Weg auf Ubuntu aus einem einfachen Grund: Er ist gut dokumentiert, reproduzierbar und für den Alltag robust. Klassisches SSL ist heute eigentlich nur noch ein Sprachgebrauch aus alten Zeiten; praktisch geht es um TLS, also um verschlüsselte und überprüfbare Verbindungen zwischen Browser und Server. Wenn das Setup sauber ist, merkt der Nutzer davon nur das Schloss im Browser - du als Betreiber sparst dir dagegen viel manuelle Pflege.

Wichtig ist aber die Grenze: Certbot löst das Zertifikatsproblem, nicht das Infrastrukturproblem. Wenn DNS falsch zeigt, Port 80 blockiert ist oder der Webserver nicht sauber neu lädt, scheitert die Ausstellung trotzdem. Genau deshalb lohnt sich ein klarer Ablauf statt eines Schnellschusses. Als Nächstes schaue ich deshalb auf die Frage, welcher Installationsweg unter Ubuntu wirklich sinnvoll ist.

Welcher Installationsweg auf Ubuntu sinnvoll ist

Auf Ubuntu gibt es mehrere Wege, Certbot zu betreiben, aber sie sind nicht gleich gut. In der Praxis nehme ich fast immer den Snap, außer eine Umgebung zwingt mich bewusst zu etwas anderem. Der Grund ist simpel: Aktualität, klare Paketgrenzen und eine Erneuerung, die in normalen Setups bereits mitgedacht ist.

Der offizielle Certbot-Weg auf modernen Linux-Systemen ist für mich daher klar: Snap zuerst, Alternativen nur mit Grund. Das erspart später das Durcheinander, bei dem apt und Snap parallel installiert sind und niemand mehr sicher weiß, welche Binary wirklich läuft. Wenn die Entscheidung steht, geht es an die konkrete Einrichtung.

So richte ich ein Zertifikat auf Ubuntu ein

Bevor ich den ersten Befehl ausführe, prüfe ich drei Dinge: Die Domain zeigt auf den richtigen Server, Port 80 ist von außen erreichbar, und ich habe sudo-Rechte. Ohne diese Basis scheitert die Ausstellung oft an einem Detail, das mit SSL selbst wenig zu tun hat.

Die Installation mit Snap

Auf einem aktuellen Ubuntu-Server sieht der Einstieg meistens so aus:

sudo apt update
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

Der Symlink ist vor allem dann hilfreich, wenn certbot nicht automatisch im PATH liegt. Ich lege ihn bewusst an, weil ich lieber ein eindeutiges Kommando habe als je nach Session unterschiedliche Aufrufe. Danach ist das Werkzeug einsatzbereit.

Apache und Nginx

Wenn der Webserver bereits läuft und die Website über HTTP erreichbar ist, ist der schnellste Weg meistens der beste. Für Apache nutze ich:

sudo certbot --apache

Für Nginx entsprechend:

sudo certbot --nginx

In diesen Fällen kann Certbot die Konfiguration oft direkt anpassen und HTTPS aktivieren. Das ist bequem, aber nicht magisch: Wenn die Serverkonfiguration ungewöhnlich ist, prüfe ich trotzdem jedes Detail nach dem Lauf. Wer lieber selbst an der Konfiguration bleibt, kann mit certonly nur das Zertifikat holen und die Webserver-Dateien von Hand anpassen.

Webroot, wenn ich die Kontrolle behalten will

Bei komplexeren Deployments arbeite ich gern mit Webroot. Dabei legt Certbot die Challenge-Datei in ein bestehendes Verzeichnis, das der Webserver ohnehin ausliefert. Ein typischer Aufruf sieht so aus:

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

Das ist sinnvoll, wenn ich die Webserver-Konfiguration nicht automatisch ändern möchte oder wenn mehrere Anwendungen auf demselben Host laufen. Der Nachteil ist klar: Ich muss genau wissen, welches Verzeichnis wirklich ausgeliefert wird. Schon ein falscher Pfad reicht für einen Fehlschlag.

Lesen Sie auch: SSL/TLS-Zertifikate - Der ultimative Leitfaden für sichere Websites

Standalone und DNS-01 für Sonderfälle

Wenn kein Webserver eingebunden werden soll, nutze ich gelegentlich Standalone:

sudo certbot certonly --standalone -d example.de

Das funktioniert aber nur, wenn Port 80 nicht belegt und von außen erreichbar ist. Für Wildcard-Zertifikate wie *.example.de reicht das nicht aus; dafür brauche ich DNS-Validierung. Genau dort liegt der praktische Punkt: Nicht jede Domain lässt sich mit dem gleichen Verfahren sauber lösen, und es ist besser, das früh zu erkennen, als später an einer scheinbar simplen Einrichtung zu hängen. Damit kommen wir zur Frage, die im Betrieb am meisten zählt: Wie bleibt das Zertifikat dauerhaft gültig?

Automatische Erneuerung, ohne später in Zeitdruck zu geraten

Let’s Encrypt-Zertifikate sind kurzlebig, und das ist Absicht. Ich behandle sie deshalb nicht wie ein einmaliges Projekt, sondern wie einen laufenden Prozess. Der richtige Reflex ist nicht, ein Zertifikat nur auszustellen, sondern sofort zu prüfen, ob die Verlängerung wirklich automatisch greift.

Mein Standardtest ist schlicht:

sudo certbot renew --dry-run

Damit simuliere ich die Erneuerung, ohne ein echtes Zertifikat zu verbrauchen oder die Konfiguration unnötig zu verändern. Wenn dieser Test sauber durchläuft, habe ich deutlich mehr Vertrauen in das Setup als nach einem bloßen Erstlauf. Bei Produktionssystemen prüfe ich außerdem, ob ein Timer vorhanden ist, zum Beispiel über systemctl list-timers oder über die üblichen Cron-Einträge.

Die eigentlichen Dateien liegen unter /etc/letsencrypt/live//. Ich zeige Webserver deshalb direkt auf fullchain.pem und privkey.pem statt Zertifikate irgendwohin zu kopieren. Das ist ein Detail mit großer Wirkung: Bei jeder Erneuerung bleiben die Symlinks stabil, und der Webserver bekommt automatisch die neuen Inhalte. Wenn ich einen Dienst mit Reload brauche, hänge ich den nach erfolgreicher Erneuerung per Hook an, damit der neue Schlüssel sofort aktiv wird. Dieser Teil entscheidet im Alltag mehr über Ruhe als jede kosmetische Optimierung an der Konfiguration.

Typische Fehler auf Ubuntu und wie ich sie vermeide

Die meisten Probleme entstehen nicht durch Certbot selbst, sondern durch die Umgebung. Ich habe die häufigsten Ursachen in einer kompakten Übersicht zusammengefasst, weil sie sich in der Praxis ständig wiederholen.

Gerade der IPv6-Fehler wird oft übersehen: Ein Server kann über IPv4 korrekt erreichbar sein, während ein alter AAAA-Eintrag die Validierung sabotiert. Deshalb prüfe ich DNS immer vollständig, nicht nur den einen Record, der gerade bequem aussieht. Wenn diese Basis stimmt, wird das System deutlich ruhiger. Dann stellt sich nur noch die Frage, in welchen Szenarien ich bewusst einen anderen Weg als den Standard nehme.

Wann ich lieber anders vorgehe

Es gibt Setups, in denen ich Certbot nicht mit der ersten naheliegenden Methode einsetze. Das betrifft vor allem Umgebungen mit Wildcard-Zertifikaten, strikten Netzwerkregeln oder mehreren Diensten hinter einem Reverse Proxy. In diesen Fällen ist die Standardlösung nicht falsch, aber sie ist nicht immer die eleganteste.

• Wildcard oder viele Subdomains: Ich gehe direkt auf DNS-01, weil HTTP-Validierung hier unnötig umständlich wäre.
• Port 80 ist gesperrt: Ich wähle DNS-01 oder, wenn das temporär sinnvoll ist, Standalone mit freigegebenem Port.
• Mehrere Dienste auf einem Host: Ich arbeite oft mit Webroot, damit ich keine Webserver-Konfiguration automatisch anfassen muss.
• Reverse Proxy oder Load Balancer: Ich plane den Reload der beteiligten Dienste bewusst mit ein, statt darauf zu hoffen, dass alles „schon irgendwie“ aktualisiert wird.

Das ist kein Veto gegen Certbot, sondern eine Frage des richtigen Verfahrens. Je klarer die Umgebung, desto einfacher ist die Entscheidung; je komplexer das Routing, desto eher lohnt sich DNS-01 oder ein bewusst manuell kontrollierter Ablauf. Für produktive Systeme ist genau diese Unterscheidung wichtig, weil sie spätere Überraschungen verhindert.

Die Punkte, die im Betrieb wirklich zählen

Wenn ich ein Zertifikat auf Ubuntu produktiv betreibe, verlasse ich mich nie nur auf die Erstinstallation. Ich prüfe regelmäßig, ob die automatische Verlängerung noch sauber läuft, ob der Webserver auf die Live-Dateien zeigt und ob DNS nach Änderungen wirklich konsistent ist. Zusätzlich halte ich /etc/letsencrypt im Backup, weil dort nicht nur Zertifikate, sondern auch die Konfiguration für die Erneuerung liegt.

Für den Alltag reicht oft eine einfache Routine: einmal ein sauberes Setup, einmal ein erfolgreicher Dry-Run, danach gelegentlich ein Blick auf Ablaufdaten und Logs. Genau so bleibt HTTPS auf Ubuntu stabil, ohne dass du es jeden Monat neu anfassen musst. Wenn du diese Linie konsequent einhältst, ist Certbot kein Basteltool, sondern ein sehr brauchbarer Teil deiner Server-Basis.