Wildcard-SSL-Zertifikate mit Certbot und Let’s Encrypt erstellen und erneuern

Für die Ausstellung eines Wildcard-Zertifikats für Namen wie *.example.com mit Certbot und Let’s Encrypt ist immer die ACME-DNS-01-Challenge erforderlich. Die HTTP-01-Challenge kann hierfür nicht verwendet werden. Die Kontrolle über die Domain wird nachgewiesen, indem TXT-Einträge unter _acme-challenge veröffentlicht werden, anstatt Validierungsdateien über HTTP auf einem einzelnen Server bereitzustellen. Let’s Encrypt unterstützt Wildcard-Zertifikate seit der Einführung von ACMEv2 im März 2018. An dieser Voraussetzung hat sich seitdem nichts geändert.

Was Sie in diesem Tutorial lernen

In diesem Tutorial erfahren Sie, wie Sie:

• überprüfen, ob Wildcard-DNS wie erwartet aufgelöst wird.
• Certbot zusammen mit dem passenden DNS-Plugin Ihres DNS-Anbieters installieren oder alternativ eine manuelle DNS-Challenge verwenden, falls kein API-Zugriff verfügbar ist.
• API-Zugangsdaten bei einer automatisierten DNS-Konfiguration sicher speichern.
• certbot certonly mit den passenden Optionen ausführen, einschließlich Konfigurationen für Apex-Domain und Wildcard in einem Zertifikat, mehrere Apex-Domains innerhalb eines Zertifikats sowie mehrstufige Subdomain-Strukturen. Außerdem prüfen Sie die erzeugten PEM-Dateien und richten unbeaufsichtigte certbot renew-Vorgänge mit Deployment-Hooks ein, die den Webserver automatisch neu laden.
• Nginx oder Apache so konfigurieren, dass TLS-Verbindungen mit den ausgestellten Zertifikatsdateien verarbeitet werden.

Die beschriebenen Schritte eignen sich für gängige Linux-Distributionen. Da sich Paketnamen unterscheiden können, sollten Sie während der Einrichtung zusätzlich die Dokumentation Ihrer Distribution und Ihres DNS-Anbieters bereithalten.

Die wichtigsten Punkte im Überblick

• Ein Zertifikat für *.example.com deckt genau eine Ebene unterhalb der Apex-Domain ab, beispielsweise api.example.com. Die Domain example.com selbst ist nur enthalten, wenn sie zusätzlich angegeben wird. Auch dev.api.example.com wird durch dieses Wildcard-Zertifikat nicht abgedeckt.
• Wildcard-Zertifikate benötigen immer eine DNS-Validierung. HTTP-01 kann weiterhin für einzelne Hostnamen verwendet werden, für die Ausstellung eines Wildcard-Zertifikats verlangt die Zertifizierungsstelle jedoch einen DNS-basierten Nachweis.
• Eine automatische Verlängerung von Wildcard-Zertifikaten setzt ein kompatibles DNS-Plugin oder eine andere automatisierte Möglichkeit zur Änderung von DNS-Einträgen voraus. Eine manuelle TXT-Validierung funktioniert zwar für die Ausstellung, muss jedoch bei jeder Verlängerung erneut durchgeführt werden, sofern DNS-Änderungen nicht automatisiert sind.
• Produktivsysteme sollten die Zertifikatserneuerung über systemd-Timer oder Cron automatisieren, da Zertifikate von Let’s Encrypt 90 Tage gültig sind.
• Staging-Anfragen eignen sich zum Testen von DNS-Konfigurationen oder zum Beheben von Rate-Limit-Problemen, ohne Produktionslimits zu verbrauchen. Verwenden Sie während der Tests --staging und entfernen Sie diese Option anschließend für ein vertrauenswürdiges Produktivzertifikat.

Warum Wildcard-Zertifikate eine DNS-01-Validierung benötigen

HTTP-01 weist die Kontrolle über einen bestimmten Hostnamen nach, indem über diesen Host ein Token bereitgestellt wird. Ein Wildcard-Muster steht dagegen für zahlreiche mögliche zukünftige Hostnamen, darunter auch Namen, die noch gar nicht auf einen Server zeigen. Die Validierung eines einzelnen HTTP-Endpunkts kann deshalb keine Kontrolle über den gesamten DNS-Namensraum nachweisen. Bei DNS-01 wird stattdessen ein TXT-Eintrag unter _acme-challenge beim autoritativen DNS-Dienst der Zone angelegt. Dadurch eignet sich dieses Verfahren für die Validierung von Wildcard-Domains.

Manuelle DNS-Validierung im Vergleich zu einem automatisierten Certbot-DNS-Plugin

Voraussetzungen

Folgende Voraussetzungen sollten erfüllt sein:

• Sie verfügen über eine Domain, deren DNS-Einträge Sie für die Ausstellung und Verlängerung von Zertifikaten bearbeiten können. Prüfen Sie im Certbot-DNS-Plugin-Verzeichnis, ob Ihr DNS-Anbieter unterstützt wird.
• Sie verfügen über ein Linux-System mit sudo-Zugriff.

