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.
• DigiCert oder andere öffentliche CA automatisieren: Ausstellung, XML-API-Upload, Dienstzuweisung und externen Listener-Test verbindet Sophos Firewall Zertifikat per XML API erneuern und Dienste prüfen zu einem kontrollierten End-to-End-Ablauf.
• 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.

Informationen und Aktionen in der Zertifikatsliste

Unter Certificates > Certificates zeigt SFOS beim Bewegen des Mauszeigers über einen Zertifikatsnamen Subject, Issuer und Purpose an. Über die Aktionen lässt sich das Zertifikat kopieren oder als .crt-Datei herunterladen; die heruntergeladene Datei enthält keinen Private Key. Regenerate steht nur für das eingebaute ApplianceCertificate zur Verfügung. Lokal signierte Zertifikate lassen sich direkt sperren; SFOS nimmt sie automatisch in die Default CRL auf. Der kontrollierte Sperrablauf steht unter Certificate Revocation Lists auf Sophos Firewall.

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.

Auch der verschlüsselte POP3- und IMAP-Abruf besitzt eine eigene TLS-Zuweisung unter Email > General settings. Wie Mailserver-CA, Zertifikatsprüfung, Scanoption und Firewall-Regel zusammenwirken, zeigt POP3 und IMAP auf Sophos Firewall scannen und testen.

Soll die Firewall dafür in die eigene Unternehmens-PKI eingebunden werden, beschreibt Untergeordnete CA für Sophos Firewall TLS Inspection einrichten den CSR-, AD-CS-, EKU- und Importablauf für eine dedizierte Re-Signing-CA.

Die eingebaute Default CA ist wiederum der Trust Anchor für lokal signierte Zertifikate. Ihre Einstellungen zu speichern regeneriert die CA und kann Portale, SSL VPN, IPsec-Peers und vertrauende Clients betreffen. Der sichere Change-Ablauf steht unter Sophos Firewall Default CA kontrolliert erneuern.

Laufzeit und Vertrauenskette reichen nicht aus, wenn ein Zertifikat vorzeitig gesperrt wurde. Wie lokale und externe Certificate Revocation Lists auf Sophos Firewall importiert, aktualisiert und geprüft werden, erklärt der eigene CRL-Ablauf.

Im FIPS-140-3-Modus validiert SFOS neu erzeugte und importierte Zertifikate zusätzlich gegen die zulässigen Schlüssel- und Digest-Verfahren. Die Aktivierung dieses Modus ist eine eigene Factory-Reset-Migration und kein normaler Zertifikatswechsel.

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.

Lokal signiertes Zertifikat erzeugen

Für einen internen Dienst kann SFOS ein Zertifikat direkt mit der eingebauten Default CA signieren. Das ist nur dann ein sauberer Weg, wenn die zugreifenden Geräte dieser CA bereits vertrauen oder das öffentliche CA-Zertifikat kontrolliert erhalten. Für öffentlich erreichbare Dienste bleibt normalerweise ein Zertifikat einer öffentlichen CA die bessere Wahl.

Unter Certificates > Certificates > Add wird Generate locally-signed certificate gewählt. Danach werden ein eindeutiger Name und der gewünschte Gültigkeitszeitraum festgelegt; SFOS schlägt standardmässig ein Jahr vor. Key type (RSA oder Elliptic curve), Schlüssellänge beziehungsweise Kurve und Secure hash müssen zur eigenen Kryptografie-Vorgabe und zu den Clients passen.

Beim Subject ist der Common name Pflicht. Country name, State, Locality name, Organization name, Organization unit name und Kontakt-E-Mail übernimmt SFOS zunächst aus den Lizenzdaten; alle Werte werden vor dem Speichern auf die tatsächliche Organisation und den vorgesehenen Zweck geprüft. Unter Subject Alternative Names werden alle verwendeten DNS-Namen sowie nötigen IPv4- oder IPv6-Adressen eingetragen.

Mindestens ein SAN oder eine Certificate ID ist erforderlich. Die Certificate ID unter Advanced settings ist nur für Kompatibilität mit älteren SFOS-Versionen vorgesehen und ersetzt bei modernen HTTPS-Clients keine korrekte SAN-Liste. Nach Save werden Issuer Default, Laufzeit, SANs und die spätere Dienstzuweisung kontrolliert.

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

