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.

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.

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. Das ausgestellte Subordinate-CA-Zertifikat herunterladen.
8. Zusätzlich das Zertifikat der Root-CA herunterladen, welche die Subordinate CA signiert hat.

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 nach der importierten CA suchen.

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; ein erneuter Upload der Datei an anderer Stelle ersetzt die fehlende Schlüsselbindung nicht.

Root CA nur zur Validierung hinzufügen

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. Je nach Inspection-Pfad liegt die Auswahl an unterschiedlichen Stellen:

• DPI: Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings
• Decryption Profile: Profiles > Decryption profiles
• Web Proxy: Web > General settings > HTTPS decryption and scanning

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; dadurch würde der aktive Re-Signing-Pfad seinen Schlüssel verlieren.

Für den Pilot:

1. Bisherige Auswahl und betroffene Regeln dokumentieren.
2. Neue CA im vorgesehenen Inspection-Pfad auswählen.
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.

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.

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:

1. Pilotregel deaktivieren oder wieder auf die bisherige Re-Signing-CA zurückstellen.
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

Wurde das Zertifikat nicht über die Importaktion beim passenden CSR eingelesen, kann SFOS den auf der Firewall erzeugten Schlüssel nicht zuordnen. Den CSR-Zuordnungspfad und das ausgestellte Zertifikat prüfen. 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