Verwenden Sie möglichst die aktuellste Certbot-Version, die über Ihre Linux-Distribution oder Snap verfügbar ist. Der genaue Installationsweg hängt vom verwendeten System ab.

• Für paketbasierte Installationen können Sie einer passenden Certbot-Standalone-Anleitung für Ihre Linux-Distribution folgen.
• Bei neueren Ubuntu-Versionen sollten Sie die Installationsmethode verwenden, die für Ihre jeweilige Version empfohlen wird.
• Das Certbot-Projekt stellt außerdem Installationsanweisungen für Snap bereit. Unter Ubuntu ist Snap die bevorzugte Installationsmethode. DNS-Plugins werden dabei separat installiert und anschließend mit dem Certbot-Snap verbunden.
• Weitere Hintergrundinformationen zu den von Let’s Encrypt ausgestellten Zertifikaten finden Sie in einer allgemeinen Einführung zu Let’s Encrypt.

Wenn Sie bereits Nginx oder Apache betreiben, aber noch keine automatisierte Wildcard-Zertifikatsverwaltung eingerichtet haben, können Sie zusätzlich eine Certbot-HTTPS-Anleitung für den verwendeten Webserver heranziehen.

Schritt 1: Wildcard-DNS konfigurieren

Richten Sie *.example.com auf den Server oder Load Balancer aus, der HTTPS-Anfragen entgegennehmen soll. Ein typischer DNS-Eintrag kann beispielsweise so aussehen:

*.example.com. 3600 IN A 203.0.113.1

Das Zeichen * steht dabei für genau eine Ebene ganz links im Hostnamen. *.example.com gilt beispielsweise für app.example.com, jedoch nicht für example.com oder dev.app.example.com.

Wenn Sie diesen DNS-Eintrag erstmals einrichten, können Sie die TTL vorübergehend von beispielsweise 3600 Sekunden auf einen niedrigeren Wert wie 300 reduzieren. Eine kürzere TTL sorgt dafür, dass DNS-Resolver zwischengespeicherte Antworten schneller verwerfen und Korrekturen dadurch früher sichtbar werden. Sobald der Eintrag stabil funktioniert und Let’s Encrypt die Validierung erfolgreich abgeschlossen hat, kann die TTL wieder erhöht werden, um die Anzahl der DNS-Abfragen zu reduzieren.

Weitere Details finden Sie in der Dokumentation zur DNS-Verwaltung Ihres DNS-Anbieters.

Prüfen Sie die DNS-Weitergabe mit dig oder host:

dig +short A app.example.com

host app.example.com

Bevor Sie fortfahren, sollte eine A- oder CNAME-Antwort zurückgegeben werden.

Schritt 2: Das passende Certbot-DNS-Plugin installieren

Certbot bietet drei verbreitete Möglichkeiten für eine DNS-Validierung: eine vollständig manuelle Validierung ohne API, ein über den Paketmanager des Betriebssystems installiertes DNS-Plugin oder ein über Snap installiertes DNS-Plugin. Welche Variante geeignet ist, hängt davon ab, wie Certbot auf Ihrem System installiert wurde und ob Ihr DNS-Anbieter einen API-Zugriff zur Verfügung stellt.

Option A: Manuelle DNS-Validierung

Verwenden Sie den manuellen Modus, wenn Ihr DNS-Anbieter keinen geeigneten API-Zugriff anbietet oder Sie das Zertifikat nur einmal ausstellen möchten:

sudo certbot certonly –manual –preferred-challenges dns \

-d ‚*.example.com‘ -d ‚example.com‘

Certbot zeigt anschließend die TXT-Werte an, die Sie erstellen müssen. Hinterlegen Sie diese bei Ihrem DNS-Anbieter, warten Sie auf die DNS-Weitergabe und setzen Sie anschließend den Vorgang im Terminal fort. Dieser interaktive Schritt wird bei jeder Verlängerung erneut benötigt. Ein unbeaufsichtigter certbot renew-Vorgang über Cron oder einen systemd-Timer würde daher irgendwann auf eine Eingabe warten und fehlschlagen. Möglichkeiten zur automatisierten Verlängerung werden in Schritt 7 behandelt.

Option B: Automatisierte DNS-Validierung über den Paketmanager

Installieren Sie das für Ihren DNS-Anbieter vorgesehene Certbot-DNS-Plugin über Ihre Linux-Distribution. Der genaue Paketname ist vom DNS-Dienst und von der Distribution abhängig.

sudo apt install python3-certbot-dns-provider

Unter Fedora oder RHEL 8 und neuer verwenden Sie dnf mit dem entsprechenden Paket:

sudo dnf install python3-certbot-dns-provider

Lassen Sie sich anschließend die verfügbaren Certbot-Plugins anzeigen, um zu prüfen, ob das DNS-Plugin registriert wurde:

certbot plugins

Das Plugin Ihres DNS-Anbieters sollte gemeinsam mit Plugins wie standalone und webroot erscheinen.

