Certbot Apache Ubuntu 24.04 installieren

Was Sie erstellen

Eine Apache-Website auf Ubuntu 24.04, die über HTTPS antwortet. Sie verwendet ein kostenloses, von Browsern vertrauenswürdiges Let's Encrypt-Zertifikat. Dieses wird durch Certbot ausgestellt und automatisch durch einen systemd-Timer erneuert, der im Hintergrund läuft. Der Befehl für die Einrichtung besteht aus nur einer Zeile. Alle Fehler treten vor dieser Zeile auf: Ein vhost ohne ServerName, Port 80 ist in der Firewall des Providers geschlossen oder die DNS-Einträge zeigen noch auf den alten Server. Daher konzentriert sich diese Anleitung primär auf die Voraussetzungen und nennt die exakten Fehlermeldungen für jeden Fehler.

Zwei Hinweise zum Umfang. Wenn Ihr Webserver nginx verwendet, ist der Ablauf identisch, aber das Plugin und die Konfigurationen unterscheiden sich. Nutzen Sie stattdessen die nginx-Version dieser Anleitung. Wenn das Zielsystem nur intern erreichbar ist – etwa ein Admin-Panel unter einer privaten Adresse oder ein Staging-Server ohne externen Zugriff – benötigen Sie keine Zertifizierungsstelle. Ein selbstsigniertes Zertifikat erfordert weniger Konfigurationsaufwand und funktioniert offline.

Voraussetzungen und die drei Gründe für ein Scheitern vor dem Start von Certbot

• Apache stellt Ihre Website bereits über plain HTTP bereit. Das Apache-Plugin von Certbot bearbeitet eine bestehende Website; es erstellt keine neue. Wenn Sie mit einem leeren VPS beginnen, installieren Sie zuerst den LAMP stack on Ubuntu 24.04 und kehren Sie dann zurück — dieser Leitfaden ist das fehlende TLS-Kapitel dazu.
• Eine öffentliche Domain mit einem A-Record auf der IP-Adresse Ihres VPS. Der HTTP-01-Challenge von Let's Encrypt bedeutet, dass sich deren Validierungsserver über das Internet mit Ihrem System verbinden: keine NAT-basierten Homelabs ohne Portweiterleitung, keine .local-Namen, keine nackten IPs. dig +short example.com muss die Adresse Ihres VPS zurückgeben. Falls Sie die DNS-Einstellungen in der letzten Stunde geändert haben, warten Sie die TTL des alten Records ab, bevor Sie den Prozess starten.
• Falls ein AAAA-Record existiert, muss dieser korrekt sein. Let's Encrypt bevorzugt IPv6, wenn ein AAAA-Record veröffentlicht wurde. Ein veralteter AAAA-Record führt zum Validierungsfehler, selbst wenn der Zugriff via curl von Ihrem Laptop — wahrscheinlich über IPv4 — problemlos funktioniert. Veröffentlichen Sie einen korrekten AAAA-Record oder gar keinen.

Die Ports 80 und 443 müssen sowohl in ufw als auch in der Netzwerk-Firewall Ihres Providers geöffnet sein — die meisten Hosting-Panels besitzen eine zweite Firewall, die das Betriebssystem nicht sieht. HTTP-01 validiert spezifisch über Port 80; ein Betrieb nur über Port 443 ist nicht möglich.

sudo ufw allow "Apache Full"
sudo ufw status

Wenn diese Voraussetzungen erfüllt sind, dauert die gesamte Aufgabe etwa fünfzehn Minuten, wobei zehn Minuten für das Lesen benötigt werden.

Snap oder apt Certbot? Auf 24.04 ist apt endlich ausreichend

Certbot wurde vor Jahren aus gutem Grund auf die Snap-Distribution umgestellt: Distro-Pakete veralten. Ubuntu 20.04 lieferte Certbot 0.40 aus und wurde nicht aktualisiert, was dazu führte, dass das Projekt Fehler aus fünf Jahren beheben musste. Auf 24.04 entfällt dieser Grund – das Archiv liefert Certbot 2.9.0, eine aktuelle Version, und unattended-upgrades hält sie auf dem neuesten Stand. Meine Empfehlung für dieses Betriebssystem: Nutzen Sie apt. Sie vermeiden den snapd-Daemon, das Apache-Plugin wird im selben Vorgang installiert und der Erneuerungs-Timer lässt sich auf herkömmliche Debian-Art in systemd integrieren.

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

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

