Untergeordnete CA für Sophos Firewall TLS Inspection einrichten

Für TLS Inspection muss die Sophos Firewall Zertifikate für besuchte HTTPS-Ziele neu signieren. Statt dafür die eingebaute SecurityAppliance_SSL_CA zu verwenden, kann eine dedizierte untergeordnete Unternehmens-CA eingesetzt werden. Verwaltete Clients vertrauen dann weiterhin der eigenen Root-CA, während der Private Key der Subordinate CA auf der Firewall bleibt.

Der sichere Ablauf besteht aus sechs Schritten:

1. Auf der Sophos Firewall einen CSR für die neue Subordinate CA erzeugen.
2. Den CSR über eine Microsoft AD CS Enterprise CA mit der Vorlage Subordinate Certification Authority signieren.
3. Das ausgestellte CA-Zertifikat direkt beim vorhandenen CSR importieren.
4. Die zugehörige Root-CA auf der Firewall als Validation only hinterlegen.
5. Die Subordinate CA als Re-Signing-CA auswählen und zunächst nur in einer Pilotregel verwenden.
6. Zertifikatskette, echten HTTPS-Verkehr, Logs und Rollback prüfen.

⚠️ Eine Re-Signing-CA kann Zertifikate für fremde Domains ausstellen. Ihr Private Key ist damit ein besonders schützenswerter Schlüssel. Die CA darf nur für den vorgesehenen Inspection-Pfad verwendet, nicht exportiert oder in Tickets weitergegeben werden. Ohne getesteten Rückweg wird sie nicht produktiv aktiviert.

Dieser Ablauf ist für AD CS im Enterprise-CA-Modus beschrieben. Sophos weist ausdrücklich darauf hin, dass das dokumentierte Verfahren nicht für eine Standalone CA gilt. Eine andere interne PKI kann ebenfalls eine Subordinate CA ausstellen, benötigt aber einen eigenen, durch den PKI-Betreiber geprüften Prozess.

Alternativ können CSR und CAs mit einem externen Werkzeug wie OpenSSL erzeugt werden. Extern erzeugte Subordinate und Root CAs werden unter Certificates > Certificate authorities hochgeladen; bei einer Signing-CA ohne passenden Firewall-CSR ist auch ihr Private Key über den freigegebenen PKI-Prozess erforderlich. Die Root bleibt ohne Private Key. Dies ist ein anderer Schlüsseltransportweg, nicht der unten beschriebene CSR-Import. Die Subordinate CA kann auch für TLS-Konfigurationen von E-Mails verwendet werden; die folgende Aktivierung und Abnahme betrifft jedoch nur Webverkehr und aktiviert keine E-Mail-TLS-Konfiguration.

Wann eine Subordinate CA sinnvoll ist

Eine eigene Subordinate CA passt vor allem in verwalteten Unternehmensnetzen, in denen bereits eine interne Root-CA auf den Clients vertraut wird. Dadurch muss nicht auf jedem Gerät ein zusätzlicher, unabhängiger Sophos Trust Anchor verteilt werden. Rotation, Sperrung und Verantwortlichkeit lassen sich in die bestehende PKI-Governance aufnehmen.

Die Lösung ist jedoch nicht automatisch einfacher. Die Firewall erhält einen Schlüssel, mit dem sie Zertifikate für TLS Inspection signieren kann. Daher braucht die CA einen eng definierten Zweck, dokumentierte Owner, eine begrenzte Laufzeit und einen getesteten Sperr- und Erneuerungsprozess.

Für kleinere Umgebungen ohne eigene PKI ist die eingebaute Sophos CA oft der einfachere Weg. Auswahl und Clientverteilung erklärt Sophos Firewall CA-Zertifikat für TLS Inspection verteilen. Den gesamten Pilot- und Ausnahmeprozess beschreibt Sophos Firewall TLS Inspection richtig einführen.

CA-Design und Rückweg vorbereiten

Vor dem CSR werden Zweck, Namen und Abhängigkeiten festgelegt. Ein mögliches Beispiel ist:

• SFOS-Objektname: SFOS-TLS-Inspection-SubCA-2026
• Common Name: SFOS TLS Inspection SubCA 2026
• ausstellende Root-CA: Example Enterprise Root CA
• geplanter Einsatz: ausschliesslich TLS Inspection und HTTPS Decryption auf FW01
• Pilotnetz: 10.20.30.0/24

Diese Werte sind Dokumentationsbeispiele und werden durch die eigene Namenskonvention, PKI und Pilotgruppe ersetzt. Eine eigene CA pro Firewall oder klar abgegrenztem Inspection-Cluster vereinfacht später Zuordnung, Sperrung und Rotation.

Vor dem Change müssen vorhanden sein:

• aktuelles Konfigurationsbackup und funktionierender unabhängiger Managementzugang,
• dokumentierte bisherige Re-Signing-CA und deren Clientverteilung,
• Zugriff auf eine AD CS Enterprise CA sowie Freigabe des PKI-Verantwortlichen,
• kleine verwaltete Testgruppe mit funktionierendem Rückweg,
• Plan für Sperrung, Erneuerung und kontrollierte Rückkehr zur bisherigen CA.

Der Backup- und Restore-Ablauf steht unter Sophos Firewall Backup erstellen und wiederherstellen. Ein Backup ersetzt jedoch nicht die Dokumentation der aktuell ausgewählten Re-Signing-CA und der vertrauenden Clients.

CSR auf der Sophos Firewall erzeugen

Der CSR wird auf der Firewall erzeugt, damit der Private Key dort entsteht und nicht zwischen AD CS, Admin-PC und Firewall transportiert werden muss.

1. Certificates > Certificates öffnen.
2. Add wählen.
3. Unter Action Generate certificate signing request (CSR) auswählen.
4. Einen eindeutigen Namen wie SFOS-TLS-Inspection-SubCA-2026 eintragen.
5. Key Type, Schlüssellänge beziehungsweise Kurve und Secure Hash gemäss eigener PKI-Policy wählen. Sophos zeigt in seinem Beispiel RSA, 2048 Bit und SHA-256; das ist ein Produktbeispiel und keine universelle Vorgabe.
6. Die freigegebenen Subject-Angaben und Subject Alternative Names der internen PKI eintragen.
7. Speichern und den CSR über das Download-Symbol öffnen.
8. Den CSR mit Copy to clipboard kopieren und ausschliesslich an den autorisierten AD-CS-Prozess übergeben.

Der CSR enthält keinen Private Key. Trotzdem gehört er zum kontrollierten PKI-Prozess, weil er Identität, öffentlichen Schlüssel und den beantragten CA-Zweck festlegt.

Die CSR-Maske enthält unter Subject name attributes Country name, State, Locality name, Organization name, Organization unit name, Common name und Email address. Man trägt die durch die PKI freigegebenen Identitätsangaben ein, nicht die Daten einer beliebigen besuchten Website. Subject Alternative Names akzeptiert DNS-Namen oder IP-Adressen, zum Beispiel web.exampleorg.com, fd12:3456:789a:1:: oder 203.0.113.10. Diese Werte aus dem Produktbeispiel sind keine Vorgaben für eine Inspection-CA; SANs werden mit dem PKI-Verantwortlichen festgelegt.

Subordinate CA mit AD CS ausstellen

Auf dem Web Enrollment der zuständigen AD CS Enterprise CA wird der Sophos-CSR eingereicht:

1. Request a certificate öffnen.
2. Advanced certificate request wählen.
3. Den kopierten CSR vollständig einfügen.
4. Als Certificate template Subordinate Certification Authority auswählen.
5. Antrag gemäss interner Freigabe prüfen und mit Submit ausstellen.
6. Unter Certificate Issued ein passendes Format wählen, beispielsweise Base 64 encoded.
7. Mit Download certificate das ausgestellte Subordinate-CA-Zertifikat herunterladen.
8. Auf der AD-CS-Startseite Download a CA certificate öffnen, die Root-CA auswählen, welche die Subordinate CA signiert hat, und Download CA certificate sowie Save wählen.

