Certbot im Standalone-Modus mit Let’s Encrypt unter Ubuntu 20.04 verwenden

Let’s Encrypt ist eine kostenlose und automatisierte Zertifizierungsstelle, die von der gemeinnützigen Internet Security Research Group (ISRG) betrieben wird. Im Standalone-Modus startet Certbot vorübergehend einen integrierten Webserver auf Port 80, um die von der Let’s-Encrypt-API bereitgestellte ACME-HTTP-01-Challenge abzuschließen. Dieser Modus eignet sich insbesondere dann, wenn auf dem System noch kein Webserver läuft oder wenn ein Dienst abgesichert werden soll, der nicht über HTTP arbeitet, beispielsweise ein Mailserver, ein MQTT-Broker oder eine eigene TCP-Anwendung. Ist bereits ein Webserver wie Nginx, Apache oder eine vergleichbare Lösung aktiv, sollte stattdessen das Webroot-Plugin oder das entsprechende Nginx- beziehungsweise Apache-Plugin verwendet werden. Dadurch kann die Verifizierung durchgeführt werden, ohne den produktiven Dienst anhalten zu müssen.

In dieser Anleitung wird EFF Certbot verwendet, um ein gültiges Let’s-Encrypt-Zertifikat mit einer Laufzeit von 90 Tagen anzufordern. Die Zertifikatsdateien werden unter /etc/letsencrypt/live/your_domain/ abgelegt. Zusätzlich wird die automatische Verlängerung über den systemd-Timer von Certbot eingerichtet. Außerdem werden Pre-Hook- und Post-Hook-Skripte konfiguriert, die bei jedem Verlängerungsversuch einen Dienst, der Port 80 belegt, automatisch stoppen und anschließend wieder starten.

Hinweis: Diese Anleitung richtet sich an Ubuntu 20.04.

Wichtige Punkte im Überblick

• Im Standalone-Modus startet Certbot vorübergehend einen eigenen Webserver, der die ACME-Challenge von Let’s Encrypt beantwortet. Für die übliche HTTP-01-Challenge muss TCP-Port 80 verfügbar sein.
• Der Standalone-Modus ist geeignet, wenn kein Webserver läuft oder ein Nicht-HTTP-Dienst wie ein Mailserver, Message Broker oder eine eigene TCP-Anwendung abgesichert werden soll. Wenn bereits ein Webserver Anfragen verarbeitet, sollte stattdessen Webroot oder das Nginx-/Apache-Plugin verwendet werden.
• Unter Ubuntu 20.04 und neueren Versionen sollte Certbot über Snap installiert werden. Das apt-basierte Certbot-Paket wird von der EFF für aktuelle Ubuntu-Versionen nicht mehr aktiv gepflegt.
• Let’s-Encrypt-Zertifikate sind 90 Tage gültig. Eine über Snap installierte Certbot-Version bringt einen systemd-Timer mit, der zweimal täglich nach erforderlichen Verlängerungen sucht und Zertifikate erneuert, sobald diese weniger als 30 Tage gültig sind.
• Auch während einer Verlängerung muss Port 80 im Standalone-Modus verfügbar sein. Pre-Hook- und Post-Hook-Skripte können einen Dienst, der diesen Port verwendet, vor dem Verlängerungsversuch beenden und anschließend wieder starten.
• Die Zertifikatsdateien befinden sich unter /etc/letsencrypt/live/your_domain/. Für die meisten Dienste werden insbesondere fullchain.pem mit der vollständigen Zertifikatskette und privkey.pem mit dem privaten Schlüssel benötigt.

Voraussetzungen

Bevor Sie mit dieser Anleitung beginnen, benötigen Sie:

• Einen Ubuntu-20.04-Server mit einem Benutzer ohne Root-Anmeldung, der über sudo-Berechtigungen verfügt, sowie eine grundlegend konfigurierte Firewall.
• Einen Domainnamen, der auf den Server verweist. In dieser Anleitung wird dafür beispielhaft your_domain verwendet.
• Port 80 muss sowohl während der Ausstellung des Zertifikats als auch bei jeder späteren Verlängerung verfügbar sein. Falls ein bestehender Webserver Port 80 verwendet, muss dieser vor dem Start von Certbot im Standalone-Modus gestoppt und anschließend wieder gestartet werden. Verwendet der abzusichernde Dienst sowohl Port 80 als auch Port 443 und kann er nicht kurzfristig beendet werden, sollte stattdessen der Webroot-Modus von Certbot eingesetzt werden. Die erforderlichen Firewall-Regeln können unter Ubuntu mit UFW eingerichtet werden.

