Let's Encrypt Wildcard Zertifikat erstellen

Ein Let’s Encrypt Wildcard Zertifikat ist sinnvoll, wenn mehrere Subdomains mit einem gemeinsamen Zertifikat abgesichert werden sollen, zum Beispiel app.example.com, vpn.example.com und portal.example.com. Für Sophos ZTNA, Reverse Proxies, Testumgebungen oder mehrere interne Webdienste kann das praktisch sein.

Wichtig ist die Erwartung: Let’s-Encrypt-Zertifikate sind kurzlebig. Der Vorteil liegt nicht in langer Laufzeit, sondern in kostenloser Ausstellung und Automatisierung. Wenn das Zertifikat manuell per DNS-TXT-Eintrag erstellt wird, muss die spätere Erneuerung bewusst geplant werden.

Wenn das Zertifikat direkt auf einer Sophos Firewall für WAF, WebAdmin oder Portale erstellt werden soll, passt meistens der eingebaute Firewall-Weg besser: Sophos Firewall Let’s Encrypt Zertifikate einrichten. Dieser Artikel beschreibt den externen Wildcard-Weg mit Certbot.

Wann ein Wildcard-Zertifikat sinnvoll ist

Ein Wildcard-Zertifikat deckt eine Ebene unterhalb einer Domain ab. *.example.com passt also für portal.example.com, aber nicht automatisch für example.com selbst und auch nicht für a.b.example.com.

• Viele Subdomains unter derselben Zone: Ein Wildcard-Zertifikat kann die Administration vereinfachen.
• Nur ein einzelner öffentlicher Dienst: Ein einzelnes FQDN-Zertifikat ist oft sauberer.
• Zertifikat soll auf mehreren Systemen genutzt werden: Ein Wildcard-Zertifikat kann praktisch sein, aber die Schlüsselverteilung muss streng kontrolliert werden.
• Vollautomatische Erneuerung ist nötig: DNS-Provider mit Certbot-Plugin oder einen anderen ACME-Client einplanen.
• Sophos Firewall soll nur WAF, WebAdmin oder Portale absichern: Den eingebauten Firewall-Let’s-Encrypt-Weg prüfen.

Ein Wildcard-Zertifikat ist kein Sicherheitsgewinn an sich. Wenn derselbe private Schlüssel auf mehreren Systemen liegt, steigt sogar die Auswirkung eines Schlüsselverlusts. Deshalb sollte dokumentiert sein, wo das Zertifikat importiert wurde und wer den privaten Schlüssel verwaltet.

Voraussetzungen

Für ein Wildcard-Zertifikat braucht man:

• eine eigene Domain oder Subdomain-Zone
• Zugriff auf DNS-TXT-Records der Domain
• einen Linux-Server oder Admin-Rechner mit Certbot
• Berechtigung, Certbot mit Root-Rechten auszuführen
• einen Plan für Renewal, Import und Schlüsselablage
• Zugriff auf das Zielsystem, zum Beispiel Sophos Central ZTNA, Reverse Proxy oder Firewall

Wildcard-Zertifikate werden über die DNS-01 Challenge validiert. Dabei wird ein TXT-Record unter _acme-challenge.example.com gesetzt. Let’s Encrypt prüft diesen DNS-Eintrag und stellt danach das Zertifikat aus. Die grundlegenden Challenge-Typen beschreibt Let’s Encrypt in der Challenge-Types-Dokumentation.

Certbot installieren

Die Certbot-Projektseite empfiehlt für viele Linux-Umgebungen die Installation über Snap. Auf einem passenden Linux-System sieht der Grundablauf so aus:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

Wenn Certbot bereits über apt, dnf oder ein anderes Paket installiert wurde, sollte man vorher prüfen, welcher Certbot tatsächlich verwendet wird. Mehrere parallele Installationswege führen sonst schnell zu falschen Versionen oder unerwarteten Renewal-Jobs.

Wildcard-Zertifikat manuell erstellen

Für eine manuelle DNS-Validierung kann Certbot mit --manual und --preferred-challenges dns gestartet werden. Im Beispiel soll das Zertifikat sowohl für example.com als auch für *.example.com gelten:

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

Certbot zeigt danach einen oder mehrere TXT-Werte an. Wenn example.com und *.example.com gleichzeitig beantragt werden, sind es zwei getrennte DNS-01-Challenges. Beide TXT-Werte müssen als separate TXT-Records unter _acme-challenge.example.com angelegt werden. Den zweiten Eintrag also zusätzlich anlegen und nicht den ersten überschreiben.

Erst wenn alle DNS-Einträge weltweit sichtbar sind, sollte man in Certbot bestätigen und die Validierung fortsetzen.

Praktische Prüfung:

dig TXT _acme-challenge.example.com @1.1.1.1

• certonly: Zertifikat beantragen oder erneuern, ohne es direkt zu installieren.
• --manual: DNS-Wert manuell setzen.
• --preferred-challenges dns: DNS-01 Challenge verwenden.
• -d example.com: Root-Domain zusätzlich aufnehmen.
• -d '*.example.com': Wildcard-Domain aufnehmen.

Die Root-Domain und die Wildcard-Domain sind getrennte Namen. Wenn nur *.example.com beantragt wird, ist example.com selbst nicht automatisch enthalten. Bei gleichzeitiger Beantragung können mehrere TXT-Records mit demselben Namen nötig sein. Das ist im DNS erlaubt und genau der Punkt, an dem Validierungen häufig scheitern, weil ein bestehender TXT-Wert versehentlich ersetzt wird.

