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.

Eine Umgebung mit eigener Enterprise-PKI kann stattdessen eine dedizierte untergeordnete CA für Sophos Firewall TLS Inspection ausstellen. Dieser Weg behält den Signing-Key auf der Firewall und bindet den Trust an die bestehende Unternehmens-Root-CA, benötigt aber einen kontrollierten PKI- und Pilotprozess.

Neben der eingebauten CA kann man eine extern erzeugte Signing-CA importieren oder auf der Firewall eine Certificate Signing Request (CSR) erstellen und durch eine externe CA, etwa Active Directory Certificate Services, eine untergeordnete Signing-CA ausstellen lassen. Bei einer externen Signing-CA müssen sowohl die untergeordnete Signing-CA als auch ihre Root-CA auf der Firewall importiert sein. Die Clients benötigen den passenden öffentlichen Trust Anchor und die erforderliche öffentliche Kette, nicht den privaten Signing-Key. Der verlinkte PKI-Ablauf erklärt die Ausstellung; die folgenden Schritte erklären Auswahl, Verteilung und Kontrolle.

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

Web-Proxy-Regel und CA vorbereiten

Für einen Web-Proxy-Pilot unter Rules and policies > Firewall rules die passende Registerkarte IPv4 oder IPv6 wählen und über Add firewall rule > New firewall rule eine Regel anlegen. Beispielsweise TLS-CA-Pilot als frei wählbaren Namen verwenden, Source zones auf LAN, Source networks and devices auf das Pilotnetz, Destination zones auf WAN und Destination networks auf die vorgesehenen Ziele setzen. Zonen, Netze und Ziele an den tatsächlichen Pfad anpassen; nicht für einen Zertifikatstest pauschal alle Clients freigeben.

Vor Änderungen die bisherigen Regelwerte und die CA-Auswahl für den Rollback dokumentieren. Unter Web > General settings > HTTPS decryption and scanning separat die HTTPS scanning certificate authority (CA) prüfen und deren öffentlichen Teil zuerst auf allen betroffenen Pilotendgeräten verteilen und anhand des Fingerprints als vertrauenswürdig nachweisen. Die gemeinsame Web-Proxy-CA ist global: Ihr Wechsel ist kein CA-Pilot pro Regel, betrifft alle Web-Proxy-Clients und benötigt vorab deren Trust sowie ein Wartungsfenster.

Erst danach in der gewählten Firewall-Regel unter Security features > Web filtering die passende Web Policy wählen, Scan HTTP and decrypted HTTPS und Use web proxy instead of DPI engine sowie ausdrücklich Decrypt HTTPS during web proxy filtering aktivieren und mit Save speichern. Die Scan-Option allein entschlüsselt nicht; die CA-Auswahl unter Web > General settings ersetzt die Entschlüsselungsoption in der Firewall-Regel nicht.

Bei der Erstkonfiguration unter Certificates > Certificate authorities > Default prüfen, ob die Einstellungen der Default CA vollständig konfiguriert sind. Das ist eine Konfigurationskontrolle, kein Auftrag zur Regeneration und kein Grund, Default statt der tatsächlich verwendeten SecurityAppliance_SSL_CA zu verteilen.

Öffentlichen CA-Teil 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.

Für einen manuellen Pilot kann man die geprüfte öffentliche Datei über das Firmenintranet oder kontrolliert per E-Mail bereitstellen. Die Benutzer speichern sie lokal und gleichen ihre Identität mit den separat dokumentierten Zertifikatswerten ab, bevor sie Vertrauen erteilen. Für grössere Gruppen bleibt GPO oder MDM der bevorzugte Weg.

