Let's Encrypt mit Certbot einrichten

Let’s Encrypt richten Sie auf einem selbst verwalteten Server am sichersten mit Certbot ein: Domain und Firewall prüfen, das passende Nginx- oder Apache-Modul installieren, Zertifikat ausstellen, Webserver-Konfiguration testen und anschließend die automatische Erneuerung mit einem Probelauf verifizieren. Erst dieser letzte Test macht HTTPS betriebssicher.

Vor dem ersten Certbot-Aufruf

Prüfen Sie zuerst die Zuständigkeit. Diese Anleitung passt zu einem Linux-Server, dessen Webserver-Konfiguration Sie selbst verwalten. Bei einem Hostingtarif mit Bedienoberfläche übernimmt häufig der Anbieter die Ausstellung. Dann ist dessen Zertifikatsfunktion der sauberere Weg, weil eine parallele Certbot-Installation später mit der Plattformautomatik kollidieren kann.

Der DNS-Eintrag der Domain muss bereits auf den Server zeigen. Prüfen Sie sowohl den IPv4- als auch einen vorhandenen IPv6-Eintrag. Ein veralteter AAAA-Eintrag ist ein klassischer Fehler: Ein Teil der Prüfstellen erreicht den falschen Server, obwohl der Aufruf vom eigenen Rechner funktioniert.

Für die übliche HTTP-Prüfung muss der Webserver von außen über Port 80 erreichbar sein. Port 443 wird für den späteren HTTPS-Betrieb benötigt. Kontrollieren Sie deshalb nicht nur die lokale Firewall, sondern auch vorgeschaltete Regeln beim Cloud- oder Serveranbieter. Eine offene lokale Regel hilft nicht, wenn die Netzfirewall davor blockiert.

Erstellen Sie vor Änderungen eine Sicherung der aktiven Webserver-Konfiguration. Notieren Sie außerdem, welcher Dienst den öffentlichen Anschluss tatsächlich bedient. Hinter einem vorgeschalteten Proxy darf Certbot nicht blind den nachgelagerten Server verändern.

Vor der Ausstellung müssen vier Punkte eindeutig sein:

• Die Domain zeigt auf diesen Server.
• Der zuständige Webserver liefert die Domain aus.
• Die externe Firewall lässt die gewählte Prüfung passieren.
• Eine Rückkehr zur gesicherten Konfiguration ist vorbereitet.

Certbot passend zum System installieren

Installieren Sie nicht aus zwei Quellen gleichzeitig. Betriebssystempaket, Snap-Paket und Python-Installation können unterschiedliche Programmstände, Timer und Pfade anlegen. Wählen Sie eine Methode nach der aktuellen offiziellen Certbot-Anleitung für Ihre Distribution und Ihren Webserver. Entfernen Sie alte Installationen nur, wenn Sie deren Zertifikate und Erneuerungsaufgaben verstanden haben.

Für Nginx benötigen Sie Certbot samt Nginx-Modul, für Apache entsprechend das Apache-Modul. Die Paketnamen unterscheiden sich zwischen Distributionen. Verlassen Sie sich deshalb nicht auf einen beliebigen Einzeiler aus einem alten Blogbeitrag. Entscheidend ist, dass dieser Aufruf ohne Fehler funktioniert:

certbot --version

Prüfen Sie danach, ob der richtige Webserver läuft und welche Konfiguration aktiv ist. Ein Zertifikat für die falsche Instanz löst kein Problem. Es schafft nur eine weitere Erneuerungsaufgabe, die niemand überwacht.

Let’s Encrypt mit Nginx einrichten

Testen Sie Nginx vor der Ausstellung. Der Certbot-Installer soll nur auf einer bereits konsistenten Konfiguration arbeiten. Der Syntaxcheck prüft außerdem, ob referenzierte Dateien erreichbar sind.

nginx -t

