Certbot für Apache auf Ubuntu 24.04 installieren

Was Sie einrichten

Eine Apache-Site auf Ubuntu 24.04, die HTTPS verwendet und mit einem kostenlosen, von Browsern vertrauenswürdigen Let's-Encrypt-Zertifikat antwortet. Certbot stellt das Zertifikat aus. Ein systemd-Timer erneuert es automatisch, ohne dass Sie sich später darum kümmern müssen. Der dafür erforderliche Befehl besteht aus einer Zeile. Alles, was schiefgeht, tritt vor dieser Zeile auf: ein VHost ohne ServerName, Port 80 ist in der Firewall des Providers geschlossen oder DNS zeigt noch auf den alten Server. Deshalb konzentriert sich diese Anleitung größtenteils auf die Voraussetzungen und nennt für jeden Fehler die genaue Fehlermeldung.

Zwei Hinweise zum Geltungsbereich. Wenn Ihr Webserver nginx ist, ist der Ablauf grundsätzlich gleich, aber Plugin und Konfiguration unterscheiden sich. Verwenden Sie in diesem Fall stattdessen die nginx-Version dieser Anleitung. Wenn der abzusichernde Dienst jedoch nur intern erreichbar ist, etwa ein Administrationsbereich unter einer privaten Adresse oder ein Staging-Server, den sonst niemand aufruft, benötigen Sie keine Zertifizierungsstelle. Ein selbstsigniertes Zertifikat verursacht weniger Aufwand und funktioniert offline.

Voraussetzungen und die drei Fälle, in denen es bereits vor dem Start von Certbot scheitert

• Apache stellt Ihre Website bereits über unverschlüsseltes HTTP bereit. Das Apache-Plugin von Certbot bearbeitet eine vorhandene Website. Es erstellt keine Website. Wenn Sie mit einem leeren VPS beginnen, richten Sie zuerst den LAMP-Stack unter Ubuntu 24.04 ein und kehren Sie anschließend hierher zurück. Dieser Leitfaden ergänzt ihn um das fehlende TLS-Kapitel.
• Eine öffentliche Domain mit einem A-Record auf die Adresse Ihres VPS. Bei der HTTP-01-Challenge verbinden sich die Validierungsserver von Let's Encrypt aus dem Internet mit Ihrem Server: Ein Homelab hinter NAT funktioniert ohne Portweiterleitung nicht, und auch .local-Namen funktionieren nicht. HTTP-01 kann eine unveränderte IP-Adresse validieren. Let's Encrypt stellt IP-Zertifikate jedoch nur über das aktivierbare shortlived-Profil aus (Gültigkeitsdauer 160 Stunden). Das Certbot 2.9.0 aus apt kann weder ACME-Profile noch IP-Adressen anfordern. Daher benötigt dieser Leitfaden einen Domainnamen. dig +short example.com muss die Adresse Ihres VPS zurückgeben. Wenn Sie DNS in der letzten Stunde geändert haben, warten Sie vor der Ausstellung, bis die TTL des alten Records abgelaufen ist.
• Wenn ein AAAA-Record vorhanden ist, muss er korrekt sein. Let's Encrypt versucht immer zuerst IPv6, wenn ein AAAA-Record veröffentlicht ist. Läuft diese Verbindung in einen Timeout, wird die Validierung über IPv4 wiederholt. Kein anderer Fehler erhält jedoch diese zweite Chance: Ein AAAA-Record auf einer Adresse, die Verbindungen ablehnt, oder auf einem aktiven Server, der nicht dieser Server ist, lässt die Validierung scheitern, selbst wenn curl von Ihrem Laptop aus, wahrscheinlich über IPv4, problemlos funktioniert. Veröffentlichen Sie einen korrekten AAAA-Record oder keinen.

Port 80 und Port 443 müssen in ufw und in der Netzwerk-Firewall Ihres Providers geöffnet sein. Die meisten Hosting-Panels verfügen über eine zweite Firewall, die das Betriebssystem nicht sieht. HTTP-01 validiert ausdrücklich über Port 80. Sie können diesen Ablauf nicht ausschließlich über Port 443 betreiben.