Unter SFOS 22 kann man die tatsächlich ausgewählte CA auch direkt am Einsatzort herunterladen. Im DPI-Pfad steht das Download-Symbol neben Re-sign RSA with und Re-sign EC with. Sind dort zwei verschiedene CAs gewählt, müssen beide auf den betroffenen Clients vertrauenswürdig sein. Im Web-Proxy-Pfad steht das Symbol neben HTTPS scanning certificate authority (CA). Dieser Download am Einsatzort reduziert das Risiko, versehentlich ein gleichnamiges, aber nicht verwendetes CA-Objekt zu verteilen.

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. Vor der Verteilung werden Subject, Issuer, Seriennummer, Gültigkeitszeitraum und Fingerprint aus der Zertifikatsanzeige dokumentiert. Nach dem Import vergleicht man diese Werte auf mindestens einem Pilotclient; der Anzeigename allein ist kein sicherer Identitätsnachweis.

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 mit der gewünschten Test-OU verknüpfen. Eine Sicherheitsgruppe bei Bedarf über die Sicherheitsfilterung verwenden, nicht als GPO-Verknüpfungsziel.
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.

Für einen einzelnen Benutzer ist auch der Schlüsselbund login möglich: Die heruntergeladene Datei per Doppelklick in Keychain Access öffnen, Identität prüfen und Always Trust setzen. Safari nutzt diesen macOS-Trust ebenfalls. Für den verwalteten geräteweiten Rollout bleibt System oder MDM sinnvoll; Benutzer- und System-Scope nicht verwechseln.

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.

Mobile Geräte mit Sophos Mobile

⚠️ Android: Installation ist keine Freigabe zur Entschlüsselung. Die Sophos-Anleitungen beschreiben den CA-Import, empfehlen für DPI wegen Zertifikatsfehlern aber zugleich, alle Android-Geräte von SSL/TLS Inspection auszunehmen. Daher gilt hier standardmässig die DPI-Ausnahme für alle Android-Geräte. Die folgenden Android-Import- und HTTPS-Testschritte gelten nur für einen separat genehmigten, eng begrenzten Pilot auf verwalteten Geräten: Ein dokumentierter betrieblicher Bedarf muss die Abweichung für benannte Geräte und Anwendungen rechtfertigen. Vor der Freigabe den tatsächlich verwendeten Trust Store und jede betroffene Anwendung prüfen; bei Fehlern den Pilot zurückbauen und die Ausnahme wiederherstellen. MDM-Installation behebt weder Certificate Pinning noch das Vertrauen aller Apps. Die DPI-Empfehlung ist keine pauschale Aussage zur Web-Proxy-Kompatibilität; auch dort ist eine separate Anwendungsprüfung nötig.

Manueller Mobile-Pilot

Wenn das Gerät die PEM-Datei nicht akzeptiert, kann eine Umwandlung in ein kompatibles Zertifikatsformat wie .der, .cer oder .crt nötig sein. Eine Dateiendung allein bestimmt nicht die Kodierung; keine Private-Key-Datei verwenden. Menübezeichnungen hängen von Android-Version und Hersteller ab. Ein Pixel-Beispiel verwendet Settings > Security & location > Advanced > Encryption & credentials:

1. Unter Credential storage Install from storage oder Install from SD card wählen.
2. Im Dateidialog über Menu > Open from den Speicherort wählen und die öffentliche Zertifikatsdatei öffnen.
3. Geräte-PIN eingeben, einen eindeutigen Zertifikatsnamen vergeben und für diesen App-Pilot VPN and apps wählen; Wi-Fi ist die separate angebotene Kategorie. Mit OK bestätigen.
4. Unter User credentials Identität und Import prüfen, danach den entschlüsselten HTTPS-Aufruf testen. Ein erfolgreicher Import garantiert nicht, dass jede Android-App dem Benutzer-Trust-Store vertraut.

Für einen manuellen iOS-Pilot die öffentliche CA-Datei auf dem Gerät bereitstellen und importieren. Danach unter Settings > General > About > Certificate Trust Settings > Enable full trust for root certificates nur dem identifizierten Root-Zertifikat Vertrauen erteilen und HTTPS testen. Nicht mehrere unbekannte Root-CAs aktivieren.

Zentral über die Geräterichtlinie verteilen