Fordern Sie danach das Zertifikat für alle Namen an, die derselbe Serverblock ausliefern soll. Ersetzen Sie die Beispieldomain vollständig durch Ihre Domain.

certbot --nginx -d example.de -d www.example.de

Certbot führt durch die Kontaktdaten und die Bedingungen, prüft die Domain und bindet das Zertifikat ein. Lesen Sie die angezeigten Änderungen, statt jede Nachfrage reflexartig zu bestätigen. Besonders bei mehreren Serverblöcken muss der Domainname eindeutig zur gewünschten Konfiguration passen.

Führen Sie anschließend erneut den Syntaxcheck aus und laden Sie Nginx kontrolliert neu:

nginx -t
nginx -s reload

Ein Reload übernimmt eine gültige Konfiguration, ohne laufende Verbindungen unnötig abzubrechen. Schlägt der Test fehl, wird nicht neu geladen. Korrigieren Sie zuerst die gemeldete Datei und Zeile; ein Neustart auf Verdacht verschärft die Störung.

Let’s Encrypt mit Apache einrichten

Prüfen Sie bei Apache die VirtualHost-Zuordnung. ServerName und zusätzliche Namen müssen zu den Domains passen, die Sie in das Zertifikat aufnehmen. Danach kontrolliert der Konfigurationstest die Syntax.

apachectl configtest

Fordern Sie das Zertifikat über das Apache-Modul an:

certbot --apache -d example.de -d www.example.de

Nach erfolgreicher Ausstellung testen Sie die Konfiguration erneut und führen einen sanften Reload aus:

apachectl configtest
apachectl -k graceful

Der sanfte Reload lässt bestehende Verbindungen auslaufen. Das ist im Betrieb die bessere Standardreaktion als ein harter Neustart. Falls Ihre Distribution Apache über einen anders benannten Dienst steuert, verwenden Sie deren dokumentierten Dienstbefehl; mischen Sie nicht wahllos apachectl und distributionsspezifische Kommandos.

HTTP-Prüfung oder DNS-Prüfung wählen

Für eine normale öffentlich erreichbare Website ist HTTP meist der direkte Weg. Let’s Encrypt ruft dabei eine Prüfdatei über Port 80 ab. Weiterleitungen auf HTTP oder HTTPS werden nur in den dafür vorgesehenen Standardpfaden akzeptiert. Eine Umleitung ersetzt daher keine erreichbare Webprüfung.

Die DNS-Prüfung setzt dagegen einen TXT-Eintrag unterhalb der Domain. Sie ist zwingend, wenn das Zertifikat eine Wildcard wie *.example.de enthalten soll. Sie eignet sich auch, wenn der Webserver nicht öffentlich über HTTP erreichbar ist oder mehrere Server denselben Namen bedienen.

Die Grafik trennt die Entscheidung sauber: Eine normale Domain kann über den erreichbaren Webserver geprüft werden, eine Wildcard-Domain braucht die DNS-Prüfung. In beiden Fällen ist das Zertifikat erst betriebstauglich, wenn die automatische Erneuerung getestet wurde.

Automatisieren Sie DNS nur mit begrenzten Rechten. Das DNS-Modul benötigt Zugang zur Schnittstelle des DNS-Anbieters. Der Schlüssel sollte nur die betroffene Zone und möglichst nur die notwendigen Einträge ändern dürfen. Vollzugriff auf das gesamte Konto auf demselben Webserver vergrößert den Schaden eines Einbruchs erheblich.

Eine manuelle DNS-Prüfung ohne Automatisierung eignet sich höchstens für einen bewussten Sonderfall. Sie verlangt bei jeder Erneuerung einen neuen TXT-Eintrag. Wer diesen Arbeitsschritt vergisst, bemerkt den Fehler meist erst durch ein ablaufendes Zertifikat. Betrieb schlägt Prospekt: Wählen Sie einen automatisierbaren Weg oder dokumentieren Sie den manuellen Termin ausdrücklich.

