Sophos Firewall Let's Encrypt Zertifikate einrichten

Mit Let’s Encrypt Zertifikaten auf Sophos Firewall kann man öffentliche HTTPS-Zertifikate direkt auf der Firewall erstellen und automatisch erneuern lassen. Das ist besonders praktisch für WAF-Veröffentlichungen, WebAdmin, User Portal, VPN Portal als Weboberfläche, Captive Portal, SPX Portal, Hotspot-Anmeldeseiten und SMTP-TLS-Konfigurationen.

Die Funktion reduziert manuelle Zertifikatsarbeit, ersetzt aber keine saubere Planung. DNS, öffentliche Erreichbarkeit, Port 80, Zertifikatsnamen, WAF-Regeln, Portalzugriff und Monitoring müssen zusammenpassen. Wenn die Validierung oder Erneuerung unbemerkt fehlschlägt, kann ein Portal oder eine veröffentlichte Webanwendung trotz eigentlich richtiger WAF-Regel plötzlich mit Zertifikatswarnung ausfallen.

Wichtig ist die Trennung zwischen Portalzertifikat und VPN-Zertifikat: Ein Let’s-Encrypt-Zertifikat kann ein VPN Portal sauber im Browser absichern. Für Remote Access VPN, Site-to-Site VPN und Chromebook SSO nennt Sophos dagegen Einschränkungen. Diese Fälle sollten separat geplant werden.

Für die eigentliche Veröffentlichung eines Webservers passt zuerst Sophos Firewall WAF: Webserver sicher veröffentlichen. Dieser Artikel konzentriert sich auf die Zertifikatsseite und den Betrieb von Let’s Encrypt auf der Firewall.

Wann Let’s Encrypt auf der Firewall sinnvoll ist

Der eingebaute Let’s-Encrypt-Weg ist sinnvoll, wenn die Sophos Firewall selbst den öffentlichen Dienst bereitstellt oder als Reverse Proxy davorsteht.

• WAF / Web Server Protection: öffentlich erreichbare HTTPS-Anwendungen mit eigenem FQDN.
• WebAdmin: administrativer Zugriff mit sauberem Zertifikat, wenn WebAdmin extern oder intern über FQDN genutzt wird.
• User Portal / VPN Portal: Benutzer melden sich an einem HTTPS-Portal an oder laden Konfigurationen herunter; das ist nicht dasselbe wie das Zertifikat für den VPN-Tunnel selbst.
• Captive Portal / Hotspot: Benutzer sehen eine HTTPS-Anmeldeseite ohne Zertifikatswarnung.
• SMTP TLS: Mail Protection oder SMTP-TLS-Konfiguration mit öffentlichem Zertifikat.

Nicht jeder Dienst passt zu diesem Weg. Für Wildcard-Zertifikate oder Zertifikate, die auf mehreren Systemen ausserhalb der Firewall eingesetzt werden sollen, ist ein extern erzeugtes Zertifikat oft besser. Dafür gibt es den bestehenden Artikel Let’s Encrypt Wildcard Zertifikat erstellen.

Grenzen und wichtige Unterschiede

Sophos Firewall erstellt Let’s-Encrypt-Zertifikate für konkrete FQDNs. Die Integration ist nicht dasselbe wie ein frei verwalteter ACME-Client auf einem Linux-Server.

Wichtige Punkte:

• Die Domain muss als vollständiger FQDN angegeben werden.
• Wildcard-Domains sind für den eingebauten Firewall-Prozess nicht der passende Weg.
• IP-Adressen sind für die HTTP-01-Validierung keine gültigen Zertifikatsnamen.
• Die HTTP-Domainvalidierung muss die Firewall über Port 80 und IPv4 erreichen können.
• Die Firewall erstellt für die Validierung temporär eine WAF-Regel und entfernt sie nach erfolgreicher Validierung wieder.
• Während dieser Validierung können bestehende Webanwendungen, die über WAF-Regeln geschützt werden, kurzfristig nicht über die Firewall erreichbar sein.
• Remote Access VPN, Site-to-Site VPN und Chromebook SSO sollten nicht mit diesem Zertifikatspfad geplant werden.
• Zertifikate sind 90 Tage gültig; die Firewall versucht die automatische Erneuerung, wenn weniger als 30 Tage Restlaufzeit bleiben.
• Wenn die Let’s-Encrypt-Registrierung auf der Firewall aufgehoben wird, werden bestehende Zertifikate nicht weiter erneuert.