Option C: Automatisierte DNS-Validierung über Snap

Unter Ubuntu 22.04 und neueren Versionen wird Certbot häufig als Snap bereitgestellt. Die Paketmanager-Version eines bestimmten DNS-Plugins ist möglicherweise nicht verfügbar oder älter. Installieren Sie deshalb zunächst den Certbot-Snap, falls dies noch nicht erfolgt ist:

sudo snap install –classic certbot

Erlauben Sie Certbot anschließend die Nutzung von Plugins, die erhöhte Berechtigungen benötigen:

sudo snap set certbot trust-plugin-with-root=ok

Installieren Sie danach das Snap-Paket des DNS-Plugins Ihres Anbieters:

sudo snap install certbot-dns-provider

Verbinden Sie das DNS-Plugin mit Certbot:

sudo snap connect certbot:plugin certbot-dns-provider

Überprüfen Sie anschließend, ob Certbot das Plugin erkennt:

certbot plugins

Das DNS-Anbieter-Plugin sollte nun in der Liste erscheinen. Anschließend können Sie mit der Konfiguration der Zugangsdaten in Schritt 3 fortfahren.

Für eine gezieltere Einrichtung können Sie eine DNS-Validierungsanleitung verwenden, die zu Ihrem Betriebssystem und Ihrer Certbot-Installationsmethode passt.

Schritt 3: Das Certbot-DNS-Plugin konfigurieren

Erstellen Sie eine Zugangsdaten-Datei, die ausschließlich vom erforderlichen Systemkonto gelesen werden kann. Ein geeigneter Speicherort für Produktivsysteme ist /etc/letsencrypt/certbot-creds.ini. Dadurch befinden sich die Zugangsdaten gemeinsam mit den übrigen Certbot-Daten. Alternativ kann die Datei auch im passenden Benutzerverzeichnis gespeichert werden.

sudo nano /etc/letsencrypt/certbot-creds.ini

Der genaue Schlüssel für die Zugangsdaten hängt von Ihrem DNS-Anbieter ab. Ein Provider-Plugin kann beispielsweise eine Konfiguration in folgender Form verwenden:

/etc/letsencrypt/certbot-creds.ini

dns_provider_token = paste_your_write_scoped_token_here

Erstellen Sie ein API-Token, das lediglich zur Änderung von DNS-Einträgen berechtigt ist, anstatt unnötigen vollständigen Kontozugriff zu gewähren. Wird das Token ausschließlich mit DNS-Schreibrechten ausgestattet, bleiben die möglichen Auswirkungen einer Offenlegung begrenzt. Speichern Sie anschließend die Datei und beschränken Sie die Berechtigungen so, dass nur root sie lesen kann:

sudo chmod 600 /etc/letsencrypt/certbot-creds.ini

Restriktive Dateiberechtigungen verhindern außerdem Sicherheitswarnungen von Certbot wegen einer unzureichend geschützten Zugangsdaten-Datei.

Schritt 4: Das Wildcard-Zertifikat abrufen

Verwenden Sie für die Ausstellung von Wildcard-Zertifikaten certbot certonly. Installer-Modi wie --nginx und --apache richten Wildcard-Virtual-Hosts nicht automatisch ein. Deshalb ist certonly hier der vorgesehene Weg. Die folgenden Abschnitte behandeln die automatisierte Ausstellung über ein DNS-Plugin, Staging-Tests, die erzeugten Dateien, mehrere Apex-Domains und mehrstufige Subdomains.

Automatisierte Zertifikatsanforderung mit einem DNS-Anbieter-Plugin

Wenn sowohl die Apex-Domain als auch die Wildcard-Domain HTTPS-Verkehr verarbeiten sollen, können Sie beide Namen gemeinsam in einer einzigen Anfrage angeben:

sudo certbot certonly \

–dns-provider \

–dns-provider-credentials /etc/letsencrypt/certbot-creds.ini \

–dns-provider-propagation-seconds 60 \

-d ‚example.com‘ \

-d ‚*.example.com‘

Die Option für die DNS-Propagation legt fest, wie lange Certbot nach dem Erstellen des _acme-challenge-TXT-Eintrags wartet, bevor die Validierung beginnt. Standardwert und empfohlene Wartezeit unterscheiden sich je nach DNS-Plugin und Anbieter. DNS-Änderungen können 30 bis 60 Sekunden oder länger benötigen. Ein Wert von 60 Sekunden ist häufig ein sinnvoller Ausgangspunkt. Wenn die Validierung fehlschlägt, können 120 Sekunden oder mehr erforderlich sein. Andere DNS-Plugins stellen vergleichbare Optionen bereit, deren Namen und geeignete Werte jedoch abweichen können.

Die Installer --nginx und --apache konfigurieren Wildcard-Virtual-Hosts nicht automatisch. Daher bleibt certonly für Wildcard-Zertifikate die geeignete Methode.

Mit der Let’s-Encrypt-Staging-Umgebung testen