Schritt 1 — Certbot installieren

Aktualisieren Sie zunächst den Snap-Core. Ubuntu 20.04 enthält snapd standardmäßig:

sudo snap install core; sudo snap refresh core

Falls auf dem Server bereits eine ältere Certbot-Version installiert war, entfernen Sie diese zunächst:

sudo apt remove certbot

Installieren Sie Certbot anschließend über Snap:

sudo snap install --classic certbot

Erstellen Sie danach einen symbolischen Link vom Certbot-Binary im Snap-Verzeichnis in einen Pfad, der direkt über die Shell erreichbar ist. Dadurch lässt sich Certbot einfach mit dem Befehl certbot starten. Dieser Schritt ist nicht bei allen Paketen erforderlich. Snap-Pakete sind jedoch standardmäßig eher isoliert aufgebaut, damit sie nicht versehentlich mit anderen Systempaketen in Konflikt geraten:

sudo ln -s /snap/bin/certbot /usr/bin/certbot

Prüfen Sie anschließend die Installation, indem Sie die installierte Certbot-Version ausgeben:

certbot --version

Output:

certbot 2.11.0

Die tatsächlich angezeigte Versionsnummer hängt vom zum Installationszeitpunkt verwendeten Snap-Kanal ab und verändert sich mit zukünftigen Certbot-Versionen.

Schritt 2 — Firewall konfigurieren

Der Standalone-Modus von Certbot verwendet standardmäßig die ACME-HTTP-01-Challenge. Dafür muss TCP-Port 80 aus dem Internet erreichbar sein. Geben Sie Port 80 in der Firewall frei:

sudo ufw allow 80

Output:

Rule added
Rule added (v6)

Öffnen Sie anschließend Port 443, damit nach Ausstellung des Zertifikats HTTPS-Verbindungen möglich sind:

sudo ufw allow 443

Output:

Rule added
Rule added (v6)

Standardmäßig nutzt der Standalone-Modus die HTTP-01-Challenge über Port 80. Wenn stattdessen --preferred-challenges tls-alpn-01 verwendet wird, muss Port 443 geöffnet sein. Wird Port 80 ausschließlich für die Zertifikatsausstellung benötigt und stellt die Anwendung keinen HTTP-Dienst bereit, kann die Firewall-Regel anschließend mit sudo ufw delete allow 80 wieder entfernt werden.

Schritt 3 — Zertifikat im Standalone-Modus anfordern

Hinweis: Bevor Sie ein Zertifikat über die produktive Let’s-Encrypt-API anfordern, sollten Sie die Konfiguration mit --dry-run testen. Falls der komplette Ausstellungsvorgang während Tests mehrfach ausgeführt werden muss, können Sie zusätzlich --staging oder --test-cert verwenden, damit keine Rate Limits überschritten werden. Zertifikate aus der Staging-Umgebung werden von Browsern nicht als vertrauenswürdig eingestuft, der technische Ausstellungsvorgang ist jedoch identisch. Aktuelle Grenzwerte finden Sie in der Dokumentation zu den Let’s-Encrypt-Rate-Limits.

Warnung: Im Standalone-Modus muss Certbot Port 80 belegen können. Falls Nginx, Apache oder ein anderer Dienst bereits auf Port 80 lauscht, muss dieser Dienst vor dem folgenden Befehl beendet und nach erfolgreicher Zertifikatsausstellung wieder gestartet werden. Ist der Port bereits belegt, beendet Certbot den Vorgang mit einem Binding-Fehler.

Die Option --standalone weist Certbot an, die Challenge über den eigenen temporären Webserver zu bearbeiten. Mit -d wird die Domain angegeben, für die das Zertifikat angefordert wird. Werden mehrere Domains in einem Zertifikat benötigt, kann -d mehrfach angegeben werden.

sudo certbot certonly --standalone -d your_domain

