Sophos Firewall CA-Zertifikat für TLS Inspection verteilen

Wenn eine Sophos Firewall HTTPS-Verbindungen per TLS Inspection oder HTTPS Scanning entschlüsselt, erstellt die Firewall für die geprüfte Verbindung ein neues Zertifikat und signiert es mit einer lokalen CA. Clients müssen dieser CA vertrauen, sonst erscheinen Browserwarnungen oder Anwendungen brechen die Verbindung ab.

In Sophos Firewall ist dafür standardmässig die eingebaute CA SecurityAppliance_SSL_CA vorhanden. Diese CA kann unter Certificates > Certificate authorities heruntergeladen und auf verwalteten Clients verteilt werden. Wichtig ist aber nicht nur, dass irgendeine Sophos CA auf den Clients liegt. Die verteilte CA muss zu der CA passen, die in der TLS-Inspection-Konfiguration tatsächlich für das Re-Signing verwendet wird.

SecurityAppliance_SSL_CA ist nicht die eingebaute Default CA für lokal signierte Zertifikate. Wenn genau dieser andere Trust Anchor geplant rotiert werden muss, gilt der separate Ablauf Sophos Firewall Default CA kontrolliert erneuern. Beide CA-Objekte werden nicht auf Verdacht gemeinsam ersetzt.

Je nach Betriebsart prüft man diese Auswahl an unterschiedlichen Stellen: Bei DPI-basierten SSL/TLS Inspection Rules ist die CA unter Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings relevant. Ein der Rule zugewiesenes Decryption Profile kann diese globalen Werte übersteuern. Beim Web Proxy liegt die HTTPS-Scanning-CA unter Web > General settings > HTTPS decryption and scanning. Wenn im aktiven Pfad eine andere CA ausgewählt ist als jene, die auf den Clients vertraut wird, entstehen Zertifikatsfehler, obwohl grundsätzlich eine Sophos CA verteilt wurde.

Der Artikel Sophos Firewall TLS Inspection richtig einführen beschreibt den gesamten Rollout. Diese Anleitung konzentriert sich auf die Verteilung des CA-Zertifikats an Windows, macOS und Firefox.

Was dieses Zertifikat leistet

Das Sophos Firewall CA-Zertifikat ist kein Serverzertifikat für WebAdmin, WAF oder VPN Portal. Es ist die Vertrauensbasis, mit der Clients die von der Firewall neu signierten HTTPS-Verbindungen akzeptieren.

Wichtig ist die Trennung:

• Firewall CA: signiert während TLS Inspection neu erzeugte Zertifikate.
• Re-Signing CA oder HTTPS Scanning CA: die konkret ausgewählte CA, welche die Firewall in DPI-Modus oder Web-Proxy-Modus verwendet.
• Client Trust Store: entscheidet, ob Browser und Anwendungen dieser CA vertrauen.
• SSL/TLS Inspection Rule: entscheidet, welcher Traffic entschlüsselt wird.
• Decryption Profile: legt fest, wie streng Zertifikate, TLS-Versionen und Fehler behandelt werden.
• Exclusion List: verhindert Decryption für problematische oder bewusst ausgenommene Ziele.

Die CA-Verteilung allein aktiviert also keine TLS Inspection. Die Verteilung verhindert nur, dass verwaltete Clients bei entschlüsseltem HTTPS-Traffic Zertifikatswarnungen anzeigen. Ob Traffic tatsächlich entschlüsselt wird, hängt von Firewall-Regeln, Web Policy, SSL/TLS Inspection Rules, Decryption Profiles und Ausnahmen ab.

Ausserdem ersetzt die CA-Verteilung keine saubere Protokollsteuerung. SSL/TLS Inspection Rules greifen auf TCP-Traffic. Wenn Web-Traffic über QUIC beziehungsweise HTTP/3 auf UDP 443 läuft, sieht die Prüfung anders aus und muss separat behandelt werden.

Vor dem Rollout

Vor der Verteilung sollte klar sein, welche Clients TLS Inspection nutzen sollen. Ein CA-Zertifikat gehört nicht unkontrolliert auf jedes Gerät, sondern gezielt auf verwaltete Firmenclients.

Vorbereitung:

• Testgruppe oder Test-OU definieren.
• Betriebsart klären: DPI-Modus, Web Proxy oder beide Varianten.
• Gewählte CA in den SSL/TLS inspection settings, verwendeten Decryption Profiles und Web General settings dokumentieren.
• Rollback und Ausnahmeprozess dokumentieren.
• CA-Zertifikat nur aus der eigenen Firewall herunterladen.
• Verteilung zuerst auf wenigen Geräten testen.
• Browser, Business-Anwendungen und Updates nach der Verteilung prüfen.
• Mobile Geräte und Apps mit eigenem Trust Store oder Certificate Pinning separat bewerten.
• Alte oder nicht mehr verwendete CA-Zertifikate aus dem Client Trust Store entfernen.

⚠️ Achtung: Wenn die CA oder der private Schlüssel kompromittiert wurde, reicht eine Neuverteilung nicht. Dann muss die CA auf der Firewall regeneriert, neu verteilt und die alte CA aus den Clients entfernt werden.

Verteilungsweg wählen

Der richtige Verteilungsweg hängt davon ab, wie die Geräte verwaltet werden.

• Windows Domain Clients: GPO in Trusted Root Certification Authorities verwenden. Das ist der sauberste Weg für klassische Active-Directory-Umgebungen.
• Windows ohne Domäne: MDM, Intune oder lokaler Import verwenden. Lokaler Import eignet sich eher für Tests oder Einzelgeräte.
• macOS: MDM-Profil oder Schlüsselbund System verwenden. Manuelle Installation ist eher für Tests oder kleine Umgebungen geeignet.
• Firefox: Windows Trust Store verwenden oder Mozilla Enterprise Policies ausrollen. Das Firefox-Verhalten muss separat geprüft werden.
• BYOD oder private Geräte: normalerweise nicht verteilen. TLS Inspection gehört auf verwaltete Unternehmensgeräte.
• Server: nur bei bewusst geprüften Server-Workloads verteilen. Ausgehender Servertraffic kann andere Risiken und Ausnahmen haben.

Für den produktiven Betrieb ist entscheidend, dass der gleiche Rollout später auch wieder zurückgebaut werden kann. Wer die CA per GPO, MDM oder Policy verteilt, sollte deshalb auch den Entzug der alten CA testen.

Sophos Firewall CA herunterladen

Auf der Sophos Firewall wird das Zertifikat in der Weboberfläche heruntergeladen:

1. Als Administrator an der Sophos Firewall anmelden.
2. Certificates > Certificate authorities öffnen.
3. Die CA SecurityAppliance_SSL_CA oder die bewusst verwendete eigene CA suchen.
4. Über das Download-Symbol das Zertifikat herunterladen.
5. Anschliessend prüfen, ob dieselbe CA in der aktiven TLS-Inspection-Konfiguration ausgewählt ist.

Das Zertifikat liegt danach üblicherweise als SecurityAppliance_SSL_CA.pem vor. Diese Datei enthält den öffentlichen Teil der CA und kann an Clients verteilt werden. Der private Schlüssel darf nicht auf Clients verteilt werden.

Die Datei sollte wie ein sicherheitsrelevantes Konfigurationselement behandelt werden. Der öffentliche Teil ist kein Passwort, aber er definiert, welcher CA Clients künftig vertrauen. Deshalb sollte die Datei aus der eigenen produktiven Firewall stammen, versioniert oder zumindest nachvollziehbar abgelegt und nicht aus alten Projekten wiederverwendet werden.

Für die Kontrolle der aktiven CA gibt es zwei zusätzliche Pfade:

• DPI-Modus: Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings öffnen und die dort ausgewählte CA mit der heruntergeladenen Datei vergleichen. Verwendet die aktive Rule ein Decryption Profile, dessen Re-Signing-CA ebenfalls kontrollieren.
• Web Proxy: Web > General settings > HTTPS decryption and scanning öffnen und die HTTPS-Scanning-CA kontrollieren.

Diese Prüfung verhindert einen häufigen Rollout-Fehler: Auf den Clients wird die Standard-CA verteilt, während die Firewall in einem Decryption Profile oder im Web Proxy bereits eine andere CA verwendet.

Windows: Zertifikat per GPO verteilen

In Active-Directory-Umgebungen ist eine Gruppenrichtlinie der sauberste Weg. Edge, Chrome und viele Windows-Anwendungen vertrauen dem Windows-Zertifikatsspeicher.

Empfohlener Pfad in der Gruppenrichtlinienverwaltung:

Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities > Certificates

Vorgehen:

1. Gruppenrichtlinienverwaltung auf einem Domain Controller oder Admin-Client öffnen.
2. Bestehende GPO für Client-Baseline verwenden oder neue GPO für TLS-Inspection-Testgruppe erstellen.
3. Zum Pfad Trusted Root Certification Authorities > Certificates wechseln.
4. Rechtsklick in die Zertifikatsliste ausführen.
5. All Tasks > Import auswählen.
6. SecurityAppliance_SSL_CA.pem importieren.
7. GPO nur mit der gewünschten OU oder Sicherheitsgruppe verknüpfen.
8. Auf einem Testclient gpupdate /force ausführen oder auf die reguläre Aktualisierung warten.

Für produktive Umgebungen sollte die GPO nicht direkt auf alle Computer angewendet werden. Eine Test-OU reduziert das Risiko, wenn ein Zertifikat falsch importiert wurde oder eine Anwendung unerwartet reagiert.

Windows: Zertifikat lokal installieren

Für einzelne Testgeräte kann das Zertifikat lokal importiert werden. Dabei gibt es zwei sinnvolle Varianten:

• Local Computer Store: gilt für alle Benutzer auf dem Gerät und ist für verwaltete Clients meist richtig.
• Current User Store: gilt nur für den angemeldeten Benutzer und ist für Tests manchmal ausreichend.

Für den lokalen Computer:

1. Als lokaler Administrator anmelden.
2. certlm.msc starten.
3. Trusted Root Certification Authorities > Certificates öffnen.
4. Rechtsklick in die Zertifikatsliste ausführen.
5. All Tasks > Import auswählen.
6. SecurityAppliance_SSL_CA.pem importieren.

Für den aktuellen Benutzer kann alternativ certmgr.msc verwendet werden.

Nach dem Import sollten Browser und Anwendungen neu gestartet werden. Bei manchen Anwendungen ist eine Abmeldung oder ein Neustart des Clients sinnvoll.

macOS: Zertifikat im Schlüsselbund vertrauen

Auf macOS wird das Zertifikat über die Schlüsselbundverwaltung importiert.

Vorgehen:

1. SecurityAppliance_SSL_CA.pem auf den Mac kopieren.
2. Zertifikat per Doppelklick öffnen.
3. Im Schlüsselbund System oder einem verwalteten MDM-Profil bereitstellen.
4. Zertifikat öffnen und unter Trust den Eintrag Always Trust setzen.
5. Änderung mit einem Admin-Konto bestätigen.
6. Browser und betroffene Anwendungen neu starten.

In grösseren macOS-Umgebungen sollte die Verteilung über MDM erfolgen. Manuelle Installation ist eher für Tests oder Einzelgeräte geeignet.

Zertifikat auf verwalteten Geräten prüfen

Nach der Verteilung sollte man auf mindestens einem Testgerät pro Plattform prüfen, ob die CA wirklich im richtigen Trust Store gelandet ist.

• Windows Computer Store: certlm.msc öffnen und unter Trusted Root Certification Authorities > Certificates suchen.
• Windows Current User Store: certmgr.msc öffnen und den Benutzer-Trust-Store prüfen.
• macOS: Schlüsselbundverwaltung öffnen und im Schlüsselbund System den Trust-Status prüfen.
• Firefox: Settings > Privacy & Security > Certificates > View Certificates öffnen.

Wenn ein Zertifikat nur im Benutzer-Store liegt, eine Anwendung aber den Computer-Store erwartet, kann der Browser funktionieren und eine andere Anwendung trotzdem Zertifikatsfehler zeigen. Umgekehrt können Browser mit eigenem Trust Store die Windows- oder macOS-Verteilung ignorieren, wenn sie nicht entsprechend konfiguriert sind.

Firefox unter Windows

Aktuelle Firefox-Versionen durchsuchen unter Windows standardmässig den Zertifikatsspeicher des Betriebssystems nach zusätzlich installierten Root-CAs. Wenn die Sophos Firewall CA per GPO im Windows Computer Store liegt, ist deshalb normalerweise kein zweiter Import in eine eigene Firefox-Datenbank nötig. Das Verhalten wird in Firefox über Allow Firefox to automatically trust third-party root certificates you install, die Einstellung security.enterprise_roots.enabled oder die Enterprise Policy ImportEnterpriseRoots gesteuert.

In verwalteten Windows-Umgebungen gibt es damit zwei sinnvolle Wege:

• Windows Trust Store verwenden: empfohlener Standardweg, wenn die CA bereits per Computer-GPO verteilt wird. Die automatische Verwendung der Betriebssystem-CAs muss in der verwalteten Firefox-Konfiguration aktiv bleiben.
• Zertifikat direkt per Mozilla Enterprise Policy importieren: Alternative, wenn Firefox-Trust bewusst separat verwaltet wird oder der Betriebssystem-Trust-Store nicht verwendet werden soll.