Verwenden Sie --staging, wenn Sie Ihre DNS-Konfiguration oder Deployment-Hooks testen. Zertifikate aus der Staging-Umgebung werden von Browsern nicht als vertrauenswürdig eingestuft, verbrauchen dafür aber keine Produktionslimits. Entfernen Sie --staging erst, wenn der vollständige Test erfolgreich abgeschlossen wurde.

Erwartete Zertifikatsdateien

Nach einer erfolgreichen Ausstellung speichert Certbot die PEM-Dateien unter /etc/letsencrypt/live/example.com/. Der Verzeichnisname entspricht normalerweise der ersten Domain, die mit -d angegeben wurde:

• fullchain.pem
• privkey.pem
• chain.pem
• cert.pem

Mehrere Domains und mehrstufige Wildcard-Abdeckung

Ein einzelner certbot certonly-Befehl kann mehrere Subject Alternative Names enthalten, indem mehrere -d-Optionen angegeben werden. Die aktuellen SAN-bezogenen Beschränkungen finden Sie in der offiziellen Dokumentation zu den Rate Limits von Let’s Encrypt. Die folgenden Konfigurationen werden häufig verwendet.

Apex-Domain und Wildcard in einem Zertifikat

Dies ist die häufigste Konfiguration und wurde bereits im automatisierten Beispiel gezeigt. Ohne die Apex-Domain deckt das Wildcard-Zertifikat example.com nicht ab. *.example.com gilt beispielsweise für api.example.com, jedoch nicht für die reine Domain example.com.

Mehrere Apex-Domains in einem Zertifikat

Wenn Sie mehrere Domains verwalten, können Sie diese in einem gemeinsamen Zertifikat zusammenfassen. Dadurch reduziert sich die Anzahl der Verlängerungskonfigurationen, die überwacht werden müssen:

sudo certbot certonly \

–dns-provider \

–dns-provider-credentials /etc/letsencrypt/certbot-creds.ini \

–dns-provider-propagation-seconds 60 \

-d ‚example.com‘ -d ‚*.example.com‘ \

-d ‚example.net‘ -d ‚*.example.net‘

Jede Domain benötigt einen eigenen Wildcard-TXT-Eintrag zur Validierung. Certbot führt deshalb für jede Domain die notwendigen DNS-API-Operationen durch. Alle Validierungseinträge müssen verfügbar sein, bevor Let’s Encrypt den Vorgang fortsetzt.

Mehrstufige Subdomains

Die ACME-Spezifikation RFC 8555 begrenzt ein Wildcard-Zertifikat auf eine einzelne Hostnamenebene. *.example.com deckt deshalb v2.api.example.com nicht ab. Für diesen Subdomain-Zweig muss ein separates Wildcard-Muster angefordert werden:

sudo certbot certonly \

–dns-provider \

–dns-provider-credentials /etc/letsencrypt/certbot-creds.ini \

–dns-provider-propagation-seconds 60 \

-d ‚api.example.com‘ \

-d ‚*.api.example.com‘

Dieses Zertifikat deckt api.example.com sowie eine Ebene darunter ab, beispielsweise v1.api.example.com und v2.api.example.com. Es gilt jedoch nicht für example.com oder *.example.com.

Schritt 5: Das Wildcard-Zertifikat überprüfen

Mit OpenSSL können Sie das ausgestellte Zertifikat kontrollieren. Prüfen Sie die SAN-Einträge, damit alle angeforderten Namen tatsächlich enthalten sind:

sudo openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem \

-noout -text | grep -A1 „Subject Alternative Name“

Die Ausgabe sollte DNS:*.example.com sowie alle weiteren mit -d angeforderten Namen enthalten. Ein Zertifikat, das mit -d 'example.com' -d '*.example.com' angefordert wurde, sollte beide Einträge anzeigen.

Prüfen Sie ebenfalls die Gültigkeitsdaten und stellen Sie sicher, dass das Ablaufdatum ungefähr 90 Tage nach der Ausstellung liegt:

sudo openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem \

-noout -dates

Die Ausgabe enthält die Zeitstempel notBefore und notAfter. Liegt notAfter weniger als 30 Tage in der Zukunft, prüfen Sie möglicherweise noch ein älteres Zertifikat anstelle des neu ausgestellten.

Die vier PEM-Dateien unter /etc/letsencrypt/live/example.com/ erfüllen unterschiedliche Aufgaben:

Schritt 6: Nginx oder Apache mit den Zertifikatsdateien konfigurieren

certbot certonly erstellt das Zertifikat, verändert die Webserver-Konfiguration jedoch nicht. Die Zertifikatspfade und TLS-Einstellungen müssen deshalb selbst in den jeweiligen Virtual Hosts oder Server-Blöcken ergänzt werden.

Nginx für ein Wildcard-Zertifikat konfigurieren

Im folgenden Nginx-Server-Block werden sowohl das Wildcard-Muster als auch die Apex-Domain in server_name angegeben, damit Nginx beide Varianten verarbeitet:

server {

listen 443 ssl;

listen [::]:443 ssl;

server_name example.com *.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# Aktuelle TLS-Einstellungen aus dem Mozilla SSL Configuration Generator einfügen

ssl_session_cache shared:SSL:10m;

ssl_session_timeout 1d;
# Hier folgen die Direktiven Ihrer Anwendung

root /var/www/html;

index index.html;

}
# HTTP auf HTTPS umleiten

server {

listen 80;

listen [::]:80;

server_name example.com *.example.com;

return 301 https://$host$request_uri;

}

Verwenden Sie für TLS-Protokolle und Cipher-Einstellungen den Mozilla SSL Configuration Generator und wählen Sie Nginx sowie das Intermediate-Profil. Der Generator erstellt aktuelle ssl_protocols– und ssl_ciphers-Direktiven passend zu den ausgewählten Nginx- und OpenSSL-Versionen. Dies ist zuverlässiger als eine fest eingetragene Cipher-Konfiguration, die mit der Zeit veralten kann.

Die Direktive ssl_session_cache shared:SSL:10m stellt den Nginx-Workern einen gemeinsamen TLS-Session-Cache mit 10 MB zur Verfügung. Dieser kann ungefähr 40.000 Sitzungen aufnehmen und ermöglicht schnellere wiederaufgenommene TLS-Handshakes. ssl_session_timeout 1d sorgt dafür, dass zwischengespeicherte Sitzungen einen Tag lang gültig bleiben.

fullchain.pem enthält sowohl das Serverzertifikat als auch das Intermediate-CA-Zertifikat. Verwenden Sie deshalb für ssl_certificate die Datei fullchain.pem und nicht cert.pem. Andernfalls können Clients mit älteren Trust Stores die Zertifikatskette möglicherweise ablehnen.

Testen Sie die Nginx-Konfiguration und laden Sie den Dienst nach Änderungen neu:

sudo nginx -t && sudo systemctl reload nginx

Apache für ein Wildcard-Zertifikat konfigurieren

Die entsprechende Apache-VirtualHost-Konfiguration nutzt ServerAlias mit dem Wildcard-Muster, um zusätzlich zur Apex-Domain auch deren Subdomains abzudecken:

<VirtualHost *:443>

ServerName example.com

ServerAlias *.example.com

SSLEngine on

SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem

SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

# TLS-Einstellungen aus https://ssl-config.mozilla.org (Apache, Intermediate) einfügen

DocumentRoot /var/www/html

</VirtualHost>

# HTTP auf HTTPS umleiten

<VirtualHost *:80>

ServerName example.com

ServerAlias *.example.com

RewriteEngine On

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

</VirtualHost>

Verwenden Sie den Mozilla SSL Configuration Generator mit Apache und dem Intermediate-Profil, um aktuelle SSLProtocol– und SSLCipherSuite-Direktiven passend zu Ihren Apache- und OpenSSL-Versionen zu erhalten. Fügen Sie diese anschließend in die Konfiguration ein.

SSLCertificateFile sollte auf fullchain.pem verweisen, da diese Datei sowohl das Serverzertifikat als auch das Intermediate-CA-Zertifikat enthält. Für Apache 2.4.8 und neuer ist dies die vorgesehene Konfiguration. Die ältere Direktive SSLCertificateChainFile wurde ab Apache 2.4.8 überflüssig, weil SSLCertificateFile seitdem die vollständige Zertifikatskette enthalten kann. Verwenden Sie bei Apache 2.4.8 oder neuer deshalb ausschließlich SSLCertificateFile mit fullchain.pem und entfernen Sie eventuell vorhandene SSLCertificateChainFile-Einträge.

Die gezeigte HTTP-Weiterleitung benötigt mod_rewrite. Aktivieren Sie die erforderlichen Module, sofern sie noch nicht aktiv sind:

sudo a2enmod rewrite ssl headers

Testen Sie anschließend die Apache-Konfiguration und laden Sie den Dienst neu:

sudo apachectl configtest && sudo systemctl reload apache2

Auf RHEL-basierten Systemen können die entsprechenden Befehle abweichen. Dort wird der Apache-Dienst häufig als httpd bezeichnet.

Schritt 7: Die Verlängerung von Wildcard-Zertifikaten automatisieren

Dieser Schritt beschreibt eine vollständig automatisierte Zertifikatserneuerung ohne wiederkehrende manuelle Arbeit. Sie erfahren, warum der manuelle Validierungsmodus für unbeaufsichtigte Verlängerungen vermieden werden sollte, wie sich das konfigurierte DNS-Plugin prüfen lässt, wie Sie den Verlängerungszeitplan kontrollieren und wie ein Webserver nach einer erfolgreichen Verlängerung automatisch neu geladen werden kann.

Warum Zertifikate aus dem manuellen Modus nicht unbeaufsichtigt verlängert werden können

Wenn ein Zertifikat mit --manual erstellt wird, speichert Certbot diese Methode in /etc/letsencrypt/renewal/example.com.conf:

[renewalparams]