Während der Ausführung fragt Certbot nach einer E-Mail-Adresse und fordert zur Zustimmung zu den Nutzungsbedingungen auf. Nach Abschluss sollte eine Erfolgsmeldung erscheinen, die zusätzlich angibt, an welchem Ort die Zertifikatsdateien gespeichert wurden:

Output:

IMPORTANT NOTES:
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/your_domain/fullchain.pem
Key is saved at: /etc/letsencrypt/live/your_domain/privkey.pem
This certificate expires on 2026-09-06.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
* Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
* Donating to EFF: https://eff.org/donate-le

Zertifikatsausstellung automatisieren

In automatisierten oder skriptgesteuerten Umgebungen, in denen keine interaktiven Eingaben möglich sind, können die Registrierungsparameter direkt im Befehl angegeben werden:

sudo certbot certonly --standalone \
  --non-interactive \
  --agree-tos \
  --no-eff-email \
  -m your_email@example.com \
  -d your_domain

Mit --agree-tos wird die Let’s-Encrypt-Teilnehmervereinbarung akzeptiert. --no-eff-email unterdrückt die Aufforderung zur Anmeldung für den EFF-Newsletter. Die Option -m legt die E-Mail-Adresse fest, die Let’s Encrypt für Warnungen zu ablaufenden Zertifikaten und fehlgeschlagenen Verlängerungen verwendet. Verwenden Sie eine tatsächlich erreichbare E-Mail-Adresse, da Benachrichtigungen über fehlgeschlagene Verlängerungen unter Umständen die einzige frühzeitige Warnung darstellen, wenn der systemd-Timer nicht mehr funktioniert.

Die Zertifikatsdateien sollten nun vorhanden sein. Listen Sie das Verzeichnis auf, in dem Zertifikate und Schlüssel gespeichert werden:

sudo ls /etc/letsencrypt/live/your_domain

Output:

cert.pem  chain.pem  fullchain.pem  privkey.pem  README

Überprüfen Sie anschließend die Zertifikatsinformationen mit OpenSSL:

sudo openssl x509 -in /etc/letsencrypt/live/your_domain/cert.pem -noout -subject -issuer -dates -ext subjectAltName

Output:

subject=CN = your_domain
issuer=C = US, O = Let's Encrypt, CN = E5
notBefore=Mon Jun  8 00:00:00 2026 GMT
notAfter=Sun Sep  6 00:00:00 2026 GMT

X509v3 Subject Alternative Name:
    DNS:your_domain

Das Feld notAfter bestätigt die Gültigkeitsdauer von 90 Tagen. Über issuer lässt sich erkennen, dass das Zertifikat von Let’s Encrypt signiert wurde. Wenn mehrere Domains mit wiederholten -d-Optionen angegeben wurden, erscheint jede davon als eigener DNS:-Eintrag. Eine Domain, die hier nicht aufgeführt ist, wird vom Zertifikat nicht abgedeckt.

Um alle Zertifikate aufzulisten, die derzeit von Certbot verwaltet werden, einschließlich der enthaltenen Domains und Ablaufdaten, verwenden Sie:

sudo certbot certificates

Output:

Found the following certs:
  Certificate Name: your_domain
    Serial Number: ...
    Key Type: ECDSA
    Domains: your_domain
    Expiry Date: 2026-09-06 00:00:00+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/your_domain/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/your_domain/privkey.pem

Dieser Befehl ist die zentrale Möglichkeit, den Status von Zertifikaten auf einem von Certbot verwalteten Server zu prüfen.

Einen Dienst für die Verwendung des Zertifikats konfigurieren

Die meisten Dienste benötigen aus diesem Verzeichnis zwei Dateien: fullchain.pem als Zertifikat und privkey.pem als privaten Schlüssel. Das folgende Beispiel zeigt die relevanten TLS-Einstellungen für Postfix in /etc/postfix/main.cf:

/etc/postfix/main.cf

smtpd_tls_cert_file = /etc/letsencrypt/live/your_domain/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/your_domain/privkey.pem
smtpd_tls_security_level = may