sudo ufw allow "Apache Full"
sudo ufw status

Wenn diese Voraussetzungen erfüllt sind, dauert die gesamte Einrichtung fünfzehn Minuten. Zehn davon entfallen auf das Lesen.

Certbot per Snap oder apt? Unter 24.04 ist apt endlich eine gute Wahl

Certbot wechselte vor Jahren aus gutem Grund zur Snap-Distribution: Die Pakete der Distributionen veralteten. Ubuntu 20.04 enthielt Certbot 0.40 und aktualisierte es nie. Das Projekt hatte genug davon, Fehler in fünf Jahre alten Versionen zu untersuchen. Unter 24.04 ist dieser Grund entfallen. Das Archiv enthält Certbot 2.9.0, eine im Februar 2024 veröffentlichte Version aus der modernen 2.x-Reihe. unattended-upgrades installiert dafür alle Sicherheitsupdates, die Ubuntu bereitstellt. Upstream ist inzwischen zur 5.x-Reihe weitergegangen, aber dieses Handbuch benötigt keine Funktionen daraus. Meine Empfehlung für dieses Betriebssystem lautet: Verwenden Sie apt. Sie benötigen weder den snapd-Daemon, noch müssen Sie den Apache-Plugin separat installieren. Er wird in derselben Transaktion installiert. Außerdem ist der Erneuerungs-Timer auf die übliche Debian-Art in systemd integriert.

sudo apt update
sudo apt install -y certbot python3-certbot-apache
certbot --version

Das korrekte Ergebnis lautet: certbot 2.9.0. Das Paket python3-certbot-apache ist das Plugin, das Ihre Apache-Konfigurationen liest und bearbeitet. Ohne dieses Paket schlägt certbot --apache mit The requested apache plugin does not appear to be installed fehl.

Snap ist weiterhin in zwei Fällen die richtige Wahl: Sie möchten am Tag der Veröffentlichung die neueste Certbot-Version verwenden, oder Sie benötigen ein DNS-Plugin, das nur als Snap verteilt wird. Das trifft auf mehrere Provider-Plugins von certbot-dns-* zu. Wenn Sie diesen Weg wählen:

sudo apt remove -y certbot python3-certbot-apache
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

Unabhängig von Ihrer Wahl dürfen Sie niemals beide Varianten installieren. Zwei Installationen bedeuten zwei Erneuerungsplaner, die um /etc/letsencrypt konkurrieren. Außerdem ist das certbot, das Ihre Shell in PATH findet, möglicherweise nicht die Installation, der Ihre Zertifikate gehören. Die oben aufgeführte Zeile apt remove ist keine optionale Dekoration.

Die von Certbot bearbeiteten vhosts müssen bereits vorhanden sein, ServerName ist entscheidend

certbot --apache sucht den virtuellen Host für Port 80, dessen ServerName oder ServerAlias mit jeder von Ihnen angegebenen -d-Domain übereinstimmt. Anschließend weist es darüber die Kontrolle über die Domain nach und erstellt eine SSL-Kopie dieses vhosts. Ohne passenden ServerName gibt es keine Übereinstimmung. Außerdem wird 000-default.conf von Ubuntu mit auskommentiertem ServerName ausgeliefert. Diese eine auskommentierte Zeile ist der häufigste Grund dafür, dass der eine große Befehl aus dieser Anleitung fehlschlägt.

Bevor Sie Certbot ausführen, konfigurieren Sie daher einen ordentlichen namensbasierten vhost für die Site. Erstellen Sie /etc/apache2/sites-available/example.com.conf:

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com
    ErrorLog ${APACHE_LOG_DIR}/example.com-error.log
    CustomLog ${APACHE_LOG_DIR}/example.com-access.log combined
</VirtualHost>

Aktivieren Sie ihn und prüfen Sie, ob Apache die Konfiguration einliest und den Namen an diesen vhost weiterleitet:

sudo a2ensite example.com.conf
sudo apache2ctl configtest
sudo systemctl reload apache2
sudo apache2ctl -S

configtest muss Syntax OK ausgeben. Wenn zusätzlich AH00558: apache2: Could not reliably determine the server's fully qualified domain name ausgegeben wird, ist das eine Warnung zum globalen ServerName, nicht zu Ihrem vhost. Sie ist hier unkritisch und lässt sich mit echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2 unterdrücken.

Die Ausgabe von -S ist die entscheidende Prüfung. Sie benötigen eine Zeile wie port 80 namevhost example.com (/etc/apache2/sites-enabled/example.com.conf:1) mit eingerücktem alias www.example.com darunter. Apache meldet den sites-enabled-Symlink, den es tatsächlich eingelesen hat, nicht die Datei, die Sie in sites-available bearbeitet haben. Wenn example.com nicht für Port 80 aufgeführt ist, wird Certbot den vhost ebenfalls nicht finden.

Zertifikat ausstellen: certbot --apache

sudo certbot --apache -d example.com -d www.example.com

Beim ersten Start werden drei Dinge abgefragt: eine E-Mail-Adresse (Let's Encrypt speichert sie nicht mehr zusammen mit Ihrem ACME-Konto und sendet keine Ablaufwarnungen mehr, daher müssen Sie die Erneuerungen selbst überwachen), die Zustimmung zu den Nutzungsbedingungen von Let's Encrypt und ob Ihre E-Mail-Adresse an die EFF weitergegeben werden darf. Eine Frage zur Weiterleitung gibt es nicht mehr: Seit Certbot 1.0 leitet das Apache-Installationsprogramm HTTP standardmäßig auf HTTPS um (die Frage selbst wurde in 1.4 entfernt). Das ist in diesem Fall gewünscht. Verwenden Sie --no-redirect nur dann, wenn Inhalte weiterhin ausdrücklich über unverschlüsseltes HTTP bereitgestellt werden müssen.

Ein erfolgreicher Ablauf sieht so aus. Lesen Sie die Ausgabe vollständig, statt sie nur zu überfliegen:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2027-01-09.

Deploying certificate
Successfully deployed certificate for example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Successfully deployed certificate for www.example.com to /etc/apache2/sites-available/example.com-le-ssl.conf
Congratulations! You have successfully enabled HTTPS on https://example.com and https://www.example.com

Hinter dieser Meldung hat Certbot vier Dinge erledigt: Es hat das Apache-Modul ssl aktiviert, falls es noch nicht aktiviert war, und example.com-le-ssl.conf geschrieben. Dabei handelt es sich um eine Kopie Ihres vhost unter *:443 mit SSLEngine on und den Pfaden zu den Zertifikaten. Anschließend wurde dieser vhost aktiviert. Außerdem hat Certbot dem ursprünglichen vhost für Port 80 einen RewriteRule-Block hinzugefügt, der alle Anfragen mit einer 301-Weiterleitung auf HTTPS umleitet. Ihre ursprüngliche vhost-Datei wurde bearbeitet, nicht ersetzt. Die SSL-Kopie liegt daneben, sodass Sie jede hinzugefügte Zeile prüfen können.

Wo das Zertifikat tatsächlich liegt und warum Sie es niemals kopieren

Alles wird unter /etc/letsencrypt/live/example.com/ abgelegt: fullchain.pem (das Zertifikat einschließlich Zwischenzertifikatskette, auf das Server verweisen sollten), privkey.pem (der private Schlüssel, nur für root lesbar) sowie cert.pem und chain.pem für Software, die die Bestandteile getrennt benötigt. Dabei handelt es sich um symbolische Links nach /etc/letsencrypt/archive/. Diese Indirektion ermöglicht die Erneuerung: Der Erneuerungsprozess schreibt neue Dateien nach archive/ und setzt die symbolischen Links auf diese Dateien. Verweisen Sie jede andere Software auf die Pfade unter live/. Dann übernimmt sie Erneuerungen automatisch. Wenn Sie die Dateien an einen anderen Ort kopieren, ist ein Ausfall nach 90 Tagen vorprogrammiert.

Die andere wichtige Datei ist /etc/letsencrypt/renewal/example.com.conf. Sie dokumentiert, wie dieses Zertifikat ausgestellt wurde: authenticator = apache, installer = apache und die Domains. Dadurch kann die Erneuerung den Vorgang unbeaufsichtigt wiederholen, einschließlich eines anschließenden Reloads von Apache.

Die Erneuerung ist bereits geplant – prüfen Sie sie, statt sie neu einzurichten

Let's-Encrypt-Zertifikate sind standardmäßig 90 Tage gültig. Das apt-Paket hat die erforderliche Infrastruktur bereits installiert: einen systemd-Timer, der Certbot zweimal täglich zu zufällig bestimmten Zeiten ausführt und jedes Zertifikat erneuert, dessen Ablauf innerhalb der nächsten 30 Tage liegt. Fügen Sie keinen cron-Job hinzu. Ein zweiter Scheduler erzeugt nur zusätzliche Logeinträge und ein weiteres Risiko für Rate-Limits. Let's Encrypt hat angekündigt, dass neue Zertifikate ab dem 10. Februar 2027 standardmäßig 64 Tage gültig sein werden. Das 30-Tage-Fenster funktioniert auch dann weiter. Die Erneuerung erfolgt lediglich ungefähr am 34. statt am 60. Tag. Auf diesem Server ist daher keine Änderung erforderlich.

systemctl list-timers certbot.timer
sudo certbot renew --dry-run

Der erste Befehl zeigt, dass der Timer aktiv ist. NEXT enthält einen Zeitpunkt innerhalb der nächsten 24 Stunden. Der Zeitplan sieht zwei Ausführungen pro Tag mit einer zufälligen Verzögerung vor. Der genaue Zeitpunkt ist daher absichtlich nicht vorhersehbar. Bei der snap-Installation lautet der Timer stattdessen snap.certbot.renew.timer. Der Testlauf simuliert eine vollständige Erneuerung über die Staging-Umgebung von Let's Encrypt. Dabei wird eine echte Challenge ausgeführt, aber kein Zertifikat ausgestellt und kein Rate-Limit-Kontingent verbraucht. Ein erfolgreicher Lauf endet mit:

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

Wenn der Testlauf fehlschlägt, wird die tatsächliche Erneuerung in ungefähr 60 Tagen aus demselben Grund fehlschlagen. Beheben Sie das Problem jetzt, solange das aktuelle Zertifikat noch seine gesamte Gültigkeitsdauer vor sich hat. Die häufigste Ursache ist eine Firewall-Regel, die nach der Ausstellung hinzugefügt wurde und Port 80 wieder geschlossen hat.

Mit curl prüfen und was das Vorhängeschloss anzeigen sollte

curl -sI http://example.com | head -n 3
curl -I https://example.com
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -dates

Der erste Befehl sollte HTTP/1.1 301 Moved Permanently mit einem Location: https://example.com/-Header zurückgeben. Dabei handelt es sich um die von Certbot eingerichtete Weiterleitung. Der zweite sollte HTTP/1.1 200 OK zurückgeben, ohne dass curl einen TLS-Fehler meldet. Der dritte gibt den Aussteller aus, eine O = Let's Encrypt-Zeile mit einem kurzen CN wie YE1 oder YE2 (ECDSA-Schlüssel) beziehungsweise YR1 oder YR2 (RSA-Schlüssel) sowie notAfter, also ungefähr 90 Tage in der Zukunft. Ein Zertifikat, das ausgestellt wurde, bevor Let's Encrypt seine älteren Zwischenzertifikate außer Betrieb genommen hat, kann bis zur nächsten Erneuerung weiterhin einen CN wie R12 oder E7 anzeigen. Das ist kein Fehler. Im Browser wird das Vorhängeschloss angezeigt. Wenn Sie darauf klicken, sehen Sie denselben Aussteller. Wenn curl funktioniert und der Browser eine Warnung anzeigt, sehen Sie mit hoher Wahrscheinlichkeit eine zwischengespeicherte Seite oder den falschen Hostnamen und kein Zertifikatsproblem.

Mehrere Sites: ein SAN-Zertifikat oder ein Zertifikat pro Site

Beides funktioniert; die Erneuerung erfolgt auf dieselbe Weise. Für voneinander unabhängige Sites auf demselben Server führen Sie den Issue-Befehl einmal pro Site aus. Jede Site erhält ein eigenes Verzeichnis unter live/ und eine eigene Erneuerungskonfiguration. Ein Problem mit einer Domain verhindert dadurch nie die Erneuerung der anderen. Das ist meine Standardempfehlung.

Für eine Site mit mehreren Namen tragen Sie alle Namen in ein SAN-Zertifikat ein. Ein einzelnes Zertifikat kann bis zu 100 Namen enthalten. Das haben Sie oben bereits mit example.com und www.example.com umgesetzt. Um einem vorhandenen Zertifikat später einen Namen hinzuzufügen, stellen Sie es neu aus. Geben Sie dabei den Namen des Zertifikats und die vollständige neue Liste an:

sudo certbot --apache --cert-name example.com -d example.com -d www.example.com -d blog.example.com

Certbot erkennt die geänderte Domainliste und fordert Sie auf, die Erweiterung zu bestätigen. Anschließend ersetzt Certbot das Zertifikat am selben live/-Pfad. Weitere Änderungen sind daher nicht erforderlich. Beachten Sie, dass die Liste ersetzt und nicht erweitert wird: Wenn Sie www in diesem Befehl weglassen, entfernt das neue Zertifikat den Namen ohne weitere Meldung.

Wildcards erfordern DNS-01, und normalerweise benötigen Sie keinen Wildcard

HTTP-01 kann *.example.com nicht ausstellen. Das Ablegen einer Datei auf einem Webserver weist die Kontrolle über einen Hostnamen nach, nicht über einen gesamten Namensraum. Wildcards erfordern die DNS-01-Challenge: Certbot setzt einen TXT-Record unter _acme-challenge.example.com. In der Praxis benötigen Sie dafür ein certbot-dns-*-Plugin mit API-Zugangsdaten für Ihren DNS-Provider oder Sie bearbeiten die TXT-Records bei jeder Erneuerung manuell mit --manual. Das ist unzumutbar und sollte nicht als Grundlage Ihrer Planung dienen. Die vollständige Anleitung – von der Funktionsweise der TXT-Records bis zu einem Plugin für unbeaufsichtigte Erneuerungen – finden Sie unter Wildcard-Zertifikate mit Certbot über DNS-01. Eine klare Empfehlung: Wenn Sie vier bekannte Subdomains haben, ist ein SAN-Zertifikat mit allen vier Einträgen einfacher als ein Wildcard-Zertifikat. Außerdem müssen dann keine DNS-API-Schlüssel auf dem Server hinterlegt werden.

Fehlerbilder und die angezeigten Meldungen

Certbot startet nicht, weil die Apache-Konfiguration fehlerhaft ist.

The apache plugin is not working; there may be problems with your existing configuration.
The error was: MisconfigurationError('Error while running apache2ctl configtest.\n\nAction \'configtest\' failed.\nThe Apache error log may have more information.\n\nAH00526: Syntax error on line 12 of /etc/apache2/sites-enabled/example.com.conf')

Das Plugin führt configtest aus, bevor es Änderungen vornimmt, und beendet sich, wenn Apache selbst einen Fehler meldet. Die \ns sind wörtlich zu verstehen, weil Certbot die Darstellung der Ausnahme ausgibt. Führen Sie sudo apache2ctl configtest selbst aus. Der Befehl nennt Datei und Zeile. Typische Ursachen sind ein Tippfehler nach einer manuellen Bearbeitung, ein SSLCertificateFile auf einen nicht mehr vorhandenen Pfad oder ein referenziertes, aber nicht aktiviertes Modul. Beheben Sie die Fehler, bis Syntax OK ausgegeben wird, und starten Sie Certbot anschließend erneut.

Kein vhost entspricht der Domain.

Unable to find a virtual host listening on port 80 which is currently the only challenge port.

Dies ist der bereits erwähnte Fehler durch ein fehlendes ServerName, der beim Ausstellen des Zertifikats erkannt wird. Certbot hat alle aktivierten vhosts für Port 80 nach einem ServerName/ServerAlias durchsucht, das zu Ihrem -d passt, und keinen gefunden. sudo apache2ctl -S zeigt, wie Apache die Anfragen tatsächlich weiterleitet. Fügen Sie die Zeile ServerName in den richtigen vhost ein, laden Sie Apache neu und versuchen Sie es erneut. Ein ähnlicher Fall ist, dass die Validierung den falschen vhost erreicht. Die Challenge-Antwort lautet dann Invalid response ... 404, weil eine andere Website die Anfrage verarbeitet hat. Die Diagnose ist dieselbe, ebenso das Werkzeug: apache2ctl -S.

Die Validierung läuft in einen Timeout.

Certbot failed to authenticate some domains (authenticator: apache).
...
Detail: ...: Timeout during connect (likely firewall problem)

Let’s Encrypt konnte an der von Ihrem DNS veröffentlichten Adresse keine TCP-Verbindung zu Port 80 herstellen. In der Reihenfolge der Wahrscheinlichkeit sind die Ursachen: die Netzwerk-Firewall Ihres Providers, unabhängig von ufw und im Hosting-Panel konfiguriert; ein ufw-Regelwerk, das nur 443 oder nur SSH zulässt; oder DNS zeigt noch auf einen früheren Server. Ein veralteter AAAA-Eintrag verursacht diesen Fehler normalerweise nicht allein. Wenn der IPv6-Verbindungsversuch in einen Timeout läuft, versucht Let’s Encrypt die Verbindung erneut über IPv4. Probleme mit AAAA zeigen sich stattdessen meist als Connection refused oder als Invalid response vom falschen Server. Testen Sie von außerhalb des VPS: curl -I http://example.com von Ihrem Laptop reproduziert, was der Validator von Let’s Encrypt sieht.

Sie haben durch wiederholte Versuche ein Rate Limit erreicht.

Error creating new order :: too many failed authorizations (5) for "example.com" in the last 1h0m0s, retry after ... UTC: see https://letsencrypt.org/docs/rate-limits/...

Let’s Encrypt erlaubt 5 fehlgeschlagene Validierungen pro Hostname, Account und Stunde. Dabei handelt es sich um ein sich wieder auffüllendes Kontingent, das ungefähr alle 12 Minuten einen weiteren Versuch ermöglicht. Wiederholte Versuche gegen eine fehlerhafte Firewall verbrauchen dieses Kontingent schnell. Warten hilft, die eigentliche Lösung ist jedoch eine Änderung des Vorgehens: Debuggen Sie nach jedem Fehler mit der Staging-Umgebung, bis die Validierung erfolgreich ist.

sudo certbot certonly --apache --dry-run -d example.com -d www.example.com

Beachten Sie das certonly: --dry-run wird nur von den Unterbefehlen certonly und renew akzeptiert. Die alleinstehende Form certbot --apache --dry-run wird überhaupt nicht ausgeführt und meldet --dry-run currently only works with the 'certonly' or 'renew' subcommands. Der Probelauf validiert gegen die Staging-Umgebung. Diese hat großzügigere eigene Limits und stellt keine echten Zertifikate aus, sodass Sie dort den ganzen Nachmittag Fehler beheben können. Führen Sie den echten Befehl erst erneut aus, wenn der Probelauf erfolgreich ist. Die anderen Limits, 50 Zertifikate pro registrierter Domain und Woche sowie 5 Duplikate desselben Namenssatzes pro Woche, erreichen Sie normalerweise nur, wenn ein Skript wiederholt Zertifikate ausstellt.

Sobald HTTPS funktioniert, denken Sie daran: Das Zertifikat schützt den Transport, nicht den Server. Auf Port 22 werden weiterhin den ganzen Tag Passwörter ausprobiert. Die Kombination mit Fail2ban unter Ubuntu 24.04 ist der naheliegende nächste Schritt für die kommenden 30 Minuten.

FAQ

Sollte ich Certbot für Apache unter Ubuntu 24.04 mit snap oder apt installieren?

Verwenden Sie apt. Ubuntu 24.04 enthält Certbot 2.9.0. Diese Version ist für alle Inhalte dieses Leitfadens aktuell genug, erhält alle Sicherheitsupdates, die Ubuntu über unattended-upgrades veröffentlicht, und erfordert kein snapd. Verwenden Sie snap nur, wenn Sie sofort die neueste Version benötigen oder ein DNS-Plugin, das ausschließlich als snap verfügbar ist. Wenn Sie wechseln, deaktivieren Sie zuerst apt remove certbot python3-certbot-apache, damit niemals zwei Erneuerungszeitpläne gleichzeitig aktiv sind.

Warum meldet Certbot „Unable to find a virtual host listening on port 80“?

Weil kein aktivierter VHost für Port 80 einen ServerName oder ServerAlias enthält, der zum mit -d übergebenen Domainnamen passt. Im standardmäßigen VHost von Ubuntu ist ServerName auskommentiert. Führen Sie sudo apache2ctl -S aus, suchen oder erstellen Sie den VHost, der für den Namen zuständig sein soll, fügen Sie ServerName example.com hinzu, laden Sie Apache neu und führen Sie Certbot erneut aus.

Wie behebe ich „Timeout during connect (likely firewall problem)“?

Let's Encrypt konnte Port 80 unter der Adresse nicht erreichen, die Ihr DNS veröffentlicht. Prüfen Sie neben ufw auch die Netzwerk-Firewall auf der Verwaltungsebene Ihres Providers. Stellen Sie sicher, dass dig +short example.com auf diesen VPS verweist. Korrigieren oder löschen Sie außerdem veraltete AAAA-Einträge, da die Validierung zuerst IPv6 verwendet und erst nach einem Timeout auf IPv4 zurückfällt. Prüfen Sie die Korrektur von außerhalb des Servers mit curl -I http://example.com. Testen Sie anschließend den Ablauf mit sudo certbot certonly --apache --dry-run -d example.com, bevor Sie das Zertifikat tatsächlich ausstellen lassen.

Erneuert Certbot Zertifikate unter Ubuntu 24.04 automatisch?

Ja. Das apt-Paket installiert certbot.timer. Dabei handelt es sich um einen systemd-Timer, der zweimal täglich ausgeführt wird und alle Zertifikate erneuert, deren Ablauf höchstens 30 Tage entfernt ist. Anschließend lädt er Apache neu. snap verwendet für dieselbe Aufgabe snap.certbot.renew.timer. Prüfen Sie dies mit systemctl list-timers certbot.timer und testen Sie den Ablauf mit sudo certbot renew --dry-run. Fügen Sie keinen eigenen cron-Job zusätzlich hinzu.

Wie erhalte ich mit Certbot und Apache ein Wildcard-Zertifikat?

Wildcard-Zertifikate erfordern die DNS-01-Challenge. Certbot muss einen TXT-Eintrag unter _acme-challenge.example.com setzen. Dafür benötigen Sie ein certbot-dns-*-Plugin mit API-Zugangsdaten für Ihren DNS-Provider. Die --manual-Alternative erfordert bei jeder Erneuerung manuell bearbeitete TXT-Einträge. Wenn Sie nur wenige bekannte Subdomains haben, ist ein SAN-Zertifikat mit einer expliziten Liste dieser Subdomains einfacher. Außerdem bleiben die DNS-API-Schlüssel dadurch vom Server fern.