authenticator = manual

Bei jedem Verlängerungsversuch wartet Certbot dann darauf, dass ein Benutzer den TXT-Eintrag manuell aktualisiert. Wird der Befehl über Cron oder einen systemd-Timer ausgeführt, wartet der Prozess schließlich auf eine Eingabe und die Verlängerung schlägt fehl.

Wird das Zertifikat stattdessen über ein DNS-Anbieter-Plugin erstellt, enthält die Verlängerungskonfiguration den Plugin-Authentifikator und den Pfad zur Zugangsdaten-Datei:

[renewalparams]

authenticator = dns-provider

dns_provider_credentials = /etc/letsencrypt/certbot-creds.ini

Mit diesen Einstellungen kann certbot renew die DNS-01-Validierung ohne menschlichen Eingriff durchführen.

Die Verlängerungskonfiguration prüfen

Kontrollieren Sie die Renewal-Konfiguration und stellen Sie sicher, dass der Authentifikator auf Ihr DNS-Plugin verweist, bevor Sie sich auf eine unbeaufsichtigte Verlängerung verlassen:

sudo cat /etc/letsencrypt/renewal/example.com.conf

Unter [renewalparams] sollte der Authentifikator Ihres DNS-Anbieters eingetragen sein. Falls dort aufgrund einer früheren Ausstellung weiterhin authenticator = manual steht, stellen Sie das Zertifikat erneut über das DNS-Plugin aus, wie in Schritt 4 beschrieben. Certbot aktualisiert anschließend die Verlängerungskonfiguration.

Den Certbot-systemd-Timer überprüfen

Unter Ubuntu und Debian richtet Certbot üblicherweise einen systemd-Timer ein, der zweimal täglich prüft, ob Zertifikate verlängert werden müssen. Der genaue Unit-Name hängt von der Installationsmethode ab:

• systemctl status certbot.timer
• snap.certbot.renew.timer

systemctl status certbot.timer

Ist kein Timer vorhanden, beispielsweise weil Certbot über pip und nicht über apt oder snap installiert wurde, können Sie stattdessen einen entsprechenden Cronjob anlegen:

0 */12 * * * root certbot renew –quiet

Speichern Sie diesen Eintrag in /etc/cron.d/certbot. Wenn Sie ihn stattdessen über sudo crontab -e hinzufügen, darf das Feld root nicht enthalten sein, da die Benutzerspalte nur bei Dateien unter /etc/cron.d/ verwendet wird.

Der Eintrag kann entweder in /etc/cron.d/certbot hinterlegt oder mit crontab -e für den root-Benutzer eingerichtet werden.

Den Verlängerungsprozess testen

Führen Sie immer einen Testlauf durch, bevor Sie sich auf die automatische Verlängerung verlassen:

sudo certbot renew –dry-run

Ein Dry Run simuliert den vollständigen ACME-Ablauf einschließlich der DNS-01-Challenge gegen die Staging-Umgebung von Let’s Encrypt und nicht gegen die Produktions-Zertifizierungsstelle. Wenn der Test fehlschlägt, sollte das Problem behoben werden, bevor das tatsächliche Zertifikat kurz vor dem Ablauf steht. Häufige Ursachen sind ein falscher Pfad zur Zugangsdaten-Datei oder ein API-Token mit unzureichenden DNS-Berechtigungen.

Der Dry Run bildet den vollständigen ACME-Austausch einschließlich DNS-01-Validierung nach, ohne die produktiven Zertifikatsdateien zu ersetzen oder die produktive Zertifizierungsstelle zu kontaktieren. Schlägt der Test fehl, beheben Sie die Ursache, die häufig in einem falschen Pfad zur Zugangsdaten-Datei oder unzureichenden DNS-API-Berechtigungen liegt, bevor das aktive Zertifikat abläuft.

Dienste nach einer erfolgreichen Verlängerung neu laden

Certbot kann unmittelbar nach einer erfolgreichen Zertifikatserneuerung einen beliebigen Befehl ausführen. Dafür stehen zwei Möglichkeiten zur Verfügung.

Bei der Ausstellung des Zertifikats können Sie --deploy-hook zusammen mit certbot certonly verwenden:

sudo certbot certonly \

–dns-provider \

–dns-provider-credentials /etc/letsencrypt/certbot-creds.ini \

–dns-provider-propagation-seconds 60 \

-d ‚example.com‘ -d ‚*.example.com‘ \

–deploy-hook „systemctl reload nginx“

Certbot speichert den Deployment-Hook in /etc/letsencrypt/renewal/example.com.conf. Dadurch wird er nach jeder zukünftigen erfolgreichen Verlängerung automatisch ausgeführt und muss nicht erneut als Option angegeben werden.

Bei bereits vorhandenen Zertifikaten können Sie stattdessen ein ausführbares Skript im Verzeichnis für Deployment-Hooks erstellen. Certbot prüft dieses Verzeichnis nach erfolgreichen Verlängerungsvorgängen:

sudo nano /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

#!/bin/sh

