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, 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.

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.

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 keine gültigen Zertifikatsnamen.
• Die HTTP-Domainvalidierung muss die Firewall über Port 80 erreichen können.
• Die Firewall erstellt für die Validierung temporäre Webserver- beziehungsweise WAF-Komponenten.
• Nach erfolgreicher Ausstellung werden die temporären Validierungskomponenten wieder entfernt.
• Zertifikate sind kurzlebig und müssen automatisch erneuert werden.

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.
• Der öffentliche DNS-Name zeigt auf die WAN-Adresse oder Hosted Address der Firewall.
• Port 80 ist für die HTTP-Validierung von aussen erreichbar.
• Es gibt keine aktive DNAT-, WAF- oder andere Regel, die die Validierungsanfrage auf Port 80 abfängt.
• 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, 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:

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.

Grundablauf:

1. Certificates öffnen.
2. Let’s-Encrypt-Bereich beziehungsweise Zertifikatsanforderung öffnen.
3. Let’s-Encrypt-Konto auf der Firewall vorbereiten.
4. Gewünschte FQDNs eintragen.
5. WAN-Interface oder öffentliche Adresse für die HTTP-Validierung auswählen.
6. Prüfen, ob Port 80 von aussen zur Firewall zeigt.
7. Zertifikat anfordern.
8. Nach erfolgreicher Ausstellung unter Certificates > Certificates prüfen, ob das Zertifikat vorhanden und gültig ist.

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.

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:

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 oder WebAdmin 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 kurzlebig. Die Stärke der Integration liegt darin, dass die Firewall die Erneuerung automatisch durchführen kann. 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?
• 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

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 oder vorgelagertem NAT geprüft.
• 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