Snap ist in zwei Fällen weiterhin die richtige Wahl: Wenn Sie die neueste Certbot-Version direkt nach der Veröffentlichung benötigen oder wenn Sie ein DNS-Plugin benötigen, das nur als Snap bereitgestellt wird (viele der certbot-dns-*-Provider-Plugins sind dies). 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

Egal für welche Methode Sie sich entscheiden, führen Sie niemals beide aus. Zwei Installationen führen dazu, dass zwei Erneuerungs-Scheduler um /etc/letsencrypt konkurrieren, und die certbot, die Ihre Shell in PATH findet, ist möglicherweise nicht diejenige, die Ihre Zertifikate verwaltet. Die apt remove-Zeile oben ist keine optionale Dekoration.

Die Certbot-vhost-Änderungen müssen bereits existieren — ServerName ist entscheidend

certbot --apache funktioniert, indem es den Port-80-Virtual-Host sucht, dessen ServerName oder ServerAlias mit jedem übergebenen -d-Domain übereinstimmt. Dadurch wird die Kontrolle über die Domain nachgewiesen und eine SSL-Kopie dieses vhost erstellt. Ohne passenden ServerName gibt es keine Übereinstimmung — und das Standard-000-default.conf von Ubuntu liefert ServerName auskommentiert aus. Diese eine auskommentierte Zeile ist der häufigste Grund, warum der große Befehl in dieser Anleitung fehlschlägt.

Bevor Sie Certbot verwenden, müssen Sie der Website einen korrekten namensbasierten vhost zuweisen. 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 diesen und bestätigen Sie, dass Apache die Konfiguration parst und den Namen korrekt weiterleitet:

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

configtest muss Syntax OK ausgeben. Falls auch AH00558: apache2: Could not reliably determine the server's fully qualified domain name ausgegeben wird, handelt es sich um eine Warnung bezüglich des globalen ServerName, nicht Ihres vhost — dies ist hier harmlos und wird durch echo "ServerName $(hostname -f)" | sudo tee /etc/apache2/conf-available/servername.conf && sudo a2enconf servername && sudo systemctl reload apache2 unterdrückt.

Die -S-Ausgabe 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 alias www.example.com darunter — Apache meldet den sites-enabled-Symlink, den er tatsächlich gelesen hat, nicht die Datei, die Sie in sites-available bearbeitet haben. Wenn example.com nicht für Port 80 gelistet ist, kann Certbot ihn ebenfalls nicht finden.

Zertifikat ausstellen: certbot --apache

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