Die weiteren Subject-Felder und die Kontakt-E-Mail werden ebenfalls kontrolliert. SFOS kann sie aus den Lizenzdaten vorbelegen, sie gehören aber zum konkreten Zertifikatsantrag und dürfen nicht ungeprüft übernommen werden.

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. Den Zweck passend zum ausgestellten Objekt wählen:
   • Certificate only: Das ausgestellte Server- oder Clientzertifikat wird unter Certificates > Certificates gespeichert.
   • Certificate authority only: Diese Option gilt für eine auf Basis des CSR ausgestellte CA, beispielsweise eine untergeordnete CA. Sie erscheint danach unter Certificates > Certificate authorities.
   • Certificate and certificate authority: Der Upload enthält sowohl das ausgestellte Zertifikat als auch dessen Root- oder untergeordnete CA.
5. Import certificate ausführen.

Bei einem CA-Import verwendet SFOS zunächst den Common Name als CA-Namen; er lässt sich vor dem Import ändern. Das aus dem CSR ausgestellte Zertifikat beziehungsweise CA-Zertifikat verknüpft SFOS mit dem zugehörigen, auf der Firewall gespeicherten Private Key. Danach entfernt SFOS den CSR-Eintrag. Deshalb vor dem Import sorgfältig prüfen, dass 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.

Beim direkten CA-Upload erkennt SFOS das X.509-Dateiformat automatisch; unterstützt werden .pem, .der und .cer. Passt die CA zu einem auf der Firewall erzeugten CSR, übernimmt SFOS den CSR-Namen und setzt den Zweck auf Signing and validation, weil der zugehörige Private Key bereits auf der Firewall liegt. Danach das Private-Key-Symbol kontrollieren. Der Einsatz als Re-Signing-CA gehört zum getrennten Ablauf für die untergeordnete TLS-Inspection-CA.

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.

Externe Signing-CA ohne passenden Firewall-CSR importieren

Dieser Ablauf ist für eine extern erzeugte Intermediate-CA vorgesehen, mit der die Firewall selbst signieren soll, nicht für das Serverzertifikat oder eine reine Vertrauenskette. Dafür müssen das CA-Zertifikat und der eigene Private Key dieser CA als geprüftes Paar vorliegen. Den Root-CA-Schlüssel nicht auf die Firewall übertragen. Ein Firewall-CSR bleibt der bevorzugte Weg, weil dann kein Schlüsseltransport nötig ist.

Enthält die Signing-CA Extended Key Usage (EKU), muss darin TLS Web Server Authentication enthalten sein. Eine bereits für Re-Signing verwendete CA nicht auf Validation only umstellen: Sonst fehlt ihr die benötigte Signing-Funktion für die erneute Verschlüsselung des entschlüsselten SSL/TLS-Verkehrs. Vor der Änderung Backup, bisherige CA-Auswahl und Abhängigkeiten sichern.

1. Certificates > Certificate authorities öffnen und Add wählen, nicht die Serverzertifikatsliste.
2. Das Intermediate-CA-Zertifikat hochladen oder dessen Zertifikatstext einfügen. SFOS erkennt .pem, .der und .cer automatisch.
3. SFOS prüft auf einen passenden Firewall-CSR. Bei einem Treffer werden dessen Name und Signing and validation übernommen; der Private Key liegt bereits auf der Firewall. Den vorgeschlagenen Namen bei Bedarf ändern und Save wählen. Kein zusätzlicher Key-Upload ist nötig.
4. Ohne passenden CSR erscheinen zusätzliche Optionen. Unter Use certificate for für diese Signing-CA Signing and validation wählen.
5. Den zu dieser Intermediate-CA gehörenden Private key hochladen, nicht den Private Key des Serverzertifikats. Das Schlüsselpasswort zur Verschlüsselung eingeben; es darf höchstens 30 Zeichen enthalten. Für den Transfer einen geschützten Schlüssel und ein starkes Passwort innerhalb dieser Grenze verwenden.
6. Einen eindeutigen CA-Namen eingeben beziehungsweise den vorgeschlagenen Namen ändern, dann Save wählen.
7. Die zugehörige Root-CA separat über Certificates > Certificate authorities > Add hochladen oder einfügen, Use certificate for auf Validation only setzen und mit Save speichern. Sie validiert die Intermediate-CA und benötigt dafür keinen Private Key.
8. Unter Certificates > Certificates den grünen Haken in Trusted beim importierten Serverzertifikat prüfen. Danach unter Certificates > Certificate authorities den Filter neben Type öffnen, Uploaded wählen und Apply ausführen. Bei der Intermediate-/untergeordneten CA muss das Private-Key-Symbol erscheinen; es bestätigt den vorhandenen Signing-Key, nicht bereits einen erfolgreichen Verkehrstest.