Hinweis: Das Verzeichnis /etc/letsencrypt/live/ kann normalerweise nur von Root gelesen werden. Dienste, die mit einem Benutzer ohne Root-Rechte ausgeführt werden, beispielsweise mit dem Benutzer postfix, benötigen entweder einen Deploy-Hook, der die Zertifikatsdateien an einen zugänglichen Speicherort kopiert, oder ausdrücklich konfigurierte Zugriffsrechte auf das Zertifikatsverzeichnis. Eine vollständige Installation und Konfiguration von Postfix kann unter Ubuntu 20.04 separat durchgeführt werden.

Für einen MQTT-Broker wie Mosquitto kann beispielsweise folgende Konfiguration unter /etc/mosquitto/conf.d/tls.conf verwendet werden:

/etc/mosquitto/conf.d/tls.conf

listener 8883
cafile /etc/ssl/certs/ca-certificates.crt
certfile /etc/letsencrypt/live/your_domain/fullchain.pem
keyfile /etc/letsencrypt/live/your_domain/privkey.pem

Port 8883 ist der Standardport für MQTT über TLS. Auch hier gilt die Einschränkung bezüglich der Root-Berechtigungen. Der Benutzer mosquitto benötigt deshalb entweder einen Deploy-Hook oder ausdrückliche Leseberechtigungen für privkey.pem.

Die README-Datei im Zertifikatsverzeichnis enthält weitere Informationen zu den einzelnen Dateien. In den meisten Fällen werden hauptsächlich die folgenden beiden Dateien benötigt:

• privkey.pem: Diese Datei enthält den privaten Schlüssel und muss geheim bleiben. Aus diesem Grund ist das Verzeichnis /etc/letsencrypt auf Root-Zugriff beschränkt. In Dienstkonfigurationen wird diese Datei häufig über Einstellungen wie ssl-certificate-key oder ssl-certificate-key-file eingebunden.
• fullchain.pem: Diese Datei enthält die vollständige Zertifikatskette. Viele Dienste binden sie über eine Option wie ssl-certificate ein.

Weitere Informationen zu den übrigen Dateien finden Sie im Abschnitt „Where are my certificates?“ der Certbot-Dokumentation.

Einige Programme benötigen Zertifikate in anderen Formaten, an anderen Speicherorten oder mit abweichenden Benutzerberechtigungen. Wenn möglich, sollten alle Dateien im Let’s-Encrypt-Verzeichnis verbleiben und die dortigen Berechtigungen nicht verändert werden, da sie bei einer Verlängerung ohnehin überschrieben werden können. Falls dies nicht möglich ist, sollte ein Skript erstellt werden, das die benötigten Dateien kopiert oder verschiebt und die erforderlichen Berechtigungen setzt. Dieses Skript muss nach jeder erfolgreichen Zertifikatsverlängerung ausgeführt werden. Die entsprechende Konfiguration wird im nächsten Schritt behandelt.

Schritt 4 — Automatische Zertifikatsverlängerung konfigurieren

Let’s-Encrypt-Zertifikate besitzen eine Gültigkeitsdauer von 90 Tagen. Eine über Snap installierte Certbot-Version richtet einen systemd-Timer mit der Bezeichnung snap.certbot.renew.timer ein. Dieser führt zweimal täglich certbot renew aus und verlängert Zertifikate, sobald deren verbleibende Laufzeit weniger als 30 Tage beträgt. Eine separate Cron-Konfiguration ist nicht erforderlich.

Nach einer erfolgreichen Verlängerung muss Certbot den Dienst, der das Zertifikat verwendet, neu laden oder neu starten, damit dieser die aktualisierten Zertifikatsdateien übernimmt. Im Standalone-Modus muss zusätzlich jeder Prozess, der Port 80 verwendet, vor der Verlängerung gestoppt und anschließend wieder gestartet werden. Certbot bietet hierfür zwei Möglichkeiten: die Option renew_hook in der Verlängerungskonfiguration sowie Pre-Hook- und Post-Hook-Skripte in den dafür vorgesehenen Verzeichnissen.

Um einen renew_hook einzurichten, öffnen Sie die Verlängerungskonfiguration der Domain:

sudo nano /etc/letsencrypt/renewal/your_domain.conf

Die Datei enthält die Einstellungen für die Zertifikatsverlängerung. Ergänzen Sie am Ende einen Hook, der den Dienst neu lädt, damit er das erneuerte Zertifikat verwendet:

/etc/letsencrypt/renewal/your_domain.conf

renew_hook = systemctl reload your_service

Ersetzen Sie den Beispielbefehl durch den tatsächlich benötigten Befehl zum Neuladen Ihres Dienstes oder durch ein Skript, das nach einer Zertifikatsverlängerung weitere Verarbeitungsschritte ausführt. Unter Ubuntu wird für das Neuladen von Diensten häufig systemctl verwendet.

Pre-Hook- und Post-Hook-Skripte für Dienstneustarts verwenden

Bei jeder Verlängerung im Standalone-Modus muss Certbot erneut Port 80 verwenden können, um die ACME-Challenge abzuschließen. Belegt ein anderer Dienst diesen Port während eines Verlängerungsversuchs, schlägt die Verlängerung fehl und das Zertifikat kann schließlich ablaufen. Ein Pre-Hook beendet den betreffenden Dienst vor dem Verlängerungsversuch, während ein Post-Hook ihn danach wieder startet.

Vor der Auswahl dieses Verfahrens sollte die damit verbundene kurze Ausfallzeit berücksichtigt werden. Certbot muss Port 80 für einige Sekunden belegen, während die ACME-Challenge verarbeitet wird. Ein durch den Pre-Hook gestoppter Dienst ist in diesem Zeitraum sowie während des Stop- und Startvorgangs nicht verfügbar. Für viele Nicht-HTTP-Dienste wie Mail, MQTT oder eigene TCP-Anwendungen ist dies normalerweise akzeptabel. Wenn eine Verlängerung ohne Unterbrechung erforderlich ist, kann ein Reverse Proxy Anfragen an /.well-known/acme-challenge/ an den von Certbot verwendeten --http-01-port weiterleiten, während der eigentliche Dienst aktiv bleibt. Diese Konfiguration liegt jedoch außerhalb des Umfangs dieser Anleitung.

Bei der Wahl zwischen den beiden folgenden Hook-Varianten sollte Methode 1 mit den Renewal-Hook-Verzeichnissen verwendet werden, wenn die Skripte unabhängig davon ausgeführt werden sollen, wie die Verlängerung gestartet wurde. Methode 2 mit Inline-Optionen ist geeignet, wenn die Hooks bereits bei der interaktiven Ausstellung des Zertifikats in der Verlängerungskonfiguration gespeichert werden sollen. Für den Standalone-Modus zur Absicherung eines Nicht-HTTP-Dienstes ist Methode 1 die sicherere Wahl.

Methode 1: Hook-Skripte in den Renewal-Hook-Verzeichnissen

Erstellen Sie zunächst das Pre-Hook-Skript:

sudo tee /etc/letsencrypt/renewal-hooks/pre/stop-service.sh <<'EOF'
#!/bin/sh
systemctl stop your_service
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/pre/stop-service.sh

Erstellen Sie anschließend das Post-Hook-Skript:

sudo tee /etc/letsencrypt/renewal-hooks/post/start-service.sh <<'EOF'
#!/bin/sh
systemctl start your_service
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/post/start-service.sh

Certbot führt Skripte aus diesen Verzeichnissen abhängig vom Zeitpunkt innerhalb des Verlängerungsvorgangs aus:

• /etc/letsencrypt/renewal-hooks/pre/: Skripte in diesem Verzeichnis werden vor jedem Verlängerungsversuch ausgeführt, unabhängig davon, ob das Zertifikat tatsächlich erneuert wird.
• /etc/letsencrypt/renewal-hooks/deploy/: Skripte in diesem Verzeichnis werden nur ausgeführt, wenn ein Zertifikat erfolgreich verlängert und bereitgestellt wurde.
• /etc/letsencrypt/renewal-hooks/post/: Skripte in diesem Verzeichnis werden nach jedem Verlängerungsversuch ausgeführt, unabhängig vom Ergebnis.

Hinweis: Ersetzen Sie your_service durch den systemd-Unit-Namen Ihrer Anwendung. Für einen Postfix-Mailserver wird beispielsweise postfix verwendet. Mit systemctl list-units --type=service können Sie aktive Dienste auflisten und den korrekten Unit-Namen überprüfen.

