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.

Für ein Sophos-ZTNA-Gateway ist ein Wildcard-Zertifikat erforderlich. Sophos Central kann dieses Zertifikat erzeugen und anschliessend verwalten und erneuern. Alternativ lässt es sich wie in diesem Artikel mit Certbot erstellen und als eigenes Zertifikat hochladen. 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.

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
• für Sophos Central die Berechtigung, den benötigten CNAME-Record im DNS anzulegen und zu ändern
• für den manuellen Certbot-Weg die Berechtigung, DNS-TXT-Records der Domain anzulegen und zu ändern
• für den manuellen Weg einen Linux-Server oder Admin-Rechner mit Certbot
• für den manuellen Weg die Berechtigung, Certbot mit Root-Rechten auszuführen
• einen zum gewählten Weg passenden Plan für Renewal, Import und Schlüsselablage
• Zugriff auf das Zielsystem, zum Beispiel Sophos ZTNA in Sophos Fusion, einen Reverse Proxy oder eine Firewall

Wildcard-Zertifikate werden über die DNS-01-Challenge validiert. Beim manuellen Certbot-Weg wird dafür ein TXT-Record unter _acme-challenge.example.com gesetzt. Beim verwalteten Sophos-Central-Weg delegiert ein CNAME-Record diese Prüfung an Sophos. Die grundlegenden Challenge-Typen beschreibt Let’s Encrypt in der Challenge-Types-Dokumentation.

Für Sophos ZTNA: Zertifikat in Sophos Central erstellen

Für ein ZTNA-Gateway ist der verwaltete Weg in Sophos Central meist einfacher als ein manueller Certbot-Ablauf: Sophos erzeugt das Let’s-Encrypt-Zertifikat und übernimmt danach auch dessen Verwaltung und Erneuerung. Dafür muss die verwendete Gateway-Domain bekannt sein und man benötigt Zugriff auf ihren DNS-Anbieter.

Wenn die DNS-Zone CAA-Records verwendet, muss Let’s Encrypt dort als berechtigte Zertifizierungsstelle zugelassen sein. Andernfalls darf Let’s Encrypt trotz korrekter Domainvalidierung kein Zertifikat ausstellen.

1. In Sophos Central Meine Produkte > ZTNA öffnen und auf Einstellungen klicken.
2. Domänen und Zertifikate öffnen und auf Domäne hinzufügen klicken. Sophos erlaubt hier höchstens 100 Domains. Die Domain im Format example.com eingeben und hinzufügen.
3. Sophos erzeugt für diese Domain einen CNAME-Wert. Diesen beim DNS-Anbieter unter _acme-challenge.example.com anlegen. example.com ist dabei durch die eigene Gateway-Domain zu ersetzen.
4. Zu Domänen und Zertifikate zurückkehren, auf Validieren klicken und bestätigen, dass der CNAME-Record angelegt wurde. Sophos prüft damit die Kontrolle über die Domain.
5. Nach erfolgreicher Validierung auf LE-Zertifikat erzeugen klicken, die Let’s-Encrypt-Abonnentenvereinbarung lesen und akzeptieren und die Erzeugung starten. Sie dauert laut Sophos ungefähr 60 Sekunden; die Seite kann währenddessen verlassen werden.

⚠️ Existiert unter _acme-challenge.example.com bereits ein TXT-Record, muss er für den von Sophos verwendeten CNAME-Record entfernt werden. Vorher prüfen, ob eine andere Anwendung diesen TXT-Record benötigt. Der CNAME-Record muss anschliessend im DNS bestehen bleiben.

Für bereits in Sophos Central vorhandene Domänen hängt das Vorgehen vom Validierungsstatus ab:

• Bereits per DNS-TXT-Eintrag validiert:
  1. Unter Meine Produkte > ZTNA > Einstellungen > Domänen und Zertifikate auf LE-Zertifikat erzeugen klicken.
  2. Unter CNAME hinzufügen den CNAME-Eintrag kopieren und beim DNS-Anbieter unter _acme-challenge.example.com anlegen.
  3. Einen dort vorhandenen TXT-Eintrag erst nach der oben genannten Auswirkungsprüfung entfernen.
  4. Die Anlage des CNAME-Eintrags bestätigen.
  5. Die Let’s-Encrypt-Abonnentenvereinbarung akzeptieren und auf Fortfahren klicken.
  6. Die Zertifikatserzeugung abschliessen und unter Domänen und Zertifikate kontrollieren, ob die Domäne und ihr CNAME-Eintrag im neuen Format angezeigt werden.
• Noch nicht validiert: Die vorhandene Domäne entfernen, über Domäne hinzufügen erneut hinzufügen, mit Validieren validieren und danach das Let’s-Encrypt-Zertifikat mit LE-Zertifikat erzeugen neu erzeugen.