Sophos hat die Funktion mit SFOS 21 eingeführt. Die Avanet-Einordnung zu den damaligen Neuerungen steht im Blogpost Sophos Firewall v21: die wichtigsten Neuerungen. In neueren Release Notes sind mehrere WAF- und Let’s-Encrypt-Korrekturen aufgeführt. Für produktive Umgebungen heisst das: Firmwarestand, Zertifikatsstatus und WAF-Betrieb sollten zusammen geprüft werden, nicht isoliert.

Voraussetzungen

Vor dem Erstellen eines Zertifikats sollten diese Punkte geklärt sein:

• Die Firewall läuft auf einer SFOS-Version mit Let’s-Encrypt-Unterstützung.
• Jeder DNS-Name im Zertifikat ist öffentlich auflösbar.
• Die öffentlichen DNS-Antworten zeigen weltweit konsistent auf die WAN-Adresse oder eine IP-Adresse, die Port 80 zur Firewall routet.
• DNS sollte nicht je nach Region unterschiedliche Ziele liefern. Öffentliche DNS-Checker aus mehreren Regionen helfen, Split-Brain- oder GeoDNS-Probleme vor der Anforderung zu finden.
• Pro Name sollte normalerweise nur eine relevante öffentliche IP-Adresse antworten. Mehrere A-Records sind nur sauber, wenn alle beteiligten Ziele HTTP-Traffic auf Port 80 zuverlässig zur Firewall weiterleiten.
• Port 80 ist für die HTTP-Validierung von aussen erreichbar.
• Es gibt keine aktive DNAT-, WAF- oder andere Regel auf der betroffenen öffentlichen IP und Port 80, die die Validierungsanfrage auf ein anderes System abfängt.
• GeoIP-Filter, vorgeschaltete Firewalls, Providerfilter und SD-WAN-Routen blockieren die Validierung nicht.
• Die Firewall kann selbst ins Internet kommunizieren.
• Datum, Uhrzeit und NTP der Firewall stimmen.
• Für den späteren Dienst ist klar, ob das Zertifikat in WAF, WebAdmin, Portal oder SMTP TLS verwendet wird.
• Ein Owner prüft Zertifikatsablauf, Renewal-Status und betroffene Dienste regelmässig.

⚠️ Let’s Encrypt ist kein Workaround für unsaubere öffentliche Erreichbarkeit. Wenn Port 80 durch eine alte DNAT-Regel, eine andere WAF-Regel, GeoIP, ein vorgelagertes NAT oder einen Providerfilter blockiert wird, kann die Zertifikatsanforderung oder Erneuerung scheitern.

Zertifikatsnamen planen

Vor der technischen Einrichtung sollte feststehen, welche Hostnamen wirklich gebraucht werden. Gute Zertifikatsplanung verhindert spätere Korrekturen an WAF-Regeln, Portalen und DNS.

Beispiele:

• portal.example.com: User Portal oder VPN Portal.
• vpn.example.com: VPN Portal oder SSL-VPN-Downloadpfad.
• admin.example.com: WebAdmin, wenn extern oder über Management-FQDN genutzt.
• app.example.com: WAF-veröffentlichte Anwendung.
• mail.example.com: SMTP TLS oder Mail Protection.

Bei mehreren Anwendungen sollte man nicht vorschnell alles in ein Zertifikat packen. Ein Zertifikat mit vielen Namen kann praktisch sein, macht aber auch Abhängigkeiten grösser. Wenn ein Zertifikat erneuert, ersetzt oder zurückgebaut wird, sind alle enthaltenen Hostnamen betroffen.

Für WAF-Regeln ist zusätzlich wichtig, dass DNS, Zertifikat, Domains in der WAF-Regel und SNI zusammenpassen. Die WAF-Grundlagen sind in Sophos Firewall WAF: Webserver sicher veröffentlichen beschrieben.

Let’s Encrypt Account und Zertifikat erstellen

Die Einrichtung erfolgt im WebAdmin im Bereich Certificates. Je nach SFOS-Version kann die genaue Darstellung leicht variieren, der Ablauf bleibt aber ähnlich.

Account registrieren

Zuerst wird die Firewall bei Let’s Encrypt registriert.