Methode 2: Inline-Optionen bei der Zertifikatsausstellung

sudo certbot certonly --standalone \
  --pre-hook "systemctl stop your_service" \
  --post-hook "systemctl start your_service" \
  -d your_domain

Certbot speichert diese Optionen automatisch unter /etc/letsencrypt/renewal/your_domain.conf. Dadurch werden sie bei allen späteren Ausführungen von certbot renew erneut angewendet.

Renewal-Timer überprüfen

Prüfen Sie, ob der systemd-Timer aktiv ist, und kontrollieren Sie den nächsten geplanten Ausführungszeitpunkt:

sudo systemctl list-timers | grep certbot

Output:

NEXT                        LEFT     LAST                        PASSED   UNIT                       ACTIVATES
Tue 2026-06-09 12:00:00 UTC 5h left  Mon 2026-06-08 00:00:00 UTC 6h ago  snap.certbot.renew.timer   snap.certbot.renew.service

Führen Sie anschließend eine simulierte Verlängerung durch, um die Konfiguration zu testen, ohne ein neues produktives Zertifikat anzufordern:

sudo certbot renew --dry-run

Output:

Congratulations, all simulated renewals succeeded:
  /etc/letsencrypt/live/your_domain/fullchain.pem (success)

Wenn keine Fehler auftreten, ist Certbot so eingerichtet, dass Zertifikate bei Bedarf verlängert und die notwendigen Befehle ausgeführt werden, damit die entsprechenden Dienste die aktualisierten Dateien verwenden. Beachten Sie, dass --dry-run Pre-Hooks und Post-Hooks ausführt, Deploy-Hooks jedoch überspringt. Ein renew_hook aus der Verlängerungskonfiguration wird bei einem Dry Run ebenfalls nicht ausgeführt, da kein echtes Zertifikat ausgestellt wird.

Standalone-Modus und andere Certbot-Modi im Vergleich

Welcher Certbot-Modus verwendet werden sollte, hängt davon ab, ob bereits ein Webserver aktiv ist und ob Certbot die Webserverkonfiguration automatisch ändern soll.

Ist bereits ein Webserver aktiv, sollte Webroot oder das passende Nginx- beziehungsweise Apache-Plugin anstelle des Standalone-Modus verwendet werden. Dadurch muss ein produktiver Dienst während einer Zertifikatsverlängerung nicht unterbrochen werden. Sowohl Nginx als auch Apache können unter Ubuntu 20.04 mit den entsprechenden Let’s-Encrypt-Certbot-Verfahren abgesichert werden. Für Ubuntu 22.04 sollte das speziell für diese Version vorgesehene Standalone-Verfahren verwendet werden.

Häufige Probleme mit dem Certbot-Standalone-Modus beheben

Port 80 wird bereits verwendet (EADDRINUSE)

Wenn ein anderer Prozess bereits Port 80 verwendet, kann Certbot mit der Fehlermeldung OSError: [Errno 98] Address already in use abbrechen. Ermitteln Sie zunächst, welcher Prozess den Port belegt:

sudo ss -tlnp 'sport = :80'

Output:

State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      511          0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=1234,fd=6))

Stoppen Sie den Dienst, der den Port verwendet. Das folgende Beispiel beendet Nginx:

sudo systemctl stop nginx

Führen Sie anschließend den Befehl certbot certonly --standalone erneut aus. Nachdem das Zertifikat ausgestellt wurde, starten Sie den Dienst wieder:

sudo systemctl start nginx

Firewall blockiert Port 80

Die ACME-HTTP-01-Challenge kann nicht erfolgreich abgeschlossen werden, wenn die Let’s-Encrypt-Server Port 80 unter der öffentlichen IP-Adresse der Domain nicht erreichen können. Prüfen Sie zunächst den aktuellen UFW-Status:

sudo ufw status

Output:

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
443                        ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)

Falls Port 80 nicht als freigegeben aufgeführt ist, öffnen Sie ihn mit:

sudo ufw allow 80

Output:

Rule added
Rule added (v6)

Nach Ausstellung des Zertifikats kann die Regel wieder entfernt werden, sofern die Anwendung keinen HTTP-Dienst bereitstellt:

sudo ufw delete allow 80

Output:

Rule deleted
Rule deleted (v6)

IPv4-/IPv6-Dual-Stack-Binding-Fehler

In einigen Docker-Umgebungen und virtuellen Serverkonfigurationen kann Certbot aufgrund von Konflikten zwischen IPv4 und IPv6 im Dual-Stack-Betrieb Port 80 nicht belegen. Die Fehlermeldung weist dabei üblicherweise darauf hin, dass Certbot Port 80 weder über IPv4 noch über IPv6 binden konnte. Mit --preferred-challenges kann die HTTP-01-Challenge ausdrücklich vorgegeben werden:

sudo certbot certonly --standalone --preferred-challenges http-01 -d your_domain

Wird Certbot innerhalb eines Docker-Containers ausgeführt, muss Port 80 vom Container auf das Hostsystem weitergeleitet werden. Zusätzlich darf auf dem Host selbst kein anderer Prozess gleichzeitig Port 80 verwenden.

Challenge schlägt trotz offenem Port 80 wegen DNS- oder IPv6-Abweichungen fehl

Wenn Certbot eine Meldung wie Connection refused oder Timeout during connect zurückgibt, obwohl Port 80 in UFW freigegeben ist, kann ein fehlerhafter DNS-AAAA-Eintrag die Ursache sein. Let’s Encrypt bevorzugt IPv6 und versucht zunächst, die Domain über IPv6 zu erreichen. Verweist ein AAAA-Eintrag auf eine IPv6-Adresse, über die Port 80 nicht erreichbar ist, schlägt die Prüfung unabhängig von korrekt eingerichteten IPv4-Firewall-Regeln fehl.

Prüfen Sie, ob für die Domain ein AAAA-Eintrag existiert:

dig AAAA your_domain

Output:

;; ANSWER SECTION:
your_domain.    300    IN    AAAA    2001:db8::1

Existiert ein AAAA-Eintrag, obwohl IPv6 auf dem Server nicht eingerichtet ist, sollte der AAAA-Eintrag beim DNS-Anbieter entfernt oder der Server so konfiguriert werden, dass seine IPv6-Adresse ebenfalls Port 80 bereitstellt. Prüfen Sie die Verfügbarkeit von Port 80 für IPv6 mit:

sudo ss -tlnp 'sport = :80'

Output:

State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      511          0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=1234,fd=6))
LISTEN 0      511             [::]:80            [::]:*     users:(("nginx",pid=1234,fd=6))

Bei einem korrekt eingerichteten Dual-Stack-Server sollten sowohl ein IPv4-Eintrag mit 0.0.0.0:80 als auch ein IPv6-Eintrag mit [::]:80 erscheinen. Ist ausschließlich der IPv4-Eintrag vorhanden, obwohl für die Domain ein AAAA-Eintrag existiert, schlägt die Let’s-Encrypt-Challenge fehl.

FAQ

Was ist der Certbot-Standalone-Modus und wann sollte er verwendet werden?

Im Standalone-Modus übernimmt Certbot vorübergehend Port 80 und stellt einen Verifizierungstoken über eine standardisierte URL bereit. Let’s Encrypt ruft diesen Token ab, um zu bestätigen, dass Sie die Kontrolle über die Domain besitzen, und stellt anschließend das Zertifikat aus. Dieser Modus eignet sich, wenn kein Webserver auf dem System läuft oder wenn ein Nicht-HTTP-Dienst wie ein Mailserver, MQTT-Broker oder eine eigene TCP-Anwendung abgesichert werden soll.

Muss ein Webserver vor der Verwendung von Certbot im Standalone-Modus gestoppt werden?

Ja. Certbot muss im Standalone-Modus Port 80 belegen, um die ACME-Challenge zu verarbeiten. Wenn Nginx, Apache oder ein anderer Webserver den Port bereits verwendet, schlägt Certbot mit einem Binding-Fehler fehl. Stoppen Sie den Webserver vor der Ausführung von sudo certbot certonly --standalone und starten Sie ihn nach erfolgreicher Zertifikatsausstellung erneut.

Wie wird ein im Standalone-Modus ausgestelltes Let’s-Encrypt-Zertifikat verlängert?