Beim ersten Weg kann die aus Windows übernommene CA funktionieren, ohne in der Firefox-Zertifikatsverwaltung als separat importierter Eintrag zu erscheinen. Massgeblich sind dann der Windows Computer Store und ein realer HTTPS-Test. Die folgende GPO-Anleitung beschreibt den zweiten Weg mit Install Certificates.

Firefox-GPO-Vorlagen herunterladen

Mozilla stellt die Policy Templates auf GitHub bereit. Benötigt werden unter anderem:

• firefox.admx
• mozilla.admx
• firefox.adml
• mozilla.adml

Die Dateien können aus dem Mozilla Policy Templates Repository oder als policy_templates.zip heruntergeladen werden.

Vorlagen importieren

Die ADMX- und ADML-Dateien werden in den zentralen PolicyDefinitions-Pfad kopiert.

Typischer lokaler Pfad:

C:\Windows\PolicyDefinitions

Bei einem Central Store in der Domäne wird stattdessen der PolicyDefinitions-Ordner unter SYSVOL verwendet.

Firefox-Richtlinie konfigurieren

In der Gruppenrichtlinie wird das Zertifikat anschliessend unter den Firefox-Policies eingetragen:

Administrative Templates > Mozilla > Firefox > Certificates > Install Certificates

Vorgehen:

1. Richtlinie Install Certificates aktivieren.
2. Dateinamen des Zertifikats eintragen, zum Beispiel SecurityAppliance_SSL_CA.pem.
3. Zertifikatsdatei per GPO oder Softwareverteilung in das erwartete Benutzerprofil-Verzeichnis kopieren.

Je nach Firefox-Version und Policy-Konfiguration werden Zertifikate aus diesen Verzeichnissen gelesen:

%USERPROFILE%\AppData\Local\Mozilla\Certificates
%USERPROFILE%\AppData\Roaming\Mozilla\Certificates

Nach der nächsten Firefox-Sitzung sollte das Zertifikat in der Firefox-Zertifikatsverwaltung sichtbar sein.

Mozilla beschreibt den empfohlenen Betriebssystem-Trust und den Policy-Import unter Set up Certificate Authorities (CAs) in Firefox. Zusätzliche Pfade und Varianten stehen im Wiki: Add Root Certificate to Firefox.

Funktion prüfen

Nach der Verteilung sollte man nicht nur prüfen, ob das Zertifikat vorhanden ist. Entscheidend ist, ob TLS Inspection sauber funktioniert.

Sinnvolle Tests:

1. Testclient neu starten oder Benutzer neu anmelden.
2. Browser öffnen und eine HTTPS-Seite aufrufen, die von der Sophos Firewall entschlüsselt wird.
3. Im Browser das Zertifikat der Website anzeigen.
4. Prüfen, ob die Zertifikatskette über SecurityAppliance_SSL_CA oder exakt die gewählte Sophos CA läuft.
5. Auf der Firewall im Log Viewer > SSL/TLS inspection prüfen, ob der Traffic als entschlüsselt angezeigt wird und welche Rule beziehungsweise Aktion getroffen wurde.
6. Wichtige Business-Anwendungen, Update-Dienste, Collaboration-Tools und Identity-Provider testen.

Wenn der Browser weiterhin das ursprüngliche öffentliche Website-Zertifikat zeigt, wurde diese Verbindung nicht entschlüsselt. Dann greift entweder keine passende SSL/TLS Inspection Rule, eine Ausnahme gewinnt, der Traffic läuft über einen anderen Pfad oder QUIC/HTTP/3 umgeht den erwarteten TCP-Pfad.

Wenn die Browserwarnung verschwindet, aber Anwendungen weiterhin Fehler zeigen, liegt das Problem oft nicht am Zertifikat selbst. Häufig sind Certificate Pinning, fehlende TLS-Ausnahmen, ein falsches Decryption Profile oder eine ungeeignete SSL/TLS Inspection Rule die Ursache.

Für Web-Traffic sollte zusätzlich geprüft werden, ob QUIC beziehungsweise HTTP/3 die erwartete Inspection umgeht. Der Artikel Sophos Firewall QUIC und HTTP/3 richtig blockieren erklärt, warum Block QUIC protocol bei Webfiltering, Malware-Scanning und TLS Inspection relevant bleibt.

Typische Fehler