Automatische Erneuerung wirklich prüfen

Ausgestellt ist nicht erneuert. Viele Certbot-Installationen richten bereits eine geplante Aufgabe ein. Ob das auf Ihrem System tatsächlich geschehen ist, prüfen Sie bei systemd-Systemen mit:

systemctl list-timers | grep certbot

Danach testen Sie den vollständigen Erneuerungsweg gegen die Testumgebung:

certbot renew --dry-run

Der Probelauf muss ohne Fehler enden. Er prüft nicht nur den Certbot-Befehl, sondern auch die gespeicherte Authentifizierungsmethode. Nach einem Umzug des Webroots, einem DNS-Anbieterwechsel oder einer Proxy-Änderung kann die ursprüngliche Methode unbrauchbar werden, obwohl das aktuell installierte Zertifikat noch funktioniert.

Kontrollieren Sie zusätzlich, ob der Webserver das erneuerte Zertifikat nach einer erfolgreichen Ausstellung neu lädt. Bei besonderen Aufbauten kann dafür ein Bereitstellungshaken nötig sein. Testen Sie einen solchen Haken bewusst; ein erneuertes Zertifikat auf der Festplatte nützt nichts, wenn der laufende Dienst weiterhin die alte Datei hält.

Staging und Rate Limits

Testen Sie unsichere Änderungen nicht durch wiederholte Produktionsanfragen. Let’s Encrypt stellt eine Staging-Umgebung bereit. Deren Zertifikate werden von normalen Browsern nicht vertraut, eignen sich aber zur Prüfung des Ablaufs. Der Certbot-Probelauf nutzt diese Testumgebung, sofern keine abweichende Serverkonfiguration gesetzt wurde.

Wiederholte Fehlversuche oder identische Neuausstellungen können Produktionslimits treffen. Dann hilft hektisches Wiederholen nicht. Lesen Sie die Fehlermeldung, beachten Sie eine angegebene Wartezeit und beseitigen Sie zuerst die Ursache. Typische Ursachen sind falsches DNS, ein blockierter HTTP-Zugriff oder eine nicht erreichbare Prüfdatei.

Sicherung, Widerruf und Ausfallpfad

Sichern Sie Konfiguration und Kontozugang, nicht nur Zertifikatsdateien. Für die Wiederherstellung brauchen Sie die Webserver-Konfiguration, die Certbot-Verwaltung und bei DNS-Automatisierung den dokumentierten Weg zu neuen Zugangsdaten. Speichern Sie geheime Schlüssel nicht unverschlüsselt in einem allgemeinen Sicherungsarchiv.

Wurde ein privater Schlüssel kompromittiert, stellen Sie zuerst einen sicheren Ersatz bereit und widerrufen danach das betroffene Zertifikat gezielt:

certbot revoke --cert-name example.de

Ein Widerruf beendet nicht automatisch jede spätere Erneuerung. Prüfen Sie anschließend die Certbot-Verwaltung und entfernen Sie nur Zertifikate, die kein Dienst mehr referenziert. Löschen Sie Dateien im Let’s-Encrypt-Verzeichnis nicht von Hand; dadurch können Verweise im Webserver und gespeicherte Erneuerungsdaten auseinanderlaufen.

Fragen Sie nach dem Ausfallpfad: Wer erhält die Warnung, wer darf DNS ändern, wo liegt die Sicherung, und wie wird der Webserver nach einer Erneuerung geladen? Diese Antworten sind wichtiger als die einmalige Erfolgsmeldung bei der Ausstellung.

Ein kostenloses Zertifikat spart die Lizenzkosten, nicht die Betriebsarbeit. Erst geprüfte DNS-Zuordnung, reproduzierbare Ausstellung, automatische Erneuerung und ein dokumentierter Widerrufsweg ergeben einen belastbaren HTTPS-Betrieb. Alles andere ist eine Momentaufnahme mit Ablaufdatum.