Sophos erzeugt pro Central-Konto nur ein Let’s-Encrypt-Zertifikat. Es enthält alle validierten Domains. Wird später eine weitere Domain validiert, muss das Zertifikat neu erzeugt werden, damit diese Domain aufgenommen wird.

Um das Zertifikat mit einem vorhandenen Gateway zu verknüpfen, Meine Produkte > ZTNA > Gateways öffnen, das Gateway auswählen und unter Domäne und Zertifikat die Option Automatisch (Let’s Encrypt) einstellen. Die Änderung speichern und danach am Gateway die Zertifikatsgültigkeit und das Ablaufdatum prüfen. Wenn Validierung oder Erzeugung noch nicht erfolgreich abgeschlossen ist, das Gateway noch nicht auf das neue Zertifikat umstellen, sondern zuerst den CNAME-Record beim autoritativen DNS-Anbieter kontrollieren.

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.

Vor der Bestätigung sollten mindestens die autoritativen Nameserver der Domain und ein externer Resolver den erwarteten TXT-Wert liefern. Ein einzelner Resolver ist nur ein Indiz, weil DNS-Provider Änderungen je nach Standort unterschiedlich schnell verteilen können.

Praktische Prüfung:

dig TXT _acme-challenge.example.com @1.1.1.1

Die autoritativen Nameserver findet man beispielsweise mit dig NS example.com. Danach lässt sich derselbe TXT-Record gezielt gegen einen dieser Server prüfen. Nach erfolgreicher Validierung werden nicht mehr benötigte Challenge-TXT-Werte wieder entfernt. Alte Werte können spätere Prüfungen unübersichtlich machen und bei vielen Einträgen die DNS-Antwort unnötig vergrössern.

• 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

Den tatsächlichen Zertifikatsnamen, die enthaltenen Domains, das Ablaufdatum und die Dateipfade zeigt Certbot mit einem lesenden Befehl:

sudo certbot certificates

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.

Die erfolgreiche Erneuerung auf dem Certbot-System aktualisiert ein zuvor importiertes Zertifikat auf Sophos Firewall, ZTNA oder einem Reverse Proxy nicht automatisch. Dafür braucht es entweder einen dokumentierten Reimport oder einen getesteten Deploy-Prozess, der nur nach erfolgreicher Erneuerung läuft. Nach jedem Rollout werden Zertifikatsname, Kette und neues Ablaufdatum am tatsächlichen Zielsystem geprüft.

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?

Für Sophos ZTNA wird das mit Certbot erzeugte Zertifikat in Sophos Central dem Gateway zugewiesen: Meine Produkte > ZTNA > Gateways öffnen, den Namen des Gateways anklicken und unter Domäne und Zertifikat die Option Eigenes Zertifikat hochladen wählen. Das erzeugte Zertifikat hochladen und auf Speichern klicken. Anschliessend am Gateway die Gültigkeit und das Ablaufdatum prüfen; ein bald ablaufendes Zertifikat muss erneuert, erneut hochgeladen und wieder am Gateway kontrolliert werden.

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 extern verwaltete Wildcard-Zertifikate bleibt der Certbot- oder ACME-Weg relevant. Danach zeigt Zertifikate auf Sophos Firewall importieren und zuweisen, wie Private Key, CA-Kette und Dienstzuweisung geprüft werden.

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.
• Certbot erneuert, das Zielsystem zeigt aber noch das alte Zertifikat: Reimport oder Deploy-Prozess wurde nicht ausgeführt. Seriennummer beziehungsweise Ablaufdatum direkt am Zielsystem 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.
• Für Sophos Central: DNS-Zugriff und Berechtigung für den benötigten CNAME-Record vorhanden.
• Für den manuellen Certbot-Weg: DNS-Zugriff und TXT-Record-Berechtigung vorhanden.
• Ausstellungsweg über Sophos Central oder einen externen ACME-Client bewusst gewählt.
• Certbot für den manuellen Weg sauber installiert.
• Domainvalidierung per Sophos-CNAME oder manueller DNS-01-Challenge erfolgreich geprüft.
• Beim externen Weg Zertifikatsdateien und privater Schlüssel sicher abgelegt.
• Beim externen Weg Zielsystem und benötigtes Importformat bekannt.
• Erneuerung durch Sophos Central oder mit Owner, Kalender beziehungsweise DNS-Automation geplant.
• Beim externen Weg Reimport oder Deploy-Prozess zum Zielsystem getestet.
• Alte Zertifikate und Schlüssel nach erfolgreicher Umstellung kontrolliert entfernt.

FAQ