Für eine grössere Zahl verwalteter Android-, iOS- und iPadOS-Geräte sollte die CA über eine MDM-Policy verteilt werden. Sophos Mobile kann das Root-Zertifikat direkt in die bereits zugewiesene Geräterichtlinie aufnehmen. Apple empfiehlt dafür MDM oder Apple Configurator; bei Apple Configurator wird zuerst auf macOS ein Konfigurationsprofil erstellt. Danach können ein oder mehrere iOS-Geräte mit dem Mac verbunden werden, um das Profil mit dem CA-Zertifikat zu installieren.

Root-Zertifikate, die auf iOS- und iPadOS-Geräten über MDM oder Apple Configurator installiert werden, werden automatisch als vertrauenswürdig behandelt. Das unterscheidet sich vom manuellen Import; die nachfolgende Trust-Kontrolle ist kein Auftrag, eine bereits aktive Einstellung erneut zu ändern.

Beispiel für iOS und iPadOS in Sophos Mobile:

1. Policies > iOS & iPadOS öffnen.
2. Die Policy auswählen, die den vorgesehenen Geräten bereits zugewiesen ist.
3. Auf der Seite Edit policy Add > Root certificate wählen.
4. Unter Root certificate mit Upload a file ausschliesslich das öffentliche CA-Zertifikat hochladen, dem die Geräte gemäss der geplanten Kette vertrauen müssen. Bei SecurityAppliance_SSL_CA ist dies der von SFOS heruntergeladene öffentliche CA-Teil.
5. Mit Apply und anschliessend Save speichern.
6. In der Policy-Liste über den Pfeil Update devices auslösen. Fehlt diese Option, wird die Änderung bei der nächsten automatischen Synchronisierung verteilt.

Für Android wird das Root-Zertifikat entsprechend in einer Android-Policy hinzugefügt. Danach nicht nur den Policy-Status prüfen: Unter iOS liegt die Kontrolle unter Settings > General > About > Certificate Trust Settings; unter Android unter Settings > Security > Advanced > Encryption & credentials > User credentials. Ein echter entschlüsselter HTTPS-Aufruf bleibt der abschliessende Nachweis.

Unter iOS prüft man dort den Trust-Status des vorgesehenen Root-Zertifikats, dessen Identität zuvor mit dem dokumentierten Fingerprint abgeglichen wurde. Ist das Vertrauen noch deaktiviert, aktiviert man unter Enable full trust for root certificates ausschliesslich das Vertrauen für dieses Root-Zertifikat. Ist es bereits vertrauenswürdig, bleibt die Einstellung unverändert; danach den entschlüsselten HTTPS-Aufruf erneut prüfen.

Der Private Key der Re-Signing-CA gehört niemals in Sophos Mobile oder auf ein Endgerät. Verteilt wird ausschliesslich das öffentliche CA-Zertifikat. Zuerst eine kleine Pilotgruppe verwenden und den Entzug der CA ebenfalls testen.

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

Für ein einzelnes Testprofil ist auch ein manueller Import möglich: Settings > Privacy & Security > Certificates > View Certificates > Authorities > Import öffnen, die öffentliche CA-Datei auswählen und mit Open bestätigen. Im Dialog Downloading Certificate nur Trust this CA to identify websites für die zuvor geprüfte CA aktivieren und OK wählen. Danach Firefox neu starten und den entschlüsselten HTTPS-Pfad prüfen. Dieser Profilimport ersetzt keine zentrale Verteilung.

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

firefox.admx und mozilla.admx werden direkt in den gewählten PolicyDefinitions-Ordner kopiert. Die zugehörigen firefox.adml und mozilla.adml gehören dagegen in dessen sprachspezifischen Unterordner, nicht neben die ADMX-Dateien.

Typischer lokaler Pfad:

C:\Windows\PolicyDefinitions

Bei einem Central Store in der Domäne verwendet man stattdessen \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions. Beide Vorkommen von <domain> durch den DNS-Namen der eigenen AD-Domäne ersetzen. Existiert ein Central Store, müssen die Mozilla-Vorlagen dort bereitgestellt werden; eine Kopie nur im lokalen Ordner genügt für die Domänen-GPO nicht.