Fehlt Trusted, Aussteller und vollständige Kette prüfen; fehlt das Schlüsselsymbol, CA-Key-Paar, Import und Passwort prüfen, bevor die CA zugewiesen wird. Der Import allein stellt noch keine TLS-Inspection-Auswahl um. Unternehmens-CSR/AD CS sowie Verkehrsauswahl und Pilotprüfung bleiben im verlinkten Ablauf für die untergeordnete TLS-Inspection-CA. Beim späteren Wechsel die bisherige CA-Auswahl als Rückweg erhalten; neue CA-Einträge erst entfernen, wenn keine Abhängigkeiten bestehen. Ein Rückwechsel nimmt einen bereits erfolgten Schlüsseltransfer nicht zurück: Importdateien aus unsicheren Zwischenablagen entfernen, geschützte Wiederherstellungskopien gemäss PKI-Vorgabe aufbewahren.

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

Beim Upgrade auf SFOS 21 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 21 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. Der sichere Ablauf für Paket, SSMK und Reimport steht unter Konfiguration selektiv exportieren und importieren. 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 Zuweisungsziel zuweisen. Die WebAdmin-/Portal-Gruppe wird dabei gemeinsam umgestellt; WAF-Regeln und SMTP lassen sich einzeln ändern.
5. Alle von diesem Zuweisungsziel betroffenen Dienste über ihre echten FQDNs und Ports testen.
6. Bei Fehlern sofort wieder das alte Zertifikat auswählen.
7. Weitere Zuweisungsziele 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.

Der vollständige Ablauf für Portal-FQDN, Passwortregistrierung, Reply Portal und Mailflow steht unter SPX E-Mail-Verschlüsselung einrichten und testen.

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.

Für eine rein interne Administration kann SFOS den WebAdmin-Namen auch mit einem lokal signierten Zertifikat absichern. Unter Certificates > Certificates > Add die Aktion Generate locally-signed certificate wählen und bei Common name sowie DNS names exakt den intern auflösbaren Firewall-Hostnamen eintragen, zum Beispiel fw01.example.com. Danach unter Administration > Admin and user settings denselben Wert als Hostname setzen, das neue Certificate auswählen und Use the firewall’s configured hostname aktivieren.

Damit der Browser diesem Zertifikat vertraut, unter Certificates > Certificate authorities das öffentliche Zertifikat der CA Default herunterladen, das Archiv entpacken und Default.der beziehungsweise Default.pem als Default.crt an die verwalteten Endgeräte verteilen. Der sichere Verteil- und Kontrollablauf für Windows, macOS und Firefox steht unter Sophos Firewall CA-Zertifikat für TLS Inspection verteilen. Verteilt wird nur das öffentliche CA-Zertifikat, niemals ein Private Key.

⚠️ Dieser Weg beseitigt die Browserwarnung nur auf verwalteten Geräten, die der Default CA vertrauen. Er macht das Zertifikat nicht öffentlich vertrauenswürdig. Wird die Default CA später regeneriert, müssen Zertifikate und Trust-Verteilung kontrolliert erneuert 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.

Wie CA, Certificate ID, Local Certificate und Remote Certificate für zwei Firewalls zusammenspielen, erklärt IPsec Site-to-Site mit Zertifikaten einrichten.