1. Certificates > Let’s Encrypt öffnen.
2. Subscriber Agreement und Bedingungen prüfen.
3. Register account anklicken.
4. Kontrollieren, ob die Registrierung ohne Warnung aktiv ist.

Wenn Let’s Encrypt die Bedingungen ändert, muss die Registrierung erneut bestätigt werden. Sonst werden bestehende Zertifikate nicht erneuert und neue Zertifikate können nicht erstellt werden. In der Praxis gehört diese Meldung deshalb in den normalen Firewall-Review, nicht in die Kategorie “später anschauen”.

Sophos Firewall weist auf geänderte Bedingungen unter anderem über Administrator-E-Mail und Control Center hin. Diese Hinweise sollten nicht als reine Informationsmeldung behandelt werden: Ohne erneute Bestätigung bleibt der automatische Zertifikatsbetrieb stehen.

Zertifikat anfordern

Danach wird das eigentliche Zertifikat erstellt.

1. Certificates > Certificates öffnen.
2. Add anklicken.
3. Bei Action die Option Request Let’s Encrypt certificate auswählen.
4. Einen sprechenden Namen vergeben, zum Beispiel le-app-example-com.
5. Unter Domains die gewünschten FQDNs eintragen, zum Beispiel app.example.com.
6. Unter Hosted address die öffentliche WAN-Adresse auswählen, auf die diese Domains zeigen.
7. Prüfen, ob Port 80 von aussen wirklich zur Firewall zeigt.
8. Save anklicken.
9. Nach einigen Minuten unter Certificates > Certificates prüfen, ob das Zertifikat als vertrauenswürdig erscheint und ein gültiges Valid until Datum hat.

Während der Validierung nutzt die Firewall den HTTP-Challenge-Response-Mechanismus. Dafür müssen externe Let’s-Encrypt-Systeme den Validierungspfad erreichen können. Wenn die Firewall hinter einem Router, Load Balancer oder Provider-NAT steht, muss die Weiterleitung auf die Firewall zeigen.

Falls der Domainname ungültig ist oder nicht existiert, ist die Korrektur je nach Zustand nicht einfach ein Edit am bestehenden CSR. Dann ist es meist sauberer, die fehlerhafte Anforderung zu löschen und mit korrigiertem FQDN neu anzulegen.

Zertifikat verwenden

Nach der Ausstellung ist das Zertifikat nur vorhanden. Es schützt einen Dienst erst, wenn es dort aktiv ausgewählt wurde.

Typische Zuordnung:

• WAF: betroffene WAF-Regel unter Rules and policies > Firewall rules prüfen.
• WebAdmin: Zertifikat für die WebAdmin-Konsole in den Admin-/Device-Access-nahen Einstellungen prüfen.
• User Portal / VPN Portal: Portal- beziehungsweise VPN-Portal-Konfiguration prüfen.
• Captive Portal / Hotspot: Anmeldeseite und Portalzertifikat prüfen.
• SMTP TLS: E-Mail- beziehungsweise SMTP-TLS-Konfiguration prüfen.

Nach der Zuordnung sollte man nicht nur im WebAdmin speichern, sondern den Dienst extern testen. Bei WAF-Veröffentlichungen passt ein Test von ausserhalb des eigenen LANs, weil interne DNS-Sicht, NAT Loopback oder Browsercache sonst falsche Sicherheit geben können.

Go-live-Test

Ein erfolgreicher Go-live-Test besteht aus DNS, TLS, Dienstfunktion und Logging.

Prüfliste:

• Der FQDN löst öffentlich auf die erwartete Adresse auf.
• Port 80 ist während der Validierung zur Firewall erreichbar.
• Port 443 oder der verwendete HTTPS-Port liefert das neue Zertifikat.
• Browser zeigt keine Zertifikatswarnung.
• Zertifikat enthält den erwarteten Hostnamen.
• Ablaufdatum passt zum neu erstellten Zertifikat.
• WAF-Regel, Portal, WebAdmin oder SMTP TLS verwendet wirklich dieses Zertifikat.
• Log Viewer zeigt keine auffälligen WAF-, Portal- oder Zertifikatsfehler.
• Bei WAF-Veröffentlichungen passt reverseproxy.log zum Testzeitpunkt.

Ein einfacher externer TLS-Test kann zusätzlich zeigen, welches Zertifikat tatsächlich ausgeliefert wird. Wichtig ist dabei, den Test von ausserhalb des Kundennetzes auszuführen, nicht nur vom internen Client.