Wichtige EKU-Grenze: Enthält das ausgestellte CA-Zertifikat einen Abschnitt Extended Key Usage, muss für diesen Signing-Zweck TLS Web Server Authentication enthalten sein. Fehlt der Wert, wird das Zertifikat nicht als Re-Signing-CA produktiv eingesetzt. Das CA-Template muss dann durch den PKI-Verantwortlichen korrigiert und ein neues Zertifikat ausgestellt werden.

Vor dem Import werden Issuer, Subject, Laufzeit, Basic Constraints und gegebenenfalls Extended Key Usage in der Zertifikatsanzeige geprüft. Die Root- und Subordinate-Dateien werden eindeutig benannt und nicht mit Serverzertifikaten verwechselt.

Subordinate und Root CA importieren

Subordinate CA beim vorhandenen CSR importieren

1. Certificates > Certificates öffnen.
2. Beim zuvor erzeugten CSR die Importaktion wählen.
3. Das von AD CS ausgestellte Subordinate-CA-Zertifikat auswählen.
4. Certificate authority only wählen. SFOS erkennt den CA-Typ und zeigt die CA-Optionen an.
5. Namen kontrollieren und Import certificate ausführen.
6. Unter Certificates > Certificate authorities den Filter neben Name öffnen, den CA-Namen eingeben und Apply wählen.

SFOS ordnet dabei den zum CSR gehörenden Private Key automatisch der Subordinate CA zu. In der CA-Liste muss deshalb bei dieser CA das Private-Key-Symbol sichtbar sein. Fehlt es, ist die CA nicht zum Signieren einsatzbereit. Die allgemeine CA-Importfunktion unter Certificates > Certificate authorities > Add kann ebenfalls einen passenden vorhandenen CSR erkennen. Der hier beschriebene Import direkt beim CSR macht die Zuordnung ausdrücklich nachvollziehbar; er ist aber nicht der einzige dokumentierte Zuordnungsweg. Ohne passenden CSR beziehungsweise Private Key erzeugt ein erneuter Zertifikatsupload keinen Signing-Key.

Root CA nur zur Validierung hinzufügen

Das Sophos-Schrittbeispiel nennt den Zweck Validation, die CA-Feldreferenz Validation only. Gemeint ist hier dieselbe sichere Rolle: Root-Zertifikat nur zur Validierung, ohne Root-Private-Key; nicht Signing and validation für die Root auswählen. Beim Upload wird die Datei unter Certificate mit Browse gewählt.

1. Certificates > Certificate authorities öffnen und Add wählen.
2. Das Root-CA-Zertifikat hochladen, das die Subordinate CA ausgestellt hat.
3. Unter Use certificate for Validation only beibehalten.
4. Namen und Fingerprint mit der freigegebenen Root-CA-Dokumentation vergleichen.
5. Speichern und die Kette der Subordinate CA erneut kontrollieren.

Die Root-CA benötigt auf der Firewall keinen Private Key. Signing and validation ist ausschliesslich für die Subordinate CA vorgesehen, deren Private Key durch den CSR bereits auf der Firewall liegt. Die allgemeinen Unterschiede zwischen Zertifikat, CSR, Private Key und CA-Kette erklärt Zertifikate auf Sophos Firewall importieren und zuweisen.

CA für TLS Inspection auswählen

Der Import allein verändert noch keinen Datenverkehr. Die neue CA wird zuerst in einem eng begrenzten Pilot aktiviert. Bei DPI gibt es eine globale Auswahl und eine mögliche Überschreibung pro Regel; der Web Proxy hat eine separate Auswahl:

• DPI, global: Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings
• DPI, pro Regel: Das unter Profiles > Decryption profiles zugewiesene Decryption Profile kann die globale Auswahl übernehmen oder überschreiben.
• Web Proxy: Web > General settings > HTTPS decryption and scanning

In den DPI-Einstellungen gibt es getrennte Felder für Re-sign RSA with und Re-sign EC with. Sie richten sich danach, ob das ursprüngliche Website-Zertifikat mit RSA beziehungsweise EC signiert wurde. In beiden Feldern darf SFOS eine RSA- oder EC-CA verwenden. Meist kann daher dieselbe Subordinate CA für beide Felder gewählt werden. Eine zweite EC-CA ist vor allem dann sinnvoll, wenn eine Anwendung nur einen bestimmten Zertifikatstyp akzeptiert; auch dieser CA müssen alle betroffenen Clients vertrauen.