Die Sprachordner des heruntergeladenen Pakets beibehalten und ADMX sowie ADML aus derselben Vorlagenversion verwenden. Beispielsweise kommen die englischen ADML-Dateien nach C:\Windows\PolicyDefinitions\en-US oder, bei Verwendung des Central Store, nach \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions\en-US. Weitere benötigte Sprachen in ihren jeweiligen Paket-Unterordner kopieren. en-US ist ein Beispiel für die Vorlagensprache, keine Vorgabe für die Sprache dieses Artikels.

Den Gruppenrichtlinieneditor erneut öffnen und prüfen, ob Administrative Templates > Mozilla > Firefox > Certificates > Install Certificates ohne Ressourcenfehler sichtbar ist. Fehlt die Richtlinie, zuerst Zielordner, Sprachunterordner und Versionszuordnung korrigieren; erst danach mit der Zertifikatsrichtlinie fortfahren.

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.

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. Den neuen Aufruf auf der Firewall anhand von Quelle, Ziel und Zeitpunkt dem tatsächlichen Betriebsmodus zuordnen und nach dem folgenden Prüfweg kontrollieren.
6. Wichtige Business-Anwendungen, Update-Dienste, Collaboration-Tools und Identity-Provider testen.

DPI: Unter Rules and policies > SSL/TLS inspection rules die passende Inspection Rule, deren Aktion, Decryption Profile und Re-Signing-CA prüfen. In Log Viewer > SSL/TLS inspection den gleichen neuen Aufruf mit Quelle, Ziel und Zeitpunkt korrelieren und Entschlüsselung sowie angewendete Regel/Aktion prüfen. DPI-Ausnahmen ebenfalls berücksichtigen.

Web Proxy: Die tatsächlich passende Firewall-Regel, ihre Web Policy und Decrypt HTTPS during web proxy filtering prüfen. Die gemeinsame HTTPS scanning certificate authority (CA) unter Web > General settings und passende Ausnahmen unter Web > Exceptions kontrollieren. In Log Viewer die relevanten Webfilter-/Proxy-Protokolle für denselben neuen Aufruf mit Quelle, Ziel und Zeitpunkt abgleichen; die Browser-Zertifikatskette und der Issuer müssen zur gewählten CA passen. SSL/TLS Inspection Rules steuern die Web-Proxy-Entschlüsselung nicht. Ein DPI-Entschlüsselungseintrag ist dafür weder zugesichert noch Voraussetzung; ein Webfilter-Eintrag allein beweist keine Entschlüsselung.

Wenn der Browser weiterhin das ursprüngliche öffentliche Website-Zertifikat zeigt, wurde diese Verbindung nicht entschlüsselt. Im DPI-Modus die Inspection Rule und deren Ausnahmen prüfen; beim Web Proxy die passende Firewall-Regel, Entschlüsselungsoption und Web-Ausnahmen prüfen. Auch ein anderer Traffic-Pfad oder QUIC/HTTP/3 kann den erwarteten TCP-Pfad umgehen.

