Zertifikate auf Sophos Firewall importieren und zuweisen

Ein Zertifikat ist auf der Sophos Firewall erst einsatzbereit, wenn vier Dinge zusammenpassen: Hostname, Serverzertifikat, Private Key und ausstellende CA-Kette. Danach muss das Zertifikat noch dem richtigen Dienst zugewiesen werden. Nur der Eintrag unter Certificates > Certificates ändert noch kein Portal und keine WAF-Regel.

Für ein Zertifikat einer internen oder öffentlichen CA ist der sicherste Standardweg:

1. Unter Certificates > Certificates > Add einen Certificate Signing Request (CSR) erzeugen.
2. Den CSR von der gewünschten CA signieren lassen.
3. Das ausgestellte Zertifikat über die Importaktion beim vorhandenen CSR einlesen.
4. Unter Trusted die installierte zugehörige CA und unter Valid until die Gültigkeit prüfen.
5. Das Zertifikat dem gewünschten Dienst zuweisen und von einem Client aus testen.

Bei diesem Weg entsteht der Private Key auf der Firewall und muss sie nicht verlassen. Ein bereits extern erzeugtes Zertifikat kann ebenfalls hochgeladen werden, benötigt aber den dazugehörigen Private Key und gegebenenfalls die fehlenden Intermediate- und Root-CAs.

Liegt bereits eine PFX- oder PEM-Datei vor, führt der Schnellweg über Certificates > Certificates > Add > Upload certificate: Format wählen, Zertifikat samt benötigtem Private Key und Passwort hochladen und danach zugehörige CA, Laufzeit sowie Dienstzuweisung prüfen.

Welcher Zertifikatsweg passt?

• Öffentliche oder interne CA, neues Zertifikat: CSR auf der Firewall erzeugen. Das reduziert Schlüsseltransporte und verhindert leicht verwechselte Zertifikat-Key-Paare.
• Vorhandenes Zertifikat mit Private Key: Zertifikat als PEM, DER, CER oder PKCS12 hochladen. Format, Passwort und CA-Kette müssen passen.
• Let’s Encrypt für einen öffentlichen Firewall-Dienst: Der eingebaute Prozess kann Ausstellung und Erneuerung übernehmen. Der vollständige Ablauf steht unter Let’s Encrypt Zertifikate auf Sophos Firewall einrichten.
• Externes Wildcard-Zertifikat: Ausserhalb der Firewall erstellen und anschliessend importieren. Planung und DNS-01-Validierung beschreibt Let’s Encrypt Wildcard Zertifikat erstellen.
• Nur für interne, verwaltete Clients: Ein lokal signiertes Zertifikat kann genügen, wenn alle Clients der ausstellenden internen CA vertrauen.

Ein selbst signiertes oder lokal signiertes Zertifikat ist nicht automatisch unsicher verschlüsselt. Ohne verteilte Vertrauenskette kann der Client die Identität aber nicht zuverlässig bestätigen und zeigt eine Warnung. Für öffentlich erreichbare Portale und WAF-Anwendungen ist deshalb normalerweise eine öffentliche CA die bessere Wahl.

Zertifikat, CA, Private Key und CSR unterscheiden

Diese vier Bestandteile haben unterschiedliche Aufgaben:

• Serverzertifikat: enthält Identität, öffentliche Schlüsselangaben, gültige Namen und Laufzeit. Es wird dem Client präsentiert.
• Private Key: beweist, dass die Firewall das Zertifikat verwenden darf. Er darf nie in Tickets, Screenshots oder öffentliche Ablagen gelangen.
• CA-Zertifikate: bilden die Vertrauenskette von der ausstellenden Intermediate-CA bis zur Root-CA. Dafür wird kein privater CA-Schlüssel benötigt.
• CSR: enthält den Zertifikatsantrag und den öffentlichen Schlüssel. Beim auf der Firewall erzeugten CSR bleibt der zugehörige Private Key auf dem Gerät.