Ein einer Inspection Rule zugewiesenes Decryption Profile kann mit Use CAs defined in SSL/TLS settings bewusst die globale Auswahl übernehmen. Werden dort stattdessen eigene Werte für Re-sign RSA with und Re-sign EC with gesetzt, überschreiben sie die globalen Einstellungen für diese Regel. Vor dem Pilot muss deshalb nicht nur die globale CA-Auswahl, sondern auch das tatsächlich zugewiesene Profil kontrolliert werden.

Nur eine CA mit dem Zweck Signing and validation und vorhandenem Private Key darf als Re-Signing-CA verwendet werden. Eine bereits verwendete Signing-CA wird nicht auf Validation only umgestellt; sie wäre damit nicht mehr für das aktive Re-Signing verwendbar. Daraus folgt keine Aussage darüber, ob SFOS den gespeicherten Schlüssel löscht.

Pilotumfang zuerst sichern: Eine globale DPI-CA-Änderung betrifft auch bestehende Regeln, deren Profile die globale Auswahl übernehmen. Für einen isolierten DPI-Pilot ein eigenes Decryption Profile mit expliziten CA-Werten verwenden und nur der bereits auf die Testgruppe begrenzten Pilotregel zuweisen. Kein produktiv geteiltes Profil bearbeiten. Die globale Web-Proxy-CA-Auswahl wird durch eine neue Pilotregel nicht isoliert; bei bereits aktivem Proxy-Scanning ist ein separat freigegebener Change für alle betroffenen Clients nötig. Bis dahin bleibt die bisherige globale CA unverändert.

Für den Pilot:

1. Bisherige Auswahl und betroffene Regeln dokumentieren.
2. Neue CA im vorgesehenen Inspection-Pfad für RSA- und EC-Zertifikate auswählen und bei DPI prüfen, ob das zugewiesene Decryption Profile die globale Auswahl übernimmt oder überschreibt.
3. Regel auf die definierte Testgruppe oder das Pilotnetz begrenzen.
4. CA-Kette auf den Pilotclients prüfen. In einer AD-Domäne sollte die Enterprise Root CA bereits vertrauenswürdig sein; die vollständige Kette bis zur neuen Subordinate CA muss dennoch erfolgreich aufgebaut werden.
5. Einen echten HTTPS-Aufruf auslösen und Zertifikatsdetails, Inspection Rule, Decryption Profile und Log-Eintrag gemeinsam prüfen.

Eine breite produktive Umstellung erfolgt erst, wenn der Pilot bestanden ist. Die CA-Auswahl aktiviert nicht automatisch eine Inspection Rule, und die Clientvertrauensstellung beweist nicht, dass der Traffic tatsächlich entschlüsselt wird.

API-Abgleich: CA-Auswahl und globale Schalter trennen

Wer die CA-Auswahl über die XML API prüft oder automatisiert, muss die Felder im Objekt SSLTLSInspectionSettings auseinanderhalten. Die Referenzen für SFOS 22.0 und 23.0 nennen dieselben Felder; daraus folgt kein Nachweis, dass eine konkrete Firewall einen Change bereits erfolgreich angewendet hat.

• RSACA und ECCA sind die CA-Auswahl für das Re-Signing von RSA- beziehungsweise EC-Serverzertifikaten, entsprechend Re-sign RSA with und Re-sign EC with. Als Wert dient der Name des vorgesehenen CA-Objekts, beispielsweise SFOS-TLS-Inspection-SubCA-2026, nicht ein Zertifikatsdateipfad, Private Key oder Aktivierungswert. Die Auswahl erzeugt oder importiert keine CA und verteilt kein Clientvertrauen. Die zuvor beschriebenen Anforderungen an Signing-Zweck, Private Key, Kette und Profil-Overrides bleiben bestehen; bei zwei unterschiedlichen verwendeten CAs müssen die betroffenen Clients beide Ketten prüfen können.