Der erste Durchlauf stellt drei Fragen: eine E-Mail-Adresse (wird für Ihr ACME-Konto und dringende CA-Meldungen verwendet; Let's Encrypt versendet keine Ablaufwarnungen mehr, daher liegt die Überwachung der Erneuerungen in Ihrer Verantwortung), die Zustimmung zu den Let's Encrypt-Bedingungen und die Frage, ob Sie Ihre E-Mail-Adresse mit der EFF teilen möchten. Es gibt keine Frage zur Weiterleitung mehr: Seit Certbot 2.0 leitet der Apache-Installer HTTP standardmäßig auf HTTPS um, was dem gewünschten Verhalten entspricht. Verwenden Sie --no-redirect, wenn Sie explizit plain HTTP benötigen, um Inhalte weiterhin über diesen Dienst bereitzustellen.

Ein Erfolg sieht wie folgt aus. Lesen Sie diese Meldung vollständig durch:

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 2026-10-14.

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

Im Hintergrund hat Certbot vier Schritte ausgeführt: Das Apache ssl Modul wurde aktiviert, falls es noch nicht aktiv war. Es wurde example.com-le-ssl.conf erstellt – eine Kopie Ihres vhost auf *:443 mit SSLEngine on und den Zertifikatspfaden – und aktiviert. Zudem wurde ein RewriteRule Block zum ursprünglichen Port-80 vhost hinzugefügt, der alle Anfragen per 301 auf HTTPS umleitet. Ihre ursprüngliche vhost-Datei wird bearbeitet und nicht ersetzt. Die SSL-Kopie liegt daneben, sodass Sie jede hinzugefügte Zeile einsehen können.

Where the certificate actually lives, and why you never copy it

Everything lands under /etc/letsencrypt/live/example.com/: fullchain.pem (the certificate plus intermediate chain — what servers should point at), privkey.pem (the private key, root-readable only), plus cert.pem and chain.pem for software that wants the pieces separately. These are symlinks into /etc/letsencrypt/archive/, and that indirection is the renewal mechanism: renewal writes new files into archive/ and repoints the symlinks. Point any other software at the live/ paths and it picks up renewals for free; copy the files somewhere and you have built yourself an outage 90 days out.

The other file worth knowing is /etc/letsencrypt/renewal/example.com.conf, which records how this certificate was issued — authenticator = apache, installer = apache, the domains — so renewal can repeat the process unattended, including reloading Apache afterward.

Die Erneuerung ist bereits geplant – Überprüfen Sie diese, anstatt sie manuell zu starten

Let's Encrypt Zertifikate sind standardmäßig auf 90 Tage ausgelegt. Das installierte apt-Paket enthält bereits die notwendige Infrastruktur: einen systemd-Timer, der Certbot zweimal täglich zu zufälligen Zeiten ausführt. Dabei werden alle Zertifikate erneuert, deren Ablaufdatum weniger als 30 Tage in der Zukunft liegt. Erstellen Sie keinen zusätzlichen cron-Job; ein zweiter Scheduler verursacht lediglich Log-Einträge und erhöht das Risiko für Rate-Limits.

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

Der erste Befehl zeigt den aktiven Timer an, wobei der nächste Ausführungszeitpunkt (NEXT) innerhalb der nächsten 24 Stunden liegt. Der Zeitplan sieht zwei Ausführungen pro Tag mit zufälliger Verzögerung vor, weshalb der exakte Zeitpunkt absichtlich unvorhersehbar ist (bei einer snap-Installation ist der Timer snap.certbot.renew.timer). Der dry run führt eine vollständige Simulation der Erneuerung gegen die Let's Encrypt staging-Umgebung durch – mit echten Challenges, aber ohne ausgestelltes Zertifikat und ohne Verbrauch von Rate-Limits. Ein korrekter Durchlauf endet mit:

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

Wenn der dry run fehlschlägt, wird die tatsächliche Erneuerung in ca. 60 Tagen ebenfalls fehlschlagen. Beheben Sie den Fehler sofort, solange das aktuelle Zertifikat noch eine ausreichende Restlaufzeit besitzt. Die häufigste Ursache ist eine Firewall-Regel, die nach der Ausstellung hinzugefügt wurde und Port 80 wieder geschlossen hat.

Überprüfung mit curl und die erwarteten Informationen des Schlosssymbols

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 – dies ist die Weiterleitung, die Certbot installiert hat. Der zweite sollte HTTP/1.1 200 OK zurückgeben, ohne dass curl eine TLS-Fehlermeldung ausgibt. Der dritte Befehl gibt den Aussteller aus – eine O = Let's Encrypt-Zeile mit einem kurzen CN wie R12 oder E7 – sowie notAfter mit einer Restlaufzeit von etwa 90 Tagen. In einem Browser erscheint das Schlosssymbol; ein Klick darauf zeigt denselben Aussteller an. Wenn curl funktioniert, der Browser jedoch eine Warnung anzeigt, liegt das Problem höchstwahrscheinlich an einer gecachten Seite oder einem falschen Hostnamen und nicht an dem Zertifikat.

Mehrere Websites: ein SAN-Zertifikat oder ein Zertifikat pro Website

Beide Methoden funktionieren; die Erneuerung erfolgt identisch. Bei nicht zusammenhängenden Websites auf demselben System führen Sie den Befehl pro Website einmal aus. Jede Website erhält ein eigenes Verzeichnis unter live/ sowie eine eigene Konfiguration zur Erneuerung. Ein Problem mit einer Domain verhindert nicht die Erneuerung der anderen. Dies ist die Standardvorgehensweise.

Verwenden Sie für eine Website mit mehreren Namen ein einzelnes SAN-Zertifikat – ein Zertifikat kann bis zu 100 Namen enthalten. Dies haben Sie oben mit example.com und www.example.com bereits durchgeführt. Um später einen Namen zu einem bestehenden Zertifikat hinzuzufügen, führen Sie die Neuerstellung mit dem Zertifikatsnamen und der vollständigen neuen Liste aus:

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

Certbot erkennt die geänderte Domain-Liste, fordert Sie zur Bestätigung der Erweiterung auf und ersetzt das Zertifikat an derselben Stelle – im selben live/-Pfad, sodass keine weiteren Anpassungen erforderlich sind. Beachten Sie, dass die Liste eine vollständige Ersetzung und keine Erweiterung ist: Wenn Sie www in diesem Befehl weglassen, wird die Domain im neuen Zertifikat ohne Fehlermeldung entfernt.

Wildcards benötigen DNS-01, und meistens benötigen Sie keine Wildcards

HTTP-01 kann *.example.com nicht ausstellen — das Platzieren einer Datei auf einem Webserver beweist die Kontrolle über einen einzelnen Hostnamen, nicht über einen gesamten Namespace. Wildcards erfordern die DNS-01-Challenge: Certbot setzt einen TXT-Record bei _acme-challenge.example.com. In der Praxis bedeutet dies entweder die Verwendung eines certbot-dns-*-Plugins mit API-Zugangsdaten für Ihren DNS-Provider oder das manuelle Bearbeiten von TXT-Records bei jeder Erneuerung mit --manual (mühsam — planen Sie dies nicht ein). Die vollständige Anleitung, von der Funktionsweise der TXT-Records bis hin zu einem Plugin für die automatische Erneuerung, finden Sie in Wildcard-Zertifikate mit Certbot über DNS-01. Ein ehrlicher Rat: Wenn Sie vier bekannte Subdomains haben, ist ein SAN-Zertifikat, das alle vier auflistet, einfacher als eine Wildcard und benötigt keine DNS-API-Keys auf dem Server.

Fehlerursachen und die angezeigten Meldungen

Certbot bricht den Start ab, da 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. Wenn Apache fehlerhaft ist, bricht der Vorgang ab — die \ns sind wörtlich zu nehmen, da Certbot die repr-Ausgabe der Exception ausgibt. Führen Sie sudo apache2ctl configtest selbst aus: Die Meldung nennt die Datei und die Zeile — meist handelt es sich um Tippfehler durch manuelle Bearbeitung, einen SSLCertificateFile auf einen nicht mehr existierenden Pfad oder ein referenziertes, aber nicht aktiviertes Modul. Beheben Sie den Fehler, bis Syntax OK ausgegeben wird, und starten Sie Certbot dann 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 Fehler durch fehlende ServerName, der erst während der Ausstellung erkannt wird. Certbot hat alle aktivierten Port-80-vhosts nach einem ServerName/ServerAlias passend zu Ihrer -d durchsucht und nichts gefunden. sudo apache2ctl -S zeigt die tatsächliche Apache-Routing-Konfiguration; fügen Sie die ServerName-Zeile zum korrekten vhost hinzu, laden Sie die Konfiguration neu und versuchen Sie es erneut. Eine ähnliche Ursache ist die Validierung gegen den falschen vhost — die Challenge-Antwort erfolgt mit Invalid response ... 404, weil eine andere Website die Anfrage empfangen hat. Die Diagnose und das Werkzeug bleiben gleich: apache2ctl -S.

Validierung läuft in ein Timeout.

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

Let's Encrypt konnte keine TCP-Verbindung zu Port 80 unter der von Ihrem DNS angegebenen Adresse herstellen. Wahrscheinlichste Ursachen: Die Netzwerk-Firewall Ihres Providers (unabhängig von ufw, konfiguriert im Hosting-Panel), ein ufw-Regelwerk, das nur 443 oder nur SSH erlaubt, DNS, das noch auf einen alten Server zeigt, oder das Stale-AAAA-Problem — die Server von Let's Encrypt versuchen IPv6, Ihr Server antwortet jedoch nur auf IPv4. Testen Sie dies von außerhalb des VPS aus: curl -I http://example.com von Ihrem Laptop reproduziert das Verhalten des Validators.

Durch wiederholte Versuche wurde ein Rate Limit erreicht.

Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/

Let's Encrypt erlaubt 5 fehlgeschlagene Validierungen pro Hostname pro Account pro Stunde — seit der Überarbeitung der Rate-Limits im Jahr 2025 handelt es sich um ein "Refilling Bucket"-Modell, bei dem etwa alle 12 Minuten ein neuer Versuch möglich ist. Häufige Wiederholungsversuche bei einer defekten Firewall verbrauchen das Kontingent schnell. Warten hilft, aber die eigentliche Lösung ist die Vorgehensweise: Debuggen Sie nach jedem Fehler mit der Staging-Umgebung, bis der Test erfolgreich ist.

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

Beachten Sie certonly: --dry-run wird nur von den Subcommands certonly und renew akzeptiert. Die nackte Form certbot --apache --dry-run bricht den Vorgang komplett ab und gibt --dry-run currently only works with the 'certonly' or 'renew' subcommands aus. Der Dry-Run validiert gegen die Staging-Umgebung. Diese hat eigene, großzügige Limits und stellt keine echten Zertifikate aus, sodass Sie dort beliebig viele Fehlversuche durchführen können. Führen Sie den echten Befehl erst aus, wenn der Staging-Test erfolgreich war. Die anderen Limits — 50 Zertifikate pro registrierter Domain pro Woche, 5 Duplikate desselben Namensatzes pro Woche — treten nur auf, wenn ein Skript Zertifikate in einer Endlosschleife neu ausstellt.

Sobald HTTPS aktiv ist, beachten Sie, dass das Zertifikat nur den Transport absichert, nicht den Server: Port 22 ist weiterhin anfällig für Brute-Force-Angriffe. Die Kombination mit Fail2ban auf Ubuntu 24.04 ist der logische nächste Schritt.

FAQ

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

Verwenden Sie apt. Ubuntu 24.04 enthält Certbot 2.9.0. Diese Version ist für alle Schritte in diesem Leitfaden aktuell genug, erhält Sicherheitsupdates über unattended-upgrades und benötigt kein snapd. Wählen Sie snap nur, wenn Sie sofort die neueste Version benötigen oder ein DNS-Plugin nutzen müssen, das exklusiv als snap verteilt wird. Falls Sie wechseln, deinstallieren Sie apt remove certbot python3-certbot-apache zuerst, damit keine zwei Erneuerungs-Scheduler gleichzeitig existieren.

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

Der Fehler tritt auf, weil kein aktivierter Port-80-vhost einen ServerName oder ServerAlias besitzt, der mit der Domain übereinstimmt, die Sie mit -d übergeben haben. Der Standard-vhost von Ubuntu hat 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 den Port 80 unter der durch DNS veröffentlichten Adresse nicht erreichen. Prüfen Sie die Netzwerk-Firewall im Panel Ihres Anbieters sowie ufw. Bestätigen Sie, dass dig +short example.com diese VPS zurückgibt, und löschen oder korrigieren Sie veraltete AAAA-Records — die Validierung bevorzugt IPv6, falls vorhanden. Überprüfen Sie die Behebung von außerhalb des Servers mit curl -I http://example.com und testen Sie dies mit sudo certbot certonly --apache --dry-run -d example.com vor der echten Zertifikatserstellung.

Erneuert Certbot Zertifikate auf Ubuntu 24.04 automatisch?

Ja. Das apt-Paket installiert certbot.timer, einen systemd-Timer, der zweimal täglich läuft und jedes Zertifikat innerhalb von 30 Tagen vor Ablauf erneuert und anschließend Apache neu lädt. Die snap-Version nutzt snap.certbot.renew.timer für dieselbe Aufgabe. Überprüfen Sie dies mit systemctl list-timers certbot.timer und testen Sie es mit sudo certbot renew --dry-run — erstellen Sie keinen eigenen cron-Job zusätzlich dazu.

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

Wildcards erfordern die DNS-01-Challenge: Certbot muss einen TXT-Record bei _acme-challenge.example.com hinterlegen. Dies erfordert ein certbot-dns-*-Plugin mit API-Zugangsdaten für Ihren DNS-Anbieter (die --manual-Alternative erfordert manuelle TXT-Records bei jeder Erneuerung). Wenn Sie nur wenige bekannte Subdomains haben, ist ein SAN-Zertifikat, das diese explizit auflistet, einfacher und verhindert, dass DNS-API-Keys auf dem Server liegen.