Eine CA für TLS Inspection erfüllt eine andere Aufgabe als ein Serverzertifikat für WebAdmin oder WAF. Die Inspection-CA signiert während der Entschlüsselung neue Zertifikate für Clients. Deren Auswahl und Verteilung erklärt Sophos Firewall CA-Zertifikat für TLS Inspection verteilen.

Namen, Laufzeit und Kette vorbereiten

Vor dem Import sollte klar sein, welchen Namen Benutzer und Systeme tatsächlich öffnen. Moderne Clients prüfen vor allem die Subject Alternative Names (SAN). Der Common Name allein ist kein verlässlicher Ersatz.

Beispiel:

• aufgerufene URL: https://vpn.example.com
• Zertifikatsname in SFOS: public-vpn-example-com-2026
• SAN im Zertifikat: vpn.example.com
• DNS: vpn.example.com zeigt auf den vorgesehenen Firewall- oder WAF-Zugang

vpn.example.com ist ein Beispiel und wird durch den eigenen FQDN ersetzt. Greift ein Admin stattdessen über die IP-Adresse oder einen anderen Alias zu, passt das Zertifikat nur, wenn auch dieser Name beziehungsweise diese IP als SAN enthalten ist.

Vor der Änderung prüfen:

• Datum, Uhrzeit und NTP der Firewall stimmen.
• Alle benötigten FQDNs stehen als SAN im Antrag oder Zertifikat.
• Private Key und Zertifikat gehören zusammen.
• Intermediate- und Root-CA sind bekannt.
• Ablaufdatum und Erneuerungsverantwortung sind dokumentiert.
• Das bisherige Zertifikat und seine Zuweisungen bleiben für einen Rückweg erhalten.

Empfohlener Weg: CSR auf der Firewall erzeugen

CSR erstellen

1. Certificates > Certificates öffnen.
2. Add wählen.
3. Unter Action Generate certificate signing request (CSR) auswählen.
4. Einen sprechenden internen Namen vergeben, zum Beispiel public-vpn-example-com-2026.
5. Den benötigten Key Type, die Schlüssellänge beziehungsweise Kurve und den Hash gemäss eigener Sicherheits- und CA-Vorgabe wählen.
6. Bei Common name den primären FQDN eintragen, zum Beispiel vpn.example.com.
7. Unter Subject Alternative Names mindestens den tatsächlich verwendeten DNS-Namen hinzufügen.
8. Speichern und den CSR über das Download-Symbol herunterladen.

Der interne Zertifikatsname ist nur eine SFOS-Bezeichnung. Er muss nicht dem FQDN entsprechen, sollte aber Zweck und Erneuerungsjahr erkennen lassen. Die SAN-Einträge sind dagegen Teil der technischen Identitätsprüfung und müssen zur späteren URL passen.

CSR signieren lassen

Den heruntergeladenen CSR an die zuständige öffentliche oder interne CA übergeben. Dabei keine neuen Schlüsseldateien erzeugen lassen, wenn der auf der Firewall erstellte Private Key verwendet werden soll. Die CA liefert anschliessend das signierte Serverzertifikat und je nach Anbieter zusätzliche Intermediate-Zertifikate.

Vor dem Import kontrollieren:

• Die CA hat den richtigen CSR signiert.
• Die SAN-Liste enthält alle freigegebenen Namen.
• Laufzeit und Aussteller entsprechen der Bestellung beziehungsweise internen Policy.
• Die CA-Kette liegt vollständig vor.

Signiertes Zertifikat zum CSR importieren

1. Certificates > Certificates öffnen.
2. In der Zeile des passenden CSR unter Manage die Importaktion wählen.
3. Das ausgestellte Zertifikat hochladen oder den Zertifikatstext einfügen.
4. Als Zweck normalerweise Certificate only wählen. Wenn dieselbe Datei zusätzlich die CA-Kette enthält, den dazu passenden Zertifikats- und CA-Zweck wählen.
5. Import certificate ausführen.

SFOS ordnet das Zertifikat dem auf der Firewall vorhandenen Private Key zu und entfernt danach den CSR-Eintrag. Deshalb vor dem Import sorgfältig prüfen, dass wirklich die richtige CSR-Zeile gewählt wurde.