• SSLTLSEngine schaltet die TLS engine, SSLTLSInspection die globale SSL/TLS Inspection; beide akzeptieren Enabled oder Disabled. Diese Felder sind weder CA-Auswahl noch Status der einzelnen Pilotregel. Eine CA-Rotation ist kein Anlass, diese globalen Schalter zu ändern. Die API-Referenz nennt für beide den Default Enabled; für den Change zählt jedoch der ausgelesene Istzustand, nicht ein Dokumentationsdefault.

• TLS13Decryption legt die globale Behandlung von TLS-1.3-Verbindungen fest: Decrypt as 1.3 oder Downgrade to TLS 1.2 and decrypt, mit dem dokumentierten Default Decrypt as 1.3. Das Feld wählt keine Signing-CA und keine Aktion einer einzelnen Inspection Rule. Ein Downgrade ist daher kein Reparaturweg für eine fehlende CA-Kette oder einen fehlenden Signing-Key; bei einem reinen CA-Wechsel bleibt die freigegebene TLS-1.3-Einstellung unverändert.

Auch SSLv2SSLv3, SSLCompression und SSLConnectionsExceeded sind eigene globale Entscheidungen für alte Protokolle, SSL Compression beziehungsweise überschrittene SSL-Verbindungskapazität. Sie akzeptieren jeweils Allow without decryption, Drop oder Reject; die API nennt jeweils Allow without decryption als Default, nicht als Sicherheitsempfehlung. Diese Entscheidungen werden bei einer CA-Rotation nicht nebenbei auf Beispielwerte zurückgesetzt.

Vor einem API-Change die tatsächlich gespeicherten globalen Werte, beide CA-Objektnamen, Profil-Overrides und betroffene Regeln sichern und den exakten Rückweg festlegen. Die Referenz kennzeichnet die genannten Felder als optional; das beweist nicht, dass ausgelassene Felder auf jeder Firmware unverändert bleiben. Ohne buildbezogen bestätigtes Update- und Wiederherstellungsverhalten keinen automatisierten Schreibaufruf ausführen. Eine dokumentierte API-Antwort 200 bedeutet Operationserfolg, 500 Operationsfehler; auch eine Erfolgsmeldung ersetzt nicht das erneute Auslesen der gespeicherten Werte und den Test mit neuen HTTPS-Verbindungen. Ein unerwarteter Wert oder unklarer Zustand stoppt die Ausweitung des Piloten.

Funktion und Sicherheit abnehmen

Ein erfolgreicher Test besteht aus mehreren Nachweisen:

1. Unter Certificates > Certificate authorities ist die Root CA als Validation only vorhanden.
2. Die Subordinate CA ist Signing and validation zugeordnet und zeigt das Private-Key-Symbol.
3. Ein Pilotclient vertraut der Root-CA und kann die vollständige Kette aufbauen.
4. Eine bewusst entschlüsselte HTTPS-Seite zeigt ein von der neuen Subordinate CA signiertes Serverzertifikat.
5. Hostname, Originalziel und Browserstatus sind korrekt; es erscheint keine unerwartete Zertifikatswarnung.
6. Log Viewer zeigt die erwartete SSL/TLS Inspection Rule und Aktion für genau diesen Test.
7. Eine nicht zum Pilot gehörende Quelle bleibt auf dem bisherigen Pfad.

Zusätzlich werden Anwendungen mit Certificate Pinning, eigenen Trust Stores oder sensiblen Updatepfaden separat getestet. Ein erfolgreicher Browseraufruf allein reicht nicht für den gesamten Rollout.

Für die Abnahme sowohl ein RSA- als auch ein EC-Serverzertifikat im vorgesehenen DPI-Pfad testen und jeweils präsentierten Issuer, vollständige Root-/Subordinate-Kette, Clientvertrauen, tatsächlich zugewiesenes Profil und Log-Aktion vergleichen. Bei unterschiedlichen Signing-CAs beide Vertrauensketten separat prüfen. Zusätzlich bestätigen, dass globale Schalter, TLS-1.3-Behandlung und die übrigen globalen Entscheidungen ihrem dokumentierten Vorzustand entsprechen und eine Quelle ausserhalb des Piloten unverändert bleibt.

Rotation und Rollback