Wenn die Browserwarnung verschwindet, aber Anwendungen weiterhin Fehler zeigen, liegt das Problem oft nicht am Zertifikat selbst. Certificate Pinning oder ein eigener Trust Store sind mögliche Ursachen. Im DPI-Modus zusätzlich Decryption Profile, Inspection Rule und TLS-Ausnahmen prüfen; beim Web Proxy die Firewall-Regel und Web-Ausnahmen nach dem obigen Prüfweg kontrollieren.

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. Bei DPI SSL/TLS-Logs und TLS-Ausnahmen prüfen; beim Web Proxy Webfilter-/Proxy-Logs und Web > Exceptions prüfen, jeweils für denselben Aufruf.
• 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: Den oben beschriebenen Prüfweg für den tatsächlichen Modus verwenden: bei DPI Inspection Rule, Profil und SSL/TLS-Logs; beim Web Proxy Firewall-Regel, Entschlüsselungsoption, gemeinsame CA, Web-Ausnahmen und Webfilter-/Proxy-Logs.
• Nach CA-Regeneration gibt es Warnungen: Die neue aktive CA fehlt möglicherweise auf Clients. Zuerst die neue öffentliche CA verteilen und anhand des Fingerprints prüfen. Eine alte, nicht kompromittierte CA erst entfernen, wenn kein aktiver Pfad sie mehr verwendet; bei Kompromittierung gilt der Notfallablauf.
• 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: Bei DPI kann eine passende Inspection Rule fehlen; beim Web Proxy kann die Entschlüsselungsoption der Firewall-Regel fehlen oder eine Web-Ausnahme greifen. Den modusspezifischen Prüfweg oben verwenden und den tatsächlichen Traffic-Pfad kontrollieren.
• Nur Mobile Apps oder einzelne Clients brechen ab: Eigenen Trust Store, Certificate Pinning und App-spezifische Prüfung berücksichtigen. Android-Geräte standardmässig von DPI ausnehmen; ein separat genehmigter Android-Pilot muss bei Fehlern zur Ausnahme zurückkehren. Andere Ausnahmen gezielt statt globaler Abschaltung prüfen.

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.

Die eingebaute SecurityAppliance_SSL_CA lässt sich regenerieren. Das ist jedoch kein risikoloser Vorbereitungsschritt: Die bisherige CA und die neue CA sind danach nicht automatisch parallel auf allen Clients vertrauenswürdig. Für einen geplanten DPI-Wechsel mit Überlappung verwendet man eine separat vorbereitete Signing-CA und testet sie über ein eng begrenztes Decryption Profile. Beim Web Proxy gibt es dagegen nur die globale HTTPS scanning certificate authority (CA). Deren Wechsel wirkt auf den gesamten Web-Proxy-Pfad und gehört deshalb in ein Wartungsfenster; vorher muss die neue öffentliche CA auf allen betroffenen Clients vertrauenswürdig sein. Der Private Key bleibt in beiden Fällen auf der Firewall.

Geplanter Wechsel:

1. Aktive CA-Auswahl, Fingerprints und alle Referenzen dokumentieren; eine neue separate Signing-CA vorbereiten, ohne die eingebaute CA als ersten Schritt zu regenerieren.
2. Nur das öffentliche Zertifikat beziehungsweise die benötigte öffentliche CA-Kette verteilen: für einen DPI-Pilot zuerst an die Testgruppe, vor einem globalen Web-Proxy-Wechsel an alle betroffenen Clients.
3. Im DPI-Modus die neue CA über ein eng begrenztes Decryption Profile aktivieren und Issuer, Log-Eintrag sowie Anwendungen der Testgruppe prüfen.
4. Nach bestandenem DPI-Pilot das öffentliche Zertifikat an alle betroffenen verwalteten Geräte verteilen und den erfolgreichen Import anhand des Fingerprints nachweisen.
5. Die verbleibenden DPI-Felder beziehungsweise die globale Web-Proxy-CA umstellen. Mit neuen Verbindungen kontrollieren, dass die neue CA signiert und die erwartete Rule greift.
6. Die alte CA erst aus Client Trust Stores entfernen, wenn kein Inspection-Pfad mehr auf sie verweist und alle betroffenen 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.

Beim normalen Rollback wird zuerst der Inspection-Pfad auf die zuvor dokumentierte CA zurückgestellt oder die Pilotregel deaktiviert. Erst nachdem eine neue Verbindung wieder den alten Issuer beziehungsweise den ursprünglichen, nicht entschlüsselten Pfad zeigt, entfernt man die nur für den Pilot verteilte CA. Wer zuerst den Client-Trust entzieht, während die Firewall weiterhin mit dieser CA neu signiert, erzeugt selbst Zertifikatsfehler. Gemeinsam genutzte oder noch referenzierte CAs werden nicht gelöscht.

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 Verdacht auf Kompromittierung des Signing-Private-Keys oder der Firewall den Incident- und CA-Wechselprozess auslösen. Der Verlust eines Clients, auf dem nur das öffentliche CA-Zertifikat liegt, kompromittiert den Signing-Key nicht.

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