Vorhandenes Zertifikat mit Private Key hochladen

Wenn Zertifikat und Schlüssel bereits ausserhalb der Firewall erzeugt wurden:

1. Certificates > Certificates > Add öffnen.
2. Upload certificate wählen.
3. Einen eindeutigen Namen vergeben.
4. Das vorhandene Dateiformat auswählen.
5. Zertifikat und die vom Format benötigten Schlüsseldaten hochladen.
6. Falls der Private Key verschlüsselt ist, dessen Passwort eingeben.
7. Speichern.

SFOS unterstützt diese Zertifikatsformate:

• PEM (.pem): Base64-kodiert; Zertifikat und Private Key liegen normalerweise in getrennten Dateien.
• DER (.der) und CER (.cer): binäre Zertifikatsformate; der Private Key liegt separat vor.
• PKCS7 (.p7b): kann Zertifikate und eine Kette enthalten, aber keinen Private Key.
• PKCS12 (.pfx oder .p12): kann Serverzertifikat, CA-Kette und Private Key gemeinsam enthalten.

RSA- und ECC-Schlüssel werden unterstützt. Für das Passwort eines importierten Private Keys akzeptiert SFOS höchstens 30 Zeichen. Diese Produktgrenze ist kein Grund, einen ungeschützten Private Key zu verwenden: Für den Transfer ein starkes Passwort innerhalb der Grenze setzen und die Importdatei danach aus unsicheren Zwischenablagen entfernen.

Fehlende CA-Kette ergänzen

Unter Certificates > Certificates zeigt ein grüner Eintrag in Trusted, dass die zugehörige CA auf SFOS installiert ist. Fehlt er, zuerst Aussteller und Kette prüfen:

1. Certificates > Certificate authorities öffnen.
2. Add wählen.
3. Fehlende Intermediate- oder Root-CA hochladen beziehungsweise den Zertifikatstext einfügen.
4. Für eine reine Vertrauenskette Validation only verwenden.
5. Speichern und den Trusted-Status des Serverzertifikats erneut prüfen.

Eine öffentliche Root- oder Intermediate-CA benötigt für die Validierung keinen Private Key. Signing and validation ist nur für eine CA gedacht, mit der die Firewall selbst Zertifikate signieren soll und deren Private Key bewusst auf der Firewall vorhanden ist.

Upgrade auf SFOS 21 oder neuer: reservierte CA-Namen prüfen

Beim ersten Upgrade einer älteren Installation auf SFOS 21 oder neuer kann NC-146082 die Migration blockieren. Ursache ist nicht die Gültigkeit des Zertifikats, sondern ein bereits konfigurierter CA-Eintrag mit einem Namen, den SFOS für integrierte Let’s-Encrypt-CAs benötigt:

Lets_Encrypt_R10
Lets_Encrypt_R11
Lets_Encrypt_R12
Lets_Encrypt_R13
Lets_Encrypt_R14
Lets_Encrypt_E5
Lets_Encrypt_E6
Lets_Encrypt_E7
Lets_Encrypt_E8
Lets_Encrypt_E9

Vor dem Wartungsfenster:

1. Ein frisches Konfigurationsbackup erstellen und Backup-Passwort sowie Secure Storage Master Key bereithalten.
2. Unter Certificates > Certificate authorities nach den exakten Namen suchen. Gibt es keinen Treffer, ist wegen NC-146082 keine Änderung nötig.
3. Bei einem Treffer Typ, Subject, Issuer, Zweck und vorhandenes Schlüsselsymbol dokumentieren. Das Schlüsselsymbol zeigt, dass die Firewall den Private Key der CA besitzt.
4. Eine CA mit Private Key zusätzlich unter Backup and firmware > Import export > Export selective configuration als CertificateAuthority exportieren. Danach prüfen, welche Zertifikate und Dienste von der CA abhängen, etwa VPN, WebAdmin und Portale, WAF, SMTP TLS oder TLS Inspection.
5. Nur einen selbst konfigurierten Eintrag entfernen, dessen Abhängigkeiten vollständig ersetzt oder nachweislich nicht mehr benötigt werden. Anschliessend das Upgrade erneut starten.

