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 Gründe, warum dies scheitert, bevor Certbot überhaupt ausgeführt wird

• 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 auf 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 von Let's Encrypt verbinden sich die Validierungsserver aus dem Internet mit Ihrem System. Ein Homelab hinter NAT ohne Portweiterleitung funktioniert nicht. Das gilt auch für .local-Namen und reine IP-Adressen. dig +short example.com muss die Adresse Ihres VPS zurückgeben. Wenn Sie die DNS-Konfiguration 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 bevorzugt IPv6, wenn ein AAAA-Record veröffentlicht ist. Ein veralteter AAAA-Record führt daher zu einer fehlgeschlagenen Validierung, obwohl curl von Ihrem Laptop aus, wahrscheinlich über IPv4, problemlos funktioniert. Veröffentlichen Sie einen korrekten AAAA-Record oder keinen AAAA-Record.

Port 80 und Port 443 müssen in ufw und in der Netzwerk-Firewall Ihres Providers geöffnet sein. Bei den meisten Hosting-Panels gibt es eine zweite Firewall, die das Betriebssystem nicht sieht. HTTP-01 wird ausdrücklich über Port 80 validiert. Sie können dies nicht ausschließlich über Port 443 ausführen.

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 wurde vor Jahren aus gutem Grund auf die Snap-Distribution umgestellt: Die Pakete der Distribution veralteten. Ubuntu 20.04 wurde mit Certbot 0.40 ausgeliefert und erhielt keine neuere Version, und das Projekt hatte genug davon, Fehler in fünf Jahre alten Versionen zu untersuchen. Unter 24.04 ist dieser Grund entfallen. Das Archiv liefert Certbot 2.9.0, eine aktuelle Version, und unattended-upgrades hält es mit Patches aktuell. Meine Empfehlung für dieses Betriebssystem: Verwenden Sie apt. Sie benötigen keinen snapd-Daemon, das Apache-Plugin wird in derselben Transaktion installiert, und der Timer für die Erneuerung wird auf die übliche Debian-Weise in systemd integriert.

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

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

Der Snap ist weiterhin in zwei Fällen die richtige Wahl: Sie möchten die neueste Certbot-Version am Tag ihrer Veröffentlichung verwenden oder 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 der certbot, den Ihre Shell in PATH findet, möglicherweise nicht die Installation, der Ihre Zertifikate gehören. Die oben stehende 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 Angaben abgefragt: eine E-Mail-Adresse (für Ihr ACME-Konto und dringende Hinweise der Zertifizierungsstelle; Let’s Encrypt versendet keine Ablaufwarnungen mehr, daher müssen Sie die Erneuerungen selbst überwachen), die Zustimmung zu den Nutzungsbedingungen von Let’s Encrypt und die Frage, ob Ihre E-Mail-Adresse an die EFF weitergegeben werden darf. Eine Frage zur Weiterleitung gibt es nicht mehr: Seit Certbot 2.0 leitet das Apache-Installationsprogramm HTTP standardmäßig auf HTTPS um. Das ist in diesem Fall gewünscht. Verwenden Sie --no-redirect nur, wenn Inhalte tatsächlich weiterhin über unverschlüsseltes HTTP bereitgestellt werden müssen.

Der Erfolg 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 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

Hinter dieser Meldung hat Certbot vier Schritte ausgeführt: Es hat das Apache-Modul ssl aktiviert, falls es noch nicht aktiviert war, die Datei example.com-le-ssl.conf geschrieben, eine Kopie Ihres virtuellen Hosts unter *:443 mit SSLEngine on und den Zertifikatspfaden angelegt, diese aktiviert und einen RewriteRule-Block zum ursprünglichen Port-80-VirtualHost hinzugefügt, der alle Anfragen mit dem Statuscode 301 auf HTTPS umleitet. Ihre ursprüngliche VirtualHost-Datei wurde bearbeitet und 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 konstruktionsbedingt 90 Tage gültig. Das bereits installierte apt-Paket hat die erforderliche Infrastruktur eingerichtet: einen systemd-Timer, der Certbot zweimal täglich zu zufällig gewählten Zeitpunkten ausführt und jedes Zertifikat erneuert, dessen Ablauf innerhalb von 30 Tagen bevorsteht. Richten Sie keinen zusätzlichen cron-Job ein. Ein zweiter Scheduler erzeugt nur zusätzliche Logeinträge und ein weiteres Risiko für Rate-Limits.

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

Der erste Befehl zeigt, dass der Timer aktiv ist. Unter NEXT steht ein 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 Probelauf simuliert eine vollständige Erneuerung über die Staging-Umgebung von Let's Encrypt. Dabei wird die echte Challenge ausgeführt, aber kein Zertifikat ausgestellt und kein Rate-Limit verbraucht. Bei einem korrekten Ergebnis endet die Ausgabe mit:

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