WebAdmin-Zertifikat über die Konsole auf Default zurücksetzen

Ist der WebAdmin nach einer fehlerhaften Zertifikatszuweisung nicht mehr nutzbar, kann ein funktionierender Device-Console-Zugang als Break-Glass-Weg dienen. Vorher werden der verwendete FQDN, die bisherige Zertifikatszuweisung und der erwartete Fingerprint dokumentiert. Eine noch offene Admin-Sitzung bleibt bestehen.

In der Device Console 2. System Configuration > 4. Reset Default Web Admin Certificate öffnen und den Reset mit y bestätigen. SFOS setzt damit das Zertifikat der WebAdmin-Konsole auf das Default-Gerätezertifikat zurück. Der Vorgang stellt weder das zuvor ausgewählte Zertifikat noch einen alten Private Key der Default CA wieder her und regeneriert die CA nicht. Die ausgelieferte Default CA gehört auch zur HTTPS-Kette für Web-Proxy-Block- und Warnseiten; Option 4 ist jedoch kein Reset dieser Proxy-Funktion. Eine Browserwarnung oder ein Namensfehler kann mit dem lokal signierten Default-Zertifikat erwartet werden.

Nach der Erfolgsmeldung den WebAdmin ausschliesslich über den vorgesehenen Managementpfad neu öffnen, das tatsächlich präsentierte Zertifikat kontrollieren und eine frische Anmeldung testen. Da WebAdmin und mehrere Portale dieselbe Zertifikatsauswahl verwenden, werden die betriebenen Portale ebenfalls geprüft. Danach kann unter Administration > Admin and user settings ein repariertes produktives Zertifikat wieder kontrolliert zugewiesen werden. Der Console-Reset ist ein Recovery-Weg, keine dauerhafte Lösung für öffentliches Vertrauen.

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

Unter Email > General settings > SMTP TLS configuration verwendet TLS certificate je nach Konfiguration ein CA- oder Serverzertifikat für das Scannen von SMTP-Verbindungen über TLS. Vor einem Wechsel deshalb den bisherigen Zweck, die Zertifikatsprüfung und die betroffenen eingehenden und ausgehenden Verbindungen dokumentieren. Präsentiert die Firewall bei öffentlicher SMTP-Kommunikation selbst eine Serveridentität, empfiehlt sich dafür ein Zertifikat einer öffentlichen CA. Nach Apply beide Verkehrsrichtungen mit den tatsächlich verwendeten TLS-Modi testen. 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.

Bei einem extern erzeugten Zertifikat muss der aus dem Private Key abgeleitete öffentliche Schlüssel mit dem öffentlichen Schlüssel des Zertifikats übereinstimmen:

(
tmpdir=$(mktemp -d)
trap 'rm -rf -- "$tmpdir"' EXIT
openssl x509 -in firewall.pem -pubkey -noout > "$tmpdir/cert-public-key.pem" &&
  openssl pkey -in firewall.key -pubout > "$tmpdir/key-public-key.pem" &&
  cmp "$tmpdir/cert-public-key.pem" "$tmpdir/key-public-key.pem"
)

firewall.key wird durch den lokalen Pfad zum Private Key ersetzt. Bei einem verschlüsselten Schlüssel fragt openssl pkey interaktiv nach dem Passwort. cmp bleibt bei identischen öffentlichen Schlüsseln ohne Ausgabe; andernfalls darf das Paar nicht importiert werden. Die temporären Dateien enthalten nur öffentliche Schlüssel, werden nach dem Vergleich aber trotzdem entfernt. Den Private Key niemals ausgeben, hochladen oder an ein Ticket anhängen.

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 -showcerts -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. -showcerts zeigt alle vom Dienst gesendeten Zertifikate; die Root-CA muss der Server normalerweise nicht mitsenden. Das erwartete Serverzertifikat und die für die Kettenbildung benötigten Intermediate-CAs müssen in dieser Ausgabe erscheinen. Verification: OK bestätigt zusätzlich die Hostnamen- und Kettenprüfung gegen den Trust Store des Testrechners. Ein dort bereits vorhandenes Intermediate kann jedoch eine unvollständige Serverauslieferung verdecken.

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