Certbot Wildcard-Zertifikate: DNS-01 & Automatisierung meistern

Ein Wildcard-Zertifikat mit Certbot ist dann sinnvoll, wenn viele Subdomains auf dasselbe Setup zeigen und die Erneuerung ohne Handarbeit laufen soll. Das Thema certbot wildcard certificate dreht sich in der Praxis fast immer um dieselbe Frage: Wie beweise ich die Domainkontrolle per DNS-01 sauber, automatisiere die Ausstellung und vermeide typische Fehler beim Renew? Genau darauf gehe ich hier ein, mit konkreten Befehlen, den sinnvollen Varianten und den Stolperfallen, die im Alltag wirklich Zeit kosten.

Was Certbot bei Wildcard-Zertifikaten tatsächlich verlangt

Für Wildcards gilt bei Let’s Encrypt und damit auch bei Certbot eine harte Regel: Die Validierung läuft über DNS-01. Dabei legt Certbot einen TXT-Eintrag unter _acme-challenge.example.de an, und der öffentliche DNS muss diesen Wert sichtbar machen. Erst dann stellt die Zertifizierungsstelle das Zertifikat aus. Ich finde diese Logik sogar sauberer als HTTP-01, weil sie unabhängig davon funktioniert, ob der Webserver schon läuft.

Wichtig ist die Abgrenzung: *.example.de deckt nur eine Ebene ab. blog.example.de ist drin, api.blog.example.de nicht. Wenn du die Stamm-Domain example.de auch nutzen willst, musst du sie im selben Zertifikat ausdrücklich mit anfordern. Genau dieser Punkt sorgt in der Praxis am häufigsten für Verwirrung, obwohl er technisch simpel ist.

Ein weiterer Punkt, der gern vergessen wird: Let’s Encrypt-Zertifikate sind 90 Tage gültig. Der eigentliche Betriebserfolg hängt deshalb nicht an der Ausstellung, sondern daran, ob Renewal und Reload zuverlässig automatisiert sind. Damit ist die technische Grundlage klar - als Nächstes geht es um den praktischen Ablauf, von der manuellen Validierung bis zur Automatisierung.

So stelle ich ein Wildcard-Zertifikat mit Certbot aus

Der Ablauf ist immer ähnlich: Certbot fragt die Domainkontrolle über DNS ab, du setzt einen TXT-Wert, und nach erfolgreicher Prüfung wird das Zertifikat ausgestellt. Der Unterschied liegt nur darin, ob du den TXT-Eintrag manuell setzt oder ob ein DNS-Plugin den Schritt übernimmt. Ich trenne diese beiden Wege konsequent, weil sie zwar dasselbe Ziel haben, im Betrieb aber sehr unterschiedliche Konsequenzen mitbringen.

Voraussetzungen

• Die Domain muss öffentlich in einem DNS liegen, den die Zertifizierungsstelle erreichen kann.
• Du brauchst Zugriff auf die DNS-Zone, entweder per Weboberfläche oder per API.
• Certbot muss installiert sein; bei automatisierten Setups zusätzlich das passende DNS-Plugin.
• Wenn du die API nutzt, sollte die Credential-Datei nur für den administrativen Account lesbar sein.

Gerade in deutschen Umgebungen ist der zweite Punkt oft der Engpass. Viele Setups laufen bei einem Hoster, der zwar DNS anbietet, aber keine saubere Automatisierung vorbereitet. Dann kann Wildcard zwar trotzdem funktionieren, nur eben nicht besonders elegant.

Manuelle DNS-Validierung

Für Testumgebungen oder sehr kleine Umgebungen reicht die manuelle Methode aus. Certbot führt dich dann Schritt für Schritt durch den DNS-Eintrag:

sudo certbot certonly --manual --preferred-challenges dns -d example.de -d '*.example.de'

Du bekommst einen Wert, den du als TXT-Record unter _acme-challenge.example.de einträgst. Wenn du Apex und Wildcard gemeinsam bestellst, können dabei mehrere TXT-Werte am gleichen Namen auftauchen. Das ist normal. Ich räume solche Einträge nach erfolgreicher Ausstellung wieder auf, damit sich der DNS-Record nicht mit alten Werten aufbläht.

Lesen Sie auch: Nonce erklärt - Warum der Einmalwert in TLS & ACME so wichtig ist

Automatische Validierung mit DNS-Plugin

Wenn dein DNS-Provider ein passendes Plugin anbietet, ist das mein Standard für produktive Systeme. Dann kann Certbot den TXT-Record selbst anlegen und später auch die Erneuerung ohne Eingriff durchlaufen:

sudo certbot certonly --dns-cloudflare --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini -d example.de -d '*.example.de'

Das konkrete Plugin hängt vom Provider ab, der Grundgedanke bleibt aber gleich: API-Zugang, TXT-Record setzen, Zertifikat ausstellen, später automatisch erneuern. Die Certbot-Dokumentation unterscheidet genau deshalb sauber zwischen manueller DNS-Validierung und DNS-Plugins. Wenn es kein offizielles Plugin gibt, kann ein --manual-auth-hook helfen, aber dann baust du praktisch deine eigene Automationsschicht. Das mache ich nur, wenn es keinen besseren Weg gibt.

Der Unterschied zwischen den Varianten ist in der Theorie klein, im Betrieb aber groß. Genau dort entscheidet sich, ob das Setup angenehm bleibt oder später Pflege verursacht.