Wenn der Probelauf fehlschlägt, wird auch die echte Erneuerung in etwa 60 Tagen auf dieselbe Weise fehlschlagen. Beheben Sie das Problem jetzt, solange das aktuelle Zertifikat noch seine gesamte Laufzeit vor sich hat. Die häufigste Ursache ist eine Firewall-Regel, die nach der Ausstellung des Zertifikats 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. Das ist die Weiterleitung, die Certbot eingerichtet hat. Der zweite sollte HTTP/1.1 200 OK ohne TLS-Fehler von curl zurückgeben. Der dritte gibt den Aussteller, eine O = Let's Encrypt-Zeile mit einem kurzen CN wie R12 oder E7 sowie notAfter mit einem Ablaufdatum in ungefähr 90 Tagen aus. Im Browser wird das Vorhängeschloss angezeigt. Wenn Sie darauf klicken, sehen Sie denselben Aussteller. Wenn curl funktioniert, der Browser aber eine Warnung anzeigt, sehen Sie fast sicher eine zwischengespeicherte Seite oder verwenden den falschen Hostnamen. Es handelt sich dann nicht um ein 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 mit den 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 bricht ab, wenn Apache selbst einen Fehler meldet. Die \ns sind wörtlich gemeint, weil Certbot die repr-Darstellung der Exception ausgibt. Führen Sie sudo apache2ctl configtest selbst aus. Der Befehl nennt Datei und Zeile. Typische Ursachen sind ein Tippfehler nach manueller Bearbeitung, ein SSLCertificateFile, das auf einen nicht mehr vorhandenen Pfad verweist, oder ein referenziertes, aber nicht aktiviertes Modul. Beheben Sie die Fehler, bis der Befehl Syntax OK ausgibt, und führen Sie Certbot anschließend erneut aus.

Kein vhost passt zur 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. Er wird beim Ausstellen erkannt. Certbot hat jeden aktivierten vhost für Port 80 nach einem ServerName/ServerAlias durchsucht, das zu Ihrem -d passt, und nichts gefunden. sudo apache2ctl -S zeigt, wie Apache den Datenverkehr 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 tritt auf, wenn die Validierung den falschen vhost erreicht. Die Challenge-Antwort lautet dann Invalid response ... 404, weil eine andere Site die Anfrage übernommen hat. Die Diagnose und das Werkzeug sind identisch: 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 angekündigten Adresse keine TCP-Verbindung zu Port 80 öffnen. Wahrscheinliche Ursachen sind, in dieser Reihenfolge: die Netzwerk-Firewall Ihres Providers, die von ufw getrennt ist und im Hosting-Panel konfiguriert wird; ein ufw-Regelwerk, das nur 443 oder nur SSH erlaubt; ein DNS-Eintrag, der noch auf einen vorherigen Server zeigt; oder das veraltete-AAAA-Problem. Dabei versuchen die Server von Let’s Encrypt, IPv6 zu verwenden, während Ihr Server nur auf IPv4 antwortet. Testen Sie von außerhalb des VPS: curl -I http://example.com von Ihrem Laptop reproduziert, was der Validierungsserver sieht.

Sie haben sich durch wiederholte Versuche in ein Rate Limit gebracht.

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 und Account innerhalb einer Stunde. Seit der Überarbeitung der Rate Limits im Jahr 2025 handelt es sich um ein sich wieder auffüllendes Kontingent. Dadurch erhalten Sie ungefähr alle 12 Minuten einen weiteren Versuch. Wiederholte Versuche gegen eine fehlerhafte Firewall verbrauchen das 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ügige eigene Limits und stellt keine echten Zertifikate aus, sodass Sie dort den ganzen Nachmittag Fehler beheben können. Führen Sie den produktiven 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 Script Zertifikate in einer Schleife erneut ausstellt.

Sobald HTTPS funktioniert, denken Sie daran, dass das Zertifikat den Transport schützt, nicht den Server. Auf Port 22 werden weiterhin den ganzen Tag Passwortversuche durchgeführt. Die Kombination mit Fail2ban auf Ubuntu 24.04 ist daher der naheliegende nächste Schritt für die nächsten 30 Minuten.

FAQ

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

Verwenden Sie apt. Ubuntu 24.04 liefert Certbot 2.9.0 aus. Diese Version ist für alle Inhalte dieses Leitfadens aktuell genug, erhält Sicherheitsaktualisierungen ü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 ausschließlich als snap verfügbar ist. Wenn Sie wechseln, deaktivieren Sie zuerst apt remove certbot python3-certbot-apache, damit nie zwei Erneuerungszeitpläne gleichzeitig aktiv sind.

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

Weil kein aktivierter Port-80-VirtualHost über ServerName oder ServerAlias verfügt, der mit der über -d übergebenen Domain übereinstimmt. Im standardmäßigen VirtualHost von Ubuntu ist ServerName auskommentiert. Führen Sie sudo apache2ctl -S aus, ermitteln oder erstellen Sie den VirtualHost, der für den Namen zuständig sein soll, ergänzen Sie ServerName example.com, 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 von Ihrem DNS veröffentlichten Adresse nicht erreichen. Prüfen Sie sowohl die netzwerkseitige Firewall im Verwaltungsbereich Ihres Providers als auch ufw. Stellen Sie sicher, dass dig +short example.com auf diesen VPS verweist, und löschen oder korrigieren Sie veraltete AAAA-Einträge. Bei vorhandenen IPv6-Einträgen bevorzugt die Validierung IPv6. Prüfen Sie die Korrektur von außerhalb des Servers mit curl -I http://example.com. Führen Sie anschließend vor der tatsächlichen Ausstellung einen Test mit sudo certbot certonly --apache --dry-run -d example.com durch.

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 jedes Zertifikat erneuert, dessen Ablauf innerhalb der nächsten 30 Tage liegt. Anschließend lädt er Apache neu. Für dieselbe Aufgabe verwendet snap snap.certbot.renew.timer. Prüfen Sie dies mit systemctl list-timers certbot.timer und führen Sie einen Test mit sudo certbot renew --dry-run durch. Richten Sie keinen eigenen Cronjob zusätzlich ein.

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 expliziter Auflistung dieser Subdomains einfacher. Außerdem bleiben die DNS-API-Schlüssel dadurch vom Server fern.