systemctl reload nginx

Machen Sie das Skript anschließend ausführbar:

sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Skripte in diesem Verzeichnis gelten für alle Zertifikate, die Certbot auf dem System verwaltet. Dies ist praktisch, wenn mehrere Zertifikate denselben Webserver verwenden. Soll ein Hook nur für ein bestimmtes Zertifikat gelten, verwenden Sie bei dessen Ausstellung stattdessen gezielt --deploy-hook.

Deployment-Hooks werden ausschließlich ausgeführt, wenn tatsächlich ein Zertifikat erneuert wurde. Erkennt Certbot bei einer Prüfung, dass ein Zertifikat noch ausreichend lange gültig ist, wird der Hook nicht gestartet. Certbot überprüft regelmäßig die Ablaufdaten und erneuert Zertifikate bei Bedarf. Da Deployment-Hooks nur nach einer erfolgreichen Erneuerung ausgeführt werden, eignen sie sich besonders zum erneuten Laden von Diensten wie Nginx oder Apache.

Pre- und Post-Hooks werden dagegen vor beziehungsweise nach jedem Verlängerungsversuch ausgeführt, unabhängig davon, ob sich ein Zertifikat geändert hat. Sie können sinnvoll sein, wenn für eine Standalone-Challenge ein Webserver gestoppt werden muss, damit Port 80 verfügbar ist. Bei DNS-Plugins sind solche Hooks normalerweise nicht erforderlich und erzeugen häufig lediglich zusätzliche Logeinträge. Zum normalen Neuladen eines Webservers nach einer Erneuerung sollten Deployment-Hooks verwendet werden.

Fehlerbehebung bei Wildcard-Zertifikaten

Der TXT-Eintrag wird nicht propagiert

Diagnose

Prüfen Sie, ob der TXT-Eintrag für _acme-challenge.example.com über die autoritativen DNS-Server abgefragt werden kann:

dig TXT _acme-challenge.example.com +short

Wenn der erwartete Wert nicht angezeigt wird, wurde der DNS-Eintrag noch nicht vollständig propagiert.

Lösung

Warten Sie, bis wiederholte DNS-Abfragen zuverlässig den erwarteten TXT-Wert zurückgeben.

Wenn die automatische Validierung über das DNS-Plugin regelmäßig fehlschlägt, erhöhen Sie die anbieterspezifische Wartezeit für DNS-Propagation, beispielsweise:

–dns-provider-propagation-seconds 120

Das Zertifikat deckt den gewünschten Hostnamen nicht ab

Diagnose

Wenn ein Zertifikat Subdomains wie api.example.com abdeckt, jedoch nicht example.com, wurde wahrscheinlich ausschließlich der Wildcard-Name angefordert.

Lösung

Geben Sie bei der Ausstellung beide Namen an:

-d example.com -d ‚*.example.com‘

Ein Wildcard-Muster wie *.example.com schließt die Apex-Domain niemals automatisch ein.

Sub-Subdomains werden nicht abgedeckt

Diagnose

Wenn v2.api.example.com nicht von einem Zertifikat für *.example.com abgedeckt wird, liegt dies daran, dass Wildcards nur eine einzelne Hostnamenebene erfassen.

Lösung

Fordern Sie für die tiefere Subdomain-Ebene ein zusätzliches Wildcard-Muster an:

-d ‚api.example.com‘ -d ‚*.api.example.com‘

Authentifizierungsfehler des DNS-Plugins

Diagnose

Verlängerungsvorgänge schlagen mit Authentifizierungsfehlern des Plugins oder DNS-API-Fehlern fehl.

Lösung