• Browser zeigt weiterhin Zertifikatswarnung: Die CA liegt vermutlich nicht im richtigen Trust Store. Windows-, macOS- oder Firefox-Zertifikatsspeicher prüfen.
• Chrome funktioniert, Firefox nicht: Prüfen, ob Firefox die zusätzlich installierten Root-CAs des Betriebssystems verwenden darf oder ob eine separate Mozilla Enterprise Policy greift. Danach Firefox neu starten und den realen HTTPS-Pfad testen.
• Einzelne Anwendungen brechen ab: Certificate Pinning oder eine eigene Zertifikatsprüfung ist wahrscheinlich. TLS Inspection Log Viewer und Ausnahmen prüfen.
• Nur manche Clients funktionieren: Die GPO greift nicht oder ist mit der falschen OU verknüpft. gpresult und GPO-Verknüpfung prüfen.
• CA ist installiert, aber Warnung bleibt: Die verteilte CA passt möglicherweise nicht zur CA im Decryption Profile, in den SSL/TLS inspection settings oder unter Web General settings.
• DPI funktioniert, Web Proxy nicht oder umgekehrt: Beide Pfade können unterschiedlich konfiguriert sein. Gewählte CA, Regelpfad und Log Viewer pro Betriebsart prüfen.
• Nach CA-Regeneration gibt es Warnungen: Die alte CA liegt noch auf Clients oder die neue CA fehlt. Alte CA entfernen und neue CA verteilen.
• URL-Feeds oder Webfilter greifen nicht wie erwartet: Der HTTPS-Pfad wird nicht entschlüsselt. TLS Inspection und Web-Policy prüfen.
• Zertifikat ist vorhanden, aber Traffic wird nicht entschlüsselt: Es fehlt eine passende SSL/TLS Inspection Rule oder der Traffic läuft über den falschen DPI-/Web-Proxy-Pfad. TLS-Rollout, Firewall-Regel und Log Viewer prüfen.
• Nur Mobile Apps oder einzelne Clients brechen ab: Eigener Trust Store, Certificate Pinning oder App-spezifische Prüfung ist wahrscheinlich. Besonders Android- und Mobile-App-Traffic sollte gezielt getestet und bei Bedarf ausgenommen werden, statt die CA breit und blind zu verteilen.

CA-Rotation und Notfall

Eine CA sollte nicht unbemerkt über Jahre betrieben werden, ohne dass Ablaufdatum, Herkunft und Verteilung bekannt sind. Für produktive Umgebungen sollte es einen kleinen Lifecycle-Prozess geben.

Geplanter Wechsel:

1. Neue CA oder neue Firewall-CA vorbereiten.
2. Neue CA an eine Testgruppe verteilen.
3. TLS Inspection mit Testgruppe prüfen.
4. Neue CA an alle betroffenen verwalteten Geräte verteilen.
5. Firewall-Regeln und Decryption Profiles kontrollieren.
6. Alte CA erst entfernen, wenn alle produktiven Geräte die neue CA erhalten haben.

Notfall bei Kompromittierung:

1. TLS Inspection bei Bedarf kontrolliert einschränken oder temporär deaktivieren.
2. Betroffene CA auf der Firewall ersetzen.
3. Neue CA über den definierten Verteilungsweg ausrollen.
4. Alte CA aus allen Trust Stores entfernen.
5. Ausnahmen, Log Viewer und betroffene Anwendungen nachprüfen.
6. Änderung im Incident- oder Change-System dokumentieren.

Wichtig: Eine kompromittierte CA ist kein normales Zertifikatsproblem. Wenn ein Angreifer den privaten Schlüssel kontrolliert, können Clients gefälschten Zertifikaten vertrauen. Dann muss die alte CA konsequent entfernt werden.

Betrieb und Pflege

Das CA-Zertifikat sollte Teil des Betriebsprozesses sein:

• Ablaufdatum und Verantwortliche dokumentieren.
• CA-Regeneration nur geplant durchführen.
• Alte CA nach Migration aus Clients entfernen.
• Verteilung über GPO oder MDM regelmässig prüfen.
• TLS-Ausnahmen dokumentieren und periodisch reviewen.
• Bei Geräteverlust oder CA-Kompromittierung die CA regenerieren.

Bei einer Änderung an TLS Inspection sollte man auch die betroffenen Firewall-Regeln, Decryption Profiles und Exclusion Lists prüfen. Sonst vertraut der Client zwar der CA, aber die Firewall entschlüsselt trotzdem nicht den gewünschten Traffic.

FAQ