Die Subordinate CA braucht eine Erneuerung vor ihrem Ablauf. Neue und alte CA sollten während einer kontrollierten Übergangsphase klar unterscheidbar bleiben. Die neue CA wird zuerst ausgestellt, importiert, auf Pilotclients geprüft und erst danach schrittweise im Inspection-Pfad ausgewählt.

Bei Fehlern gilt der vorbereitete Rückweg:

Für einen CA-Rollback bevorzugt man die bisherige CA beziehungsweise das bisherige Profil. Das Deaktivieren einer Pilotregel allein garantiert weder die bisherige CA noch die bisherige Entschlüsselung: Eine nachfolgende Regel kann übernehmen. Vorher den tatsächlichen Folgepfad prüfen und danach Zertifikat sowie Logs erneut kontrollieren.

Ein CA-Rollback stellt nur die pilotbedingten CA-/Profiländerungen auf den gesicherten Vorzustand zurück. SSLTLSEngine oder SSLTLSInspection pauschal auf Disabled zu setzen oder TLS13Decryption zu ändern, stellt weder die bisherige CA noch den bisherigen Schutzpfad wieder her. Danach gespeicherte Auswahl und Overrides erneut auslesen sowie Zertifikatskette und Logs mit neuen Verbindungen kontrollieren. Fehlt ein nachgewiesener Rückweg, nicht weiter ausrollen.

1. Bisherige Re-Signing-CA beziehungsweise das bisherige Decryption Profile wiederherstellen. Die Pilotregel nur dann deaktivieren, wenn der zuvor geprüfte Folgepfad den freigegebenen Vorzustand wiederherstellt; kein pauschales Abschalten der globalen Engine oder Inspection.
2. Mit einem neuen Browserprozess prüfen, dass der bisherige Zertifikatspfad wieder greift.
3. Neue CA nicht löschen, solange Regeln, Decryption Profiles oder Web-Proxy-Einstellungen darauf verweisen.
4. PKI-Verantwortlichen einbeziehen, wenn EKU, Kette, Template oder Sperrstatus unklar sind.
5. Kompromittierte Schlüssel nicht weiterverwenden; CA sperren, neue CA ausstellen und Trust Stores kontrolliert bereinigen.

Eine CA wird erst gelöscht, wenn keine Konfiguration mehr darauf verweist, der alte Pfad nicht mehr benötigt wird und die Aufbewahrungs- sowie Audit-Vorgaben erfüllt sind.

Fehler gezielt eingrenzen

Private-Key-Symbol fehlt

Den vorhandenen CSR, das dazu ausgestellte Zertifikat und die automatische Schlüsselzuordnung prüfen. Auch beim Import unter Certificates > Certificate authorities > Add ist entscheidend, ob SFOS einen passenden CSR findet. Fehlt der passende CSR oder stimmt das Zertifikat nicht mit ihm überein, ist die Zuordnung nicht nachgewiesen. Private Keys werden nicht aus Tickets, E-Mails oder unkontrollierten Ablagen nachgeladen.

CA lässt sich nicht als Re-Signing-CA auswählen

CA-Zweck, Private-Key-Symbol und Zertifikatserweiterungen kontrollieren. Ist eine Extended Key Usage vorhanden, muss TLS Web Server Authentication enthalten sein. Eine Root CA mit Validation only ist bewusst nicht für das Re-Signing auswählbar.

Client meldet eine nicht vertrauenswürdige Kette

Root- und Subordinate-CA, Fingerprints und Trust Store des betroffenen Clients prüfen. Danach den tatsächlich präsentierten Issuer im Browser mit der auf SFOS ausgewählten CA vergleichen. Das blosse Vorhandensein der Root CA auf der Firewall oder dem Client beweist nicht, dass die richtige Re-Signing-CA aktiv ist.

Browser funktioniert, eine Anwendung aber nicht

Die Anwendung kann einen eigenen Trust Store oder Certificate Pinning verwenden. Zuerst Ziel, Client, Inspection Rule und Fehlerzeitpunkt dokumentieren. Keine globale Don't decrypt-Ausnahme setzen; den Fehler im kleinen Pilot eingrenzen und nur die nötige Ausnahme begründet freigeben.

FAQ