Zertifikatsdateien finden

Nach erfolgreicher Ausstellung liegen die Dateien typischerweise unter:

/etc/letsencrypt/live/example.com/

Wichtige Dateien:

• fullchain.pem: Zertifikat inklusive Zwischenzertifikaten.
• cert.pem: nur das Serverzertifikat.
• privkey.pem: privater Schlüssel.
• chain.pem: Zwischenzertifikate.

Viele Zielsysteme benötigen fullchain.pem und privkey.pem. Manche Importmasken verlangen Zertifikat und Schlüssel getrennt, andere zusätzlich die Chain. Vor dem Import sollte klar sein, welches Format das Zielsystem erwartet.

⚠️ privkey.pem ist der private Schlüssel. Diese Datei darf nicht in Tickets, Chats, E-Mails oder unsicheren Ablagen landen. Wer den privaten Schlüssel besitzt, kann das Zertifikat missbrauchen.

Erneuerung planen

Der manuelle --manual-Weg ist für Tests und Einzelaktionen einfach, aber für produktive Zertifikate nur bedingt geeignet. Ohne Automatisierung muss bei jeder Erneuerung wieder ein neuer DNS-TXT-Record gesetzt werden.

Für produktive Nutzung gibt es drei saubere Varianten:

• DNS-Plugin für den DNS-Provider: passend, wenn Certbot DNS-Records per API setzen darf.
• Anderer ACME-Client mit DNS-Automation: passend, wenn der Provider oder die Plattform besser unterstützt wird.
• Manuelle Erneuerung mit Kalender und Owner: nur für Tests oder selten genutzte Zertifikate sinnvoll.

Wenn DNS-API-Zugang verwendet wird, sind die API-Zugangsdaten besonders kritisch. Ein DNS-Token sollte nur die nötige Zone und möglichst nur die nötigen Record-Typen ändern dürfen. Breite Domain-Admin-Zugänge gehören nicht ungeschützt auf einen Webserver.

Ein Renewal-Test wird mit Certbot normalerweise so geprüft:

sudo certbot renew --dry-run

Bei manuell erstellten DNS-Zertifikaten ist dieser Test nur aussagekräftig, wenn der DNS-Prozess ebenfalls automatisiert ist oder die manuellen Hooks sauber funktionieren.

Import in Sophos-Umgebungen

Wenn das Zertifikat für Sophos ZTNA, eine Firewall, einen Reverse Proxy oder ein anderes Sophos-nahes System verwendet wird, sollte man vor dem Import diese Punkte prüfen:

• Passt der Zertifikatsname zum öffentlichen Hostnamen?
• Wird die Root-Domain zusätzlich zur Wildcard benötigt?
• Erwartet das Zielsystem fullchain.pem oder getrennte Zertifikatsbestandteile?
• Wird der private Schlüssel akzeptiert oder muss er in ein anderes Format konvertiert werden?
• Gibt es einen dokumentierten Ablauf für die nächste Erneuerung?
• Ist klar, auf welchen Systemen dasselbe Zertifikat importiert wurde?

Wenn es nur um WAF, WebAdmin oder Portale auf Sophos Firewall geht, ist der eingebaute Firewall-Prozess oft einfacher, weil Erstellung und Erneuerung direkt auf der Firewall stattfinden. Für echte Wildcard-Zertifikate bleibt der externe Certbot- oder ACME-Weg aber relevant.

Typische Fehler

• Validierung schlägt fehl: TXT-Record ist noch nicht sichtbar, der DNS-Zonenname ist falsch oder einer von mehreren TXT-Werten wurde überschrieben. Mit dig TXT _acme-challenge.example.com @1.1.1.1 prüfen.
• Zertifikat gilt nicht für example.com: Es wurde nur *.example.com beantragt. Root-Domain zusätzlich mit -d example.com aufnehmen.
• Zertifikat gilt nicht für a.b.example.com: Die Wildcard deckt nur eine Subdomain-Ebene ab. Eigenes Zertifikat oder passende Wildcard für tiefere Zone planen.
• Renewal funktioniert nicht automatisch: Der manuelle DNS-Weg hat keine Automation. DNS-Plugin oder anderen ACME-Client prüfen.
• Import schlägt fehl: Datei oder Format passt nicht. fullchain.pem, cert.pem, privkey.pem und Chain-Anforderung vergleichen.
• Sicherheitsrisiko durch Schlüsselkopien: Der private Schlüssel liegt auf mehreren Systemen. Ablage, Zugriffe und Importorte dokumentieren.

Checkliste

• Domain und Subdomain-Ebene festgelegt.
• Root-Domain und Wildcard bewusst ausgewählt.
• DNS-Zugriff und TXT-Record-Berechtigung vorhanden.
• Certbot sauber installiert.
• DNS-01 Challenge erfolgreich geprüft.
• Zertifikatsdateien und privater Schlüssel sicher abgelegt.
• Zielsystem und benötigtes Importformat bekannt.
• Erneuerung mit Owner, Kalender oder DNS-Automation geplant.
• Alte Zertifikate und Schlüssel nach erfolgreicher Umstellung kontrolliert entfernt.

FAQ