Zertifikatskette prüfen

Nach dem Wechsel auf ein neues Let’s-Encrypt-Zertifikat sollte nicht nur der Common Name oder SAN-Eintrag geprüft werden. Entscheidend ist auch, ob der Client die vollständige Zertifikatskette sieht. Wenn ein Browser, eine App oder ein Monitoring-System eine unvollständige Chain meldet, kann die Ursache bei der Zertifikatsauswahl, einem alten importierten Zertifikat, einer falschen WAF-Regel oder einem zwischengeschalteten Reverse Proxy liegen.

Praktisch sollte man diese Punkte prüfen:

• Externer HTTPS-Test zeigt den erwarteten FQDN ohne Zertifikatswarnung.
• Das ausgelieferte Zertifikat ist wirklich das neue Let’s-Encrypt-Zertifikat der Sophos Firewall.
• Die Zertifikatskette ist vollständig und wird nicht durch ein altes Backend- oder Proxy-Zertifikat ersetzt.
• WAF-Regel, Portal oder WebAdmin verwenden dasselbe Zertifikat, das im externen Test sichtbar ist.
• Falls ein vorgeschalteter Load Balancer, Router oder Reverse Proxy beteiligt ist, wird dort kein anderes Zertifikat ausgeliefert.

Diese Prüfung ist besonders wichtig, wenn dieselbe Domain früher über eine andere Veröffentlichung lief oder wenn mehrere WAF-Regeln, DNAT-Regeln oder externe Proxies denselben Hostnamen verwenden. Sonst sieht man im WebAdmin ein gültiges Zertifikat, während Clients von aussen trotzdem eine andere oder unvollständige Chain erhalten.

Erneuerung im Betrieb überwachen

Let’s-Encrypt-Zertifikate sind 90 Tage gültig. Die Stärke der Integration liegt darin, dass die Firewall die Erneuerung automatisch durchführen kann, sobald ein Zertifikat weniger als 30 Tage Restlaufzeit hat. Trotzdem sollte man den Prozess nicht blind laufen lassen.

In einem Betriebscheck sollten diese Punkte regelmässig geprüft werden:

• Läuft die Firewall auf einem aktuellen, stabilen SFOS-Stand?
• Ist das Zertifikat noch gültig?
• Wurde die automatische Erneuerung erfolgreich durchgeführt?
• Ist Port 80 weiterhin für die Validierung erreichbar?
• Gibt es neue DNAT- oder WAF-Regeln, die die Validierung blockieren könnten?
• Ist die Let’s-Encrypt-Registrierung weiterhin aktiv und wurden geänderte Bedingungen bestätigt?
• Zeigen Benutzer oder Monitoring Zertifikatswarnungen?
• Gibt es WAF- oder Portalfehler im Log Viewer?

Besonders wichtig ist diese Prüfung nach Firewall-Upgrades, WAF-Änderungen, Providerwechseln, DNS-Umstellungen und Änderungen an vorgeschalteten Routern oder Reverse Proxies.

Typische Fehler