Eine eingebaute CA darf nicht entfernt werden. Verweigert der WebAdmin das Löschen, fehlt der ursprüngliche Private Key oder bleibt eine Referenz unklar, sollte das Upgrade gestoppt und Sophos Support beigezogen werden. Datenbank- oder Advanced-Shell-Manipulationen sind dafür kein sicherer Ersatz.

Nach dem Upgrade kontrollieren, ob die integrierten Let’s-Encrypt-CAs vorhanden sind, abhängige Zertifikate wieder Trusted anzeigen und die betroffenen Dienste funktionieren.

Zertifikat dem richtigen Dienst zuweisen

Vor dem Zuweisen: Rückweg sichern

Ein Zertifikatswechsel sollte nicht mit dem Löschen des alten Eintrags beginnen:

1. Neues Zertifikat und vollständige CA-Kette importieren.
2. SAN, Aussteller, Laufzeit und Trusted kontrollieren.
3. Bisherige Zuweisung und betroffene Dienste dokumentieren.
4. Neues Zertifikat zuerst einem Dienst zuweisen.
5. Diesen Dienst über seinen echten FQDN und Port testen.
6. Bei Fehlern sofort wieder das alte Zertifikat auswählen.
7. Weitere Dienste nacheinander umstellen und jeweils prüfen.
8. Altes Zertifikat erst entfernen, wenn keine Referenz mehr besteht und der neue Zustand stabil läuft.

WAF und SMTP lassen sich nacheinander umstellen. WebAdmin, User Portal, VPN Portal, Captive Portal und die beiden SPX-Portale wechseln dagegen über eine gemeinsame Zertifikatsauswahl gleichzeitig.

Bei einer Änderung am WebAdmin zusätzlich eine bestehende Admin-Sitzung und einen alternativen lokalen Managementzugang offenhalten, bis Anmeldung und Zertifikat über den vorgesehenen FQDN geprüft sind.

WebAdmin und Portale

Unter Administration > Admin and user settings > Admin console and end-user interaction wird ein gemeinsames Zertifikat für diese Dienste ausgewählt:

• WebAdmin Console
• User Portal
• VPN Portal
• Captive Portal
• SPX Registration Portal
• SPX Reply Portal

Im Feld Certificate das neue Zertifikat wählen und mit Apply speichern. Das Zertifikat muss alle FQDNs abdecken, unter denen die verwendeten Dienste erreichbar sind. Wird beispielsweise admin.example.com für WebAdmin und vpn.example.com für das VPN Portal genutzt, müssen beide Namen als SAN enthalten sein oder die URL-Planung muss vereinheitlicht werden.

Das VPN-Portalzertifikat schützt die HTTPS-Webseite, über die Benutzer Profile und Clients beziehen. Es ist nicht automatisch das Local- oder Remote-Certificate eines IPsec-Tunnels.

WAF

Bei einer WAF-Veröffentlichung die jeweilige Regel unter Rules and policies > Firewall bearbeiten, HTTPS aktivieren, unter HTTPS certificate das neue Zertifikat wählen und speichern. Die Regel verwendet Protect with web server protection. SNI, Domain in der Regel und SAN im Zertifikat müssen denselben Hostnamen beschreiben.

Eine Änderung an einer WAF-Regel startet die Web-Server-Protection-Regeln neu und trennt bestehende Verbindungen. Für produktive Anwendungen gehört der Zertifikatswechsel deshalb in ein Wartungsfenster. Die vollständige Veröffentlichung und Kontrolle beschreibt Sophos Firewall WAF: Webserver sicher veröffentlichen.

SMTP TLS im MTA-Modus

Für Mail Protection unter Email > General settings > SMTP TLS configuration beim Feld TLS certificate das neue Serverzertifikat wählen und mit Apply speichern. Für öffentliche SMTP-Kommunikation empfiehlt sich ein Zertifikat einer öffentlichen CA, damit Gegenstellen die Identität ohne eigene CA-Verteilung prüfen können. Der restliche Mailfluss steht unter Sophos Firewall Mail Protection im MTA-Modus.