Wird Certbot unter Ubuntu 20.04 über Snap installiert, richtet es den systemd-Timer snap.certbot.renew.timer ein, der zweimal täglich certbot renew startet. Für den Standalone-Modus sollten Pre-Hook- und Post-Hook-Skripte eingerichtet werden, die alle Dienste stoppen und wieder starten, die Port 80 verwenden. Die Hooks können entweder über --pre-hook und --post-hook angegeben oder als ausführbare Skripte unter /etc/letsencrypt/renewal-hooks/ abgelegt werden. Mit sudo certbot renew --dry-run lässt sich der Ablauf testen.

Wo werden die Zertifikatsdateien nach der Ausstellung durch Certbot gespeichert?

Certbot speichert die Zertifikate unter /etc/letsencrypt/live/your_domain/. Zu den für Dienste häufig benötigten Dateien gehören fullchain.pem mit der vollständigen Zertifikatskette, privkey.pem mit dem privaten Schlüssel, cert.pem mit ausschließlich dem eigentlichen Endzertifikat sowie chain.pem mit der Intermediate-Zertifikatskette.

Was passiert, wenn Port 80 während der Zertifikatsausstellung durch die Firewall blockiert wird?

Die ACME-HTTP-01-Prüfung schlägt fehl, weil die Let’s-Encrypt-Server Port 80 der Domain nicht erreichen können. Öffnen Sie den Port mit sudo ufw allow 80, führen Sie Certbot aus und entfernen Sie die Regel anschließend mit sudo ufw delete allow 80, wenn die Anwendung keinen HTTP-Dienst bereitstellt.

Kann Certbot im Standalone-Modus in einem Docker-Container verwendet werden?

Ja. Port 80 muss jedoch vom Container auf den Host weitergeleitet werden, und auf Host-Ebene darf kein anderer Prozess gleichzeitig Port 80 belegen. Auch IPv4-/IPv6-Dual-Stack-Probleme können in Docker-Umgebungen zu Binding-Fehlern führen. Tritt ein entsprechender Fehler auf, sollte die Container-Netzwerkkonfiguration und das Port-Mapping überprüft werden. Alternativ kann --preferred-challenges http-01 verwendet werden, um ausdrücklich die HTTP-01-Challenge auszuwählen.

Wie lange ist ein Let’s-Encrypt-Zertifikat gültig und wann wird es erneuert?

Ein Let’s-Encrypt-Zertifikat ist 90 Tage gültig. Der systemd-Timer von Certbot versucht eine Verlängerung, sobald sich das Zertifikat innerhalb der letzten 30 Tage seiner Gültigkeit befindet. Sind die benötigten Pre-Hooks und Post-Hooks korrekt eingerichtet und ist Port 80 während der Verlängerung verfügbar, ist kein manueller Eingriff erforderlich.

Ist Snap die empfohlene Installationsmethode für Certbot unter Ubuntu 20.04?

Ja. Die EFF empfiehlt für Ubuntu 20.04 und neuere Versionen die Installation von Certbot über Snap. Das Paket python3-certbot aus den apt-Paketquellen wird upstream nicht mehr aktiv gepflegt. Bei der Snap-Installation können aktuelle Certbot-Versionen außerdem automatisch über den Snap-Refresh-Mechanismus bereitgestellt werden.

Fazit

In dieser Anleitung wurde Certbot unter Ubuntu 20.04 über Snap installiert, die Firewall für die ACME-HTTP-01-Challenge auf Port 80 sowie für HTTPS-Verbindungen auf Port 443 konfiguriert, ein Zertifikat mit certbot certonly --standalone angefordert, die Zertifikatsinformationen mit OpenSSL überprüft und die automatische Verlängerung über den systemd-Timer von Certbot zusammen mit Pre-Hook- und Post-Hook-Skripten eingerichtet.

Die Zertifikatsdateien unter /etc/letsencrypt/live/your_domain/ können nun verwendet werden, um TLS für Dienste auf dem Server einzurichten. Die Verlängerung erfolgt automatisch, ohne dass ein manueller Eingriff erforderlich ist, sofern die konfigurierten Pre-Hooks und Post-Hooks sicherstellen, dass Port 80 bei jedem Verlängerungsversuch verfügbar ist.