• Erneuern Sie das DNS-API-Token.
• Stellen Sie sicher, dass das Token über DNS-Schreibberechtigungen verfügt.
• Prüfen Sie, ob der Pfad zur Zugangsdaten-Datei auf dem System mit dem Pfad übereinstimmt, der in der Certbot-Verlängerungskonfiguration unter /etc/letsencrypt/renewal/*.conf hinterlegt ist.

Rate-Limit-Fehler von Let’s Encrypt

Diagnose

Certbot zeigt Meldungen wie „Too many certificates“ oder andere Hinweise auf ein überschrittenes Rate Limit an.

Lösung

• Verwenden Sie während Tests und Fehlersuche vorübergehend die Staging-Umgebung mit --staging.
• Nachdem die eigentliche Ursache behoben wurde, starten Sie die Anfrage erneut ohne --staging.

Die Verlängerungskonfiguration verwendet weiterhin manuelle Authentifizierung

Diagnose

Die Certbot-Verlängerungskonfiguration ist weiterhin auf manuelle Authentifizierung eingestellt und verhindert damit eine unbeaufsichtigte Verlängerung.

Lösung

Stellen Sie das Zertifikat erneut über das DNS-Anbieter-Plugin aus, wie in Schritt 4 beschrieben. Certbot aktualisiert daraufhin die Verlängerungskonfiguration, sodass zukünftige Verlängerungen die automatisierte Validierungsmethode verwenden.

Der Webserver liefert weiterhin das alte Zertifikat aus

Diagnose

certbot renew wird erfolgreich abgeschlossen, die Website liefert jedoch weiterhin ein älteres Zertifikat aus.

Lösung

Prüfen Sie, ob ein Deployment-Hook konfiguriert wurde.

Kontrollieren Sie /etc/letsencrypt/renewal/example.com.conf auf einen Renewal- oder Deployment-Hook.

Alternativ können Sie das Verzeichnis mit den Deployment-Hooks prüfen:

ls /etc/letsencrypt/renewal-hooks/deploy/

Falls kein Hook vorhanden ist, laden Sie den Webserver manuell neu:

sudo systemctl reload nginx

Um diesen Vorgang bei zukünftigen Verlängerungen zu automatisieren, richten Sie wie in Schritt 7 beschrieben einen Deployment-Hook ein.

Wenn die erneuerten Zertifikatsdateien bereits vorhanden sind, der Server jedoch weiterhin veraltetes TLS-Material ausliefert, sollten Sie die SSL-Zertifikats- und HTTPS-Weiterleitungskonfiguration des Webservers überprüfen.

Häufig gestellte Fragen zu Certbot-Wildcard-Zertifikaten

1. Benötige ich getrennte Zertifikate für die Apex-Domain und die Wildcard-Domain?

Nein. Wenn HTTPS sowohl für example.com als auch für *.example.com verwendet wird, können beide Namen in einer einzigen Anfrage angegeben werden. Verwenden Sie dafür zwei -d-Optionen, wie in Schritt 4 gezeigt. Let’s Encrypt speichert beide Namen als separate SAN-Einträge innerhalb desselben Zertifikats, sodass eine einzige Verlängerungskonfiguration für beide ausreicht.

2. Warum lehnt Certbot die HTTP-Validierung für eine Wildcard-Anfrage ab?

Let’s Encrypt stellt Wildcard-Zertifikate ausschließlich nach erfolgreicher DNS-01-Validierung aus. HTTP-01 kann nicht nachweisen, dass Sie über jeden möglichen Hostnamen unterhalb einer Domain verfügen. Deshalb kann eine Wildcard-Anfrage nicht ausschließlich über HTTP validiert werden.

3. Wie häufig ändern sich die Dateien unter /etc/letsencrypt/live/?

Certbot aktualisiert die symbolischen Links nach jeder erfolgreichen Zertifikatserneuerung. Anwendungen sollten deshalb immer auf die Dateien innerhalb der live-Verzeichnisse verweisen und keine kopierten Zertifikatsdateien verwenden. Dadurch zeigen sie automatisch auf die erneuerten Zertifikate. Wenn eine Anwendung den Datei-Descriptor des Zertifikats bereits beim Start öffnet und den symbolischen Link später nicht erneut liest, kann trotzdem ein Reload-Hook erforderlich sein.

4. Können *.api.example.com und *.example.com im selben Zertifikat enthalten sein?

Ja. Beide Wildcard-Namen können gemeinsam in einem Zertifikat verwendet werden, indem zusätzlich -d '*.api.example.com' zusammen mit den übrigen -d-Optionen angegeben wird. Certbot führt für jedes Wildcard-Muster eine eigene DNS-01-Validierung durch. Dadurch werden getrennte _acme-challenge-TXT-Einträge unter _acme-challenge.example.com und _acme-challenge.api.example.com erstellt. Jede zusätzliche Wildcard erfordert bei einer Verlängerung außerdem eine eigene DNS-API-Operation.

Mehrere Wildcard-Namen können innerhalb eines Zertifikats zusammengefasst werden. Separate Zertifikate können die Verwaltung allerdings vereinfachen und die Auswirkungen eines kompromittierten privaten Schlüssels begrenzen.

5. Ersetzt ein Wildcard-Zertifikat Zertifikate für einzelne Hosts?

Wildcard-Zertifikate können die Anzahl der zu verwaltenden Zertifikate reduzieren. Gleichzeitig vergrößert sich jedoch der mögliche Schadensbereich, wenn der zugehörige private Schlüssel kompromittiert wird. Viele Umgebungen kombinieren deshalb beide Ansätze, beispielsweise ein Wildcard-Zertifikat auf Edge-Load-Balancern und separate Zertifikate für einzelne Dienste innerhalb eines internen Service-Netzwerks.

Fazit

Sie wissen nun, warum Wildcard-Zertifikate von Let’s Encrypt mit Certbot auf einer DNS-Validierung basieren, worin sich die manuelle Zertifikatsausstellung von einer automatisierten Validierung über DNS-Plugins unterscheidet, wie mehrere Domains und unterschiedliche Wildcard-Subdomain-Ebenen in Zertifikatsanfragen eingebunden werden können, wie Nginx oder Apache mit den ausgestellten TLS-Dateien konfiguriert werden und wie Zertifikate geprüft sowie automatisiert erneuert werden können, ohne unerwartete Dienstunterbrechungen zu verursachen.