Nach der Änderung ein frisches Sophos Firewall Backup erstellen und Ablaufdatum, Owner sowie nächste Erneuerung dokumentieren.

Zertifikat und Auslieferung kontrollieren

Datei vor dem Import prüfen

Auf einem Admin-Computer mit OpenSSL lässt sich ein PEM-Zertifikat lesend prüfen:

openssl x509 -in firewall.pem -noout -subject -issuer -dates -ext subjectAltName -fingerprint -sha256

firewall.pem wird durch den lokalen Dateipfad ersetzt. Die Ausgabe soll das erwartete Subject, den Aussteller, den Gültigkeitszeitraum, die benötigten SANs und einen SHA-256-Fingerprint zeigen. Der Befehl liest keinen Private Key.

HTTPS-Dienst von aussen prüfen

WebAdmin, Portale und WAF von einem Admin-Computer mit OpenSSL testen:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_hostname vpn.example.com -verify_return_error </dev/null

FQDN und Port werden durch den realen HTTPS-Dienst ersetzt. -servername sendet den Namen per SNI, damit bei mehreren WAF- oder Portalzielen das richtige Zertifikat ausgewählt wird. Erfolgreich ist die Prüfung, wenn das erwartete Zertifikat erscheint, der Hostname passt und am Ende Verification: OK steht.

Bei einer internen CA muss der Admin-Computer dieser CA bereits vertrauen oder sie für den Test ausdrücklich als Vertrauensanker erhalten. Ein Verifikationsfehler kann sonst am Testgerät liegen, obwohl die Firewall die richtige Kette ausliefert.

SMTP mit STARTTLS prüfen

SMTP auf Port 25 oder 587 startet normalerweise unverschlüsselt und wechselt erst mit STARTTLS zu TLS. Dafür ist ein eigener Test nötig:

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -verify_hostname mail.example.com -verify_return_error </dev/null

mail.example.com und Port 25 werden durch den SMTP-FQDN und den tatsächlich verwendeten STARTTLS-Port ersetzt. Für implizites TLS auf Port 465 wird -starttls smtp nicht verwendet. Auch hier müssen das erwartete Zertifikat, der Hostname und Verification: OK zusammenpassen.

Zusätzlich im Browser oder Client prüfen:

• URL verwendet einen der enthaltenen SANs.
• Aussteller und Ablaufdatum entsprechen dem neuen Zertifikat.
• Keine Zertifikatswarnung erscheint.
• Der erwartete WebAdmin-, Portal-, WAF- oder Maildienst funktioniert.
• Ein externer Test sieht nicht noch das Zertifikat eines vorgeschalteten Load Balancers oder Reverse Proxys.

Typische Fehler und nächste Prüfung

• Trusted bleibt leer: Intermediate-CA fehlt, falsche CA wurde importiert oder die Kette gehört nicht zum Serverzertifikat. Issuer und CA-Reihenfolge prüfen.
• Import wird abgelehnt: Dateiformat, Private-Key-Passwort, 30-Zeichen-Grenze, Zertifikat-Key-Paar und Systemzeit kontrollieren.
• Browser meldet falschen Namen: Aufgerufener FQDN oder IP-Adresse fehlt in den SANs. URL, DNS und Zertifikatsnamen vergleichen.
• Browser zeigt weiterhin das alte Zertifikat: Der Dienst nutzt noch die alte Zuweisung oder ein vorgeschalteter Proxy terminiert TLS. Mit openssl s_client und SNI direkt am erwarteten Ziel prüfen.
• WAF liefert das falsche Zertifikat: Hosted Address, Listen Port, Domain, SNI und Reihenfolge überlappender WAF-Regeln kontrollieren.
• Nur einzelne Clients warnen: Trust Store, Zwischenzertifikate, Systemzeit und mögliche Certificate-Pinning-Einschränkungen dieses Clients prüfen.
• Nach dem Wechsel ist ein Portal nicht erreichbar: Altes Zertifikat wieder auswählen und zuerst FQDN, Port, Device Access und Zertifikatskette getrennt prüfen.

FAQ