Welche Variante ich im Alltag bevorzuge

Ich würde Wildcards nicht aus Gewohnheit einsetzen, sondern nur dann, wenn sie das Betriebsmodell wirklich vereinfachen. Die folgende Einordnung hilft bei der Entscheidung:

Wichtig ist noch die Abgrenzung zu HTTP-01: Webroot, Apache-Installer oder Nginx-Installer lösen das Wildcard-Problem nicht selbst aus, weil sie auf HTTP-Validierung basieren. Sie können das Zertifikat später einbinden, aber die Domainprüfung bleibt bei Wildcards DNS-basiert. Wenn du das sauber trennst, vermeidest du die typischen Fehlannahmen schon im Vorfeld.

Genau bei DNS tauchen dann auch die meisten Praxisfehler auf.

Die typischen Fehler bei Wildcards und wie man sie vermeidet

• Ich vergesse die Apex-Domain. Ein Zertifikat nur für *.example.de schützt nicht automatisch example.de. Wenn beide Namen gebraucht werden, müssen sie gemeinsam angefordert werden.
• Ich nutze den falschen Challenge-Typ. HTTP-01 oder Webroot helfen hier nicht. Für Wildcards immer DNS-01.
• Der TXT-Eintrag ist noch nicht öffentlich sichtbar. Viele Fehlschläge sind reine Propagation. Ich warte lieber auf die sichtbare DNS-Antwort, statt mehrfach neu auszustellen.
• Alte TXT-Werte bleiben liegen. Bei wiederholten Versuchen sammeln sich Einträge unter _acme-challenge an. Ich räume sie nach erfolgreicher Ausstellung auf, damit die Antwort nicht unnötig groß wird.
• CAA blockiert die Ausstellung. CAA-Einträge legen fest, welche Zertifizierungsstellen überhaupt ausstellen dürfen. Wenn die Validierung korrekt ist, die Ausstellung aber trotzdem scheitert, prüfe ich diese DNS-Policy zuerst.
• Ich erwarte zu viel vom Stern. *.example.de deckt nur eine Ebene ab. Für weitere Ebenen brauchst du zusätzliche Namen oder separate Zertifikate.

Ein zusätzlicher Prüfpunkt, der oft übersehen wird, ist die öffentliche Sichtbarkeit. Nicht jede interne DNS-Struktur spiegelt das wider, was außen tatsächlich abgefragt wird. Für die ACME-Prüfung zählt nur der öffentliche, autoritative DNS-Eintrag - nicht das, was im lokalen Resolver oder im Firmen-LAN steht.

Wenn die Ausstellung einmal funktioniert, entscheidet die Erneuerung darüber, ob das Setup wartbar bleibt.

So halte ich die Erneuerung stabil

Certbot-Zertifikate laufen standardmäßig 90 Tage; ich plane den Renew-Prozess deshalb meist um Tag 60 herum. So bleibt genug Puffer für DNS-Probleme, API-Ausfälle oder geänderte Provider-Policies. Der kleine zeitliche Abstand macht im Betrieb einen großen Unterschied, weil du nicht erst kurz vor Ablauf unter Druck gerätst.

sudo certbot renew --dry-run

Mit diesem Test prüfe ich jede Änderung an DNS-Plugin, API-Zugang oder Hook-Skript, bevor sie produktiv wird. Wenn der Dry-Run sauber durchläuft, ist das ein gutes Zeichen dafür, dass auch die echte Erneuerung funktioniert. Für Webserver-Reloads nutze ich anschließend einen Deploy-Hook, damit nur bei tatsächlich erneuertem Zertifikat neu geladen wird:

sudo certbot renew --deploy-hook "systemctl reload nginx"

Bei Apache ist der Befehl entsprechend angepasst. Der Punkt ist nicht der konkrete Service, sondern die Logik dahinter: Zertifikat erneuern, nur dann reloaden, und die Erneuerung regelmäßig testen. Wenn ich mehrere Frontends habe, läuft Certbot oft zentral, aber der Reload der Zielsysteme ist trotzdem separat zu denken.

• Prüfe Zertifikate regelmäßig mit certbot certificates.
• Nutze für API-Zugänge möglichst restriktive Tokens mit minimalen Rechten.
• Hinterlege die Credential-Dateien nur mit den nötigen Dateirechten.
• Teste nach Änderungen an DNS oder Hoster-API immer einen Dry-Run.

Am Ende zählt nicht die einmalige Ausstellung, sondern ein kleiner, wiederholbarer Betriebsablauf.

Was ich für einen stabilen Wildcard-Betrieb empfehle

Ich würde Wildcards mit Certbot nur dann einsetzen, wenn die DNS-Automatisierung sauber steht. Ohne diese Basis wird aus einer eleganten Lösung schnell ein Pflegefall. Wenn Zone, Plugin und Renewal-Job zusammenpassen, ist ein Wildcard-Zertifikat dagegen sehr robust und im Betrieb deutlich angenehmer als viele Einzelzertifikate.

Für neue Projekte prüfe ich deshalb zuerst, ob Wildcard wirklich nötig ist. Wenn nur zwei oder drei feste Hostnamen abgesichert werden müssen, ist ein normales SAN-Zertifikat oft übersichtlicher. Wenn aber regelmäßig Subdomains dazukommen, ist die Kombination aus Certbot, DNS-01 und automatischer Erneuerung die deutlich bessere Strategie.