• Zertifikat wird nicht erstellt: Der FQDN zeigt möglicherweise nicht auf die Firewall oder Port 80 ist nicht erreichbar. Öffentliche DNS-Auflösung und externen Porttest prüfen.
• Zertifikatsanforderung schlägt nach WAF-Änderung fehl: Eine bestehende Regel fängt die HTTP-Validierung ab. DNAT-, WAF- und Firewall-Regeln auf Port 80 prüfen.
• Validierung schlägt je nach Herkunftsland fehl: GeoIP, vorgeschaltete Filter oder SD-WAN können einzelne Validierungsziele blockieren. Für die Ausstellung sollte Port 80 nicht nur aus dem eigenen Land erreichbar sein.
• DNS liefert je nach Region unterschiedliche IPs: Let’s Encrypt validiert nicht zwingend aus der Region des Admins. Öffentliche DNS-Antworten müssen weltweit auf einen Pfad zeigen, der Port 80 zur Firewall bringt.
• Mehrere A-Records zeigen auf unterschiedliche Systeme: Die Validierung kann zufällig ein Ziel erreichen, das den Challenge-Pfad nicht zur Firewall weiterleitet. DNS vereinfachen oder sicherstellen, dass alle Ziele den HTTP-Challenge-Pfad korrekt routen.
• WAF-Anwendung ist während der Ausstellung kurz nicht erreichbar: Die Firewall nutzt temporäre WAF-Mechanik für die Validierung. Kritische Veröffentlichungen sollten deshalb nicht während eines ungeplanten Produktionsfensters geändert werden.
• Zertifikat ist erstellt, Browser zeigt aber altes Zertifikat: Der Dienst verwendet noch ein anderes Zertifikat. WAF-Regel, Portal oder WebAdmin-Zertifikatsauswahl prüfen.
• Browser oder Monitoring meldet unvollständige Zertifikatskette: Falsches Zertifikat ist aktiv, die Chain wird nicht vollständig ausgeliefert oder ein vorgeschalteter Proxy liefert ein anderes Zertifikat. Externen TLS-Test, WAF-Regel, Portalzuordnung und mögliche Proxies vergleichen.
• WAF-Anwendung funktioniert nach Zertifikatswechsel nicht sauber: SNI, Domain, Backend-Host oder Schutzprofil passt möglicherweise nicht. WAF-Regel, Domains, reverseproxy.log und Backend-Logs prüfen.
• Erneuerung funktioniert nicht: Der Validierungspfad hat sich seit der Erstellung geändert. DNS, Port 80, vorgeschaltetes NAT und Firmwarestand prüfen.
• Erneuerung stoppt nach geänderten Bedingungen: Wenn das Let’s-Encrypt-Subscriber-Agreement erneut bestätigt werden muss, bleiben neue Zertifikate und Erneuerungen blockiert, bis Register account wieder bestätigt wurde.
• Zertifikate werden nach Deregistrierung nicht erneuert: Wenn der Let’s-Encrypt-Account auf der Firewall deregistriert wurde, muss man nicht nur das einzelne Zertifikat, sondern zuerst den Account-Status prüfen.
• Zertifikat soll für Remote Access VPN oder Site-to-Site VPN verwendet werden: Das ist nicht der unterstützte Einsatzzweck dieser Integration. Für VPN-Zertifikate sollte ein eigener Zertifikatspfad geplant werden.
• Control Center zeigt WAF- oder Zertifikatswarnung: Alte WAF-Regel, WAF-Restart oder Zertifikatsstatus kann problematisch sein. Log Viewer, WAF-Regeln und Zertifikatsliste prüfen.

Wenn WAF und Zertifikat zusammen auffällig sind, sollte man nicht nur am Zertifikat suchen. WAF-Matching, Hosted Address, Domains, SNI und Backend-Erreichbarkeit gehören zur gleichen Fehlerkette.

Rollback planen

Bei öffentlichen Portalen und WAF-Anwendungen sollte vor einem Zertifikatswechsel klar sein, wie man zurückgeht.

Sinnvolle Vorbereitung:

• bisheriges Zertifikat nicht sofort löschen
• betroffene WAF-Regel und Portal-Konfiguration dokumentieren
• externen Testzugang bereithalten
• DNS-TTL kennen, falls Hostnamen umgestellt werden
• Wartungsfenster für kritische Portale wählen
• Benutzerkommunikation vorbereiten, wenn ein Portal betroffen ist

Wenn das neue Zertifikat zwar erstellt wurde, aber ein Dienst danach falsch arbeitet, kann man meistens wieder das vorherige Zertifikat auswählen. Wenn die Ursache dagegen eine blockierte HTTP-Validierung ist, hilft ein Zertifikatsrollback nur kurzfristig. Dann muss der Validierungspfad korrigiert werden, sonst scheitert die nächste Erneuerung erneut.

Checkliste

• FQDNs und Dienste dokumentiert.
• Öffentliche DNS-Auflösung geprüft.
• Port 80 für HTTP-Validierung geprüft.
• Konflikte mit DNAT, WAF, GeoIP, SD-WAN oder vorgelagertem NAT geprüft.
• Let’s-Encrypt-Account registriert und geänderte Bedingungen bestätigt.
• Let’s-Encrypt-Zertifikat erstellt.
• Zertifikat dem richtigen Dienst zugewiesen.
• Externer HTTPS-Test durchgeführt.
• Log Viewer und bei WAF reverseproxy.log geprüft.
• Renewal-Verantwortung und Monitoring festgelegt.
• Altes Zertifikat erst nach erfolgreichem Betrieb entfernt.

FAQ