Sophos Firewall Default CA kontrolliert erneuern

Die eingebaute Default CA ist auf Sophos Firewall kein gewöhnlicher Beschreibungseintrag. Sobald ihre Einstellungen gespeichert werden, regeneriert SFOS die CA automatisch. Dabei entsteht ein neuer Schlüssel und damit ein neuer Trust Anchor. Alte Vertrauensstellungen passen danach nicht mehr automatisch.

Eine kontrollierte Erneuerung beginnt deshalb nicht mit Save, sondern mit einer vollständigen Abhängigkeitsliste. Dazu gehören lokal signierte Zertifikate, WebAdmin und Portale, SSL-VPN-Profile, zertifikatsbasierte IPsec-Peers sowie externe Systeme, die der bisherigen CA vertrauen.

⚠️ Wichtig: Die Default CA nur mit geprüftem Backup, unabhängigem Managementzugang, Wartungsfenster und einem Plan für alle abhängigen Dienste erneuern. Eine kosmetische Änderung an Land, Organisation oder Common Name rechtfertigt keine ungeplante Regeneration.

Default CA in zehn Schritten erneuern

1. Technischen Grund, Change Owner, Wartungsfenster und Erfolgskriterien dokumentieren.
2. Alle Zertifikate, Dienste, VPN-Profile, Peers und Clients erfassen, die der bisherigen Default CA vertrauen.
3. Prüfen, ob das eigentliche Ziel nicht nur das ApplianceCertificate oder die separate SecurityAppliance_SSL_CA betrifft.
4. Aktuelles Konfigurationsbackup, SSMK, lokalen Adminzugang und Recovery-Weg positiv testen.
5. Alte Default CA herunterladen, SHA-256-Fingerprint, Subject, Seriennummer und Gültigkeit sichern.
6. Neue CA-Daten, Schlüsseltyp und Kompatibilität mit allen Gegenstellen schriftlich freigeben.
7. Unter Certificates > Certificate authorities > Default die vorbereiteten Werte eintragen und erst im Wartungsfenster speichern.
8. Neue öffentliche CA herunterladen und kontrolliert an Peers, Clients und Trust Stores verteilen.
9. WebAdmin, Portale, SSL VPN, IPsec und jeden weiteren abhängigen Dienst separat testen.
10. Fingerprint, Logs, Testergebnisse und verbleibende Altprofile dokumentieren; bei einem kritischen Fehler den vorbereiteten Rückweg verwenden.

Default CA, ApplianceCertificate und Inspection CA unterscheiden

Sophos Firewall enthält mehrere Objekte mit unterschiedlichen Aufgaben:

• Default: interne CA für lokal signierte Zertifikate.
• ApplianceCertificate: eingebautes Serverzertifikat, das standardmässig für WebAdmin, User Portal und Captive Portal verwendet wird. Es ist von der Default CA signiert und kann separat regeneriert werden.
• SecurityAppliance_SSL_CA: separate eingebaute CA für HTTPS-Inspection und Re-Signing, sofern sie in der TLS-Inspection-Konfiguration ausgewählt ist.

Diese Objekte dürfen nicht gleichgesetzt werden. Ein Problem mit einem einzelnen ApplianceCertificate beweist keinen Defekt der Default CA. Ebenso erzeugt eine Änderung der Default CA nicht automatisch einen geplanten Wechsel der SecurityAppliance_SSL_CA.

Die allgemeine Arbeit mit Zertifikat, Private Key, CSR und CA-Kette erklärt Zertifikate auf Sophos Firewall importieren und zuweisen. Für die Inspection CA gilt der eigene Ablauf CA-Zertifikat für HTTPS Scanning verteilen.

Wann eine Regeneration gerechtfertigt ist

Ein geplanter Wechsel kann nötig sein, wenn:

• der bisherige CA-Schlüssel nachweislich oder plausibel kompromittiert ist,
• die CA abläuft und tatsächlich noch produktiv verwendet wird,
• Identität, Schlüsseltyp oder Kryptografievorgaben kontrolliert migriert werden,
• Sophos Support die Regeneration für ein bestätigtes Fehlerbild verlangt.

Keine ausreichenden Gründe sind ein einzelner fehlgeschlagener VPN-Download, eine Browserwarnung ohne Kettenanalyse, ein kosmetischer Subject-Wunsch oder ein alter Community-Befehl. Für ein Problem mit .ovpn und ApplianceCertificate zuerst SSL-VPN-Konfigurationsdownload systematisch prüfen.

Abhängigkeiten vor dem Change inventarisieren

Zertifikate und zugewiesene Dienste

Unter Certificates > Certificates für jedes lokal signierte Zertifikat mindestens Name, Subject, Issuer, Gültigkeit und tatsächliche Zuweisung erfassen. Dazu gehören je nach Umgebung:

• WebAdmin, User Portal und Captive Portal,
• SSL-VPN-Serverzertifikat,
• Site-to-Site- und Remote-Access-IPsec mit Digital certificate,
• WAF-, SMTP-, API- oder andere TLS-Dienste,
• selbst erzeugte Client- oder Serverzertifikate ausserhalb der Firewall.

Ein sichtbares Zertifikat ist noch keine Abhängigkeit. Entscheidend ist, ob ein produktiver Dienst es verwendet und ob die Gegenstelle der ausstellenden Default CA vertraut.

Vertrauende Systeme und Verteilungswege

Zusätzlich dokumentieren:

• Browser und Betriebssysteme mit importierter alter CA,
• MDM-, GPO- oder Softwareverteilung für die neue CA,
• IPsec-Peers mit importierter Default.pem, Remote CA oder DN-Zuordnung,
• SSL-VPN-Benutzer und der Weg für neue .ovpn-Profile,
• Monitoring, API-Clients oder Integrationen mit Zertifikatspinning,
• HA-, Notfall- und externer Managementzugang.

Wenn nicht klar ist, wer die bisherige CA verteilt hat oder welche Gegenstellen darauf vertrauen, wird der Change gestoppt.

Ausgangszustand und Rückweg sichern

Vor dem Wartungsfenster unter Certificates > Certificate authorities die Default CA herunterladen. Das Archiv enthält den öffentlichen Teil, nicht automatisch einen separat nutzbaren Export ihres Private Keys.

Auf einem Admin-Computer lassen sich PEM-Daten lesend prüfen:

openssl x509 -in Default.pem -noout -subject -issuer -serial -dates -fingerprint -sha256

Für eine DER-Datei wird das Eingabeformat angegeben:

openssl x509 -inform DER -in Default.der -noout -subject -issuer -serial -dates -fingerprint -sha256

Fingerprint und Ausgabe gehören mit Firewallname, Seriennummer, SFOS-Build und Change-Ticket in die Vorheraufnahme. Zertifikatsdateien und interne PKI-Daten werden nicht ungeschützt an öffentliche Tickets angehängt.

Zusätzlich ein aktuelles Sophos Firewall Backup mit Passwort und SSMK extern sichern. Ein Restore ersetzt die gesamte Konfiguration, startet die Firewall neu und kann spätere Änderungen zurücksetzen. Er ist ein letzter geplanter Rückweg, keine schnelle Undo-Funktion für die CA.

Wartungsfenster vorbereiten

Vor Save müssen folgende Punkte grün sein:

• lokales admin-Konto oder zweiter Admin aus dem Managementnetz getestet,
• Console- oder anderer unabhängiger Recovery-Zugang vorhanden,
• neue CA-Werte und Kryptografie mit allen Peer-Systemen kompatibel,
• Verantwortliche für VPN-Peers, MDM/GPO und Portale erreichbar,
• neue Profile, Trust-Store-Verteilung und Testkonten vorbereitet,
• Zeitfenster für einen vollständigen Backup-Restore realistisch vorhanden.

In einem HA-Cluster wird die unterstützte WebAdmin-Konfiguration auf dem aktuellen Primary vorgenommen. SFOS dokumentiert für diesen Change keine unterbrechungsfreie CA- oder Sitzungskontinuität. Nach einem geplanten Failover sind deshalb frische Anmeldungen und alle kritischen Dienste erneut zu prüfen; die CA nicht unabhängig auf beiden Nodes bearbeiten.

Default CA in SFOS aktualisieren

1. Certificates > Certificate authorities öffnen.
2. Auf Default klicken. Der Name selbst lässt sich nicht ändern.
3. Country, State, Locality, Organization, Organizational unit, Common name und E-Mail-Adresse kontrollieren.
4. Unter Private key settings bewusst RSA oder Elliptic curve, die dazugehörige Schlüssellänge beziehungsweise Kurve und den Secure hash wählen.
5. Werte gegen Change-Ticket und Kompatibilitätsliste prüfen.
6. Erst im Wartungsfenster auf Save klicken.

Beispielwerte wie CH, Zurich, Example AG, IT Security, fw01.example.com und pki@example.com sind reine Dokumentationswerte. Sie werden durch die eigene Organisation, den tatsächlichen Firewallbezug und die freigegebene PKI-Namenskonvention ersetzt.

⚠️ Save ist der Umschaltpunkt. SFOS regeneriert die Default CA automatisch. Die bisherigen Subject-Werte später erneut einzutragen, stellt den alten Schlüssel und Fingerprint nicht wieder her.

Direkt danach die neue Default CA herunterladen und denselben OpenSSL-Check ausführen. Ein neuer SHA-256-Fingerprint ist nach einer Regeneration zu erwarten. Unerwartete Felder, Fehler beim Download oder ein nicht dokumentierbarer Zustand sind Stop-Bedingungen.

Abhängige Dienste kontrolliert umstellen

WebAdmin und Portale

Prüfen, welches Zertifikat unter Administration > Admin and user settings für WebAdmin, User Portal und Captive Portal ausgewählt ist. Wird ein lokal signiertes Zertifikat mit der neuen CA verwendet, muss die neue CA auf den zugreifenden Clients vertrauenswürdig sein.

Eine bestehende Full-Admin-Sitzung bleibt während der Prüfung offen. Neue private Browserfenster testen FQDN, Zertifikatskette und Anmeldung aus der vorgesehenen Managementquelle. Der CLI-Befehl zum Zurücksetzen des WebAdmin-Zertifikats auf das Default-Gerätezertifikat ist kein Rollback des alten CA-Schlüssels.

SSL VPN

Verwendet SSL VPN das ApplianceCertificate oder ein anderes lokal signiertes Serverzertifikat, müssen Benutzer nach Änderung der Default-CA-Einstellungen eine neue .ovpn-Datei herunterladen und importieren. Ein vorhandener Dateiname oder ein grüner Tunnelstatus mit altem Profil reicht nicht als Abnahme.

Mindestens ein Pilotbenutzer lädt das neue Profil über den vorgesehenen Portalweg, baut eine frische Verbindung auf und prüft DNS, Route und echten Anwendungsverkehr. Alte Profile werden erst nach erfolgreicher Migration aller Nutzer aus der Verteilung entfernt.

Zertifikatsbasierte IPsec-Peers

Bei Digital certificate tauschen Sophos-Firewall-Peers ihre CA-Zertifikate aus. Wurde bisher Default.pem der Gegenseite importiert, muss der neue öffentliche CA-Teil kontrolliert auf dem Peer ersetzt beziehungsweise ergänzt und die Zuordnung erneut geprüft werden.

Die vollständige Verbindungskonfiguration bleibt im Artikel Site-to-Site IPsec auf Sophos Firewall einrichten. Für den CA-Wechsel werden mindestens IKE-Aufbau, Child SA, beide Verkehrsrichtungen und die tatsächlichen Anwendungen getestet. Ein grüner Tunnel allein beweist den Rückweg nicht.

HTTPS-Inspection und andere Signierpfade

Für HTTPS-Inspection zuerst die unter Web > General settings tatsächlich ausgewählte Signing CA ermitteln. Ist dies SecurityAppliance_SSL_CA oder eine externe CA, wird sie nicht nur wegen der Default-CA-Regeneration neu verteilt.

Nur wenn ein Signierpfad nachweislich die geänderte Default CA oder ein davon abhängiges Zertifikat verwendet, gehört er in den Change. Dadurch bleibt die Trust-Store-Änderung auf die wirklich betroffenen Endpoints begrenzt.

Ergebnis und Logs prüfen

Die Abnahme trennt Konfiguration und Funktion:

1. Neue CA herunterladen und Subject, Issuer, Seriennummer, Gültigkeit und SHA-256-Fingerprint dokumentieren.
2. Unter Certificates > Certificates Issuer, Trusted und betroffene Zertifikatsobjekte prüfen.
3. WebAdmin, Portale, SSL VPN, IPsec und weitere zugewiesene Dienste einzeln testen.
4. In vpncertificate.log die CA- und Zertifikatsoperation zum Change-Zeitpunkt prüfen.
5. In configuration-audit.log Administrator, Zeit und unterstützte Vorher-/Nachherdaten kontrollieren.
6. In den jeweiligen Dienstlogs nur die zum Test gehörenden Fehler und Erfolge korrelieren.

Der Audit Trail wird in Konfigurationsänderungen mit configuration-audit.log nachvollziehen erklärt. Nicht jeder Dienst schreibt denselben Detailgrad in configuration-audit.log; die technische Abnahme bleibt deshalb zwingend.

Rollback und Stop-Bedingungen

Eine regenerierte CA besitzt keinen einfachen Undo-Schalter. Das erneute Speichern alter Texte stellt den alten Private Key nicht wieder her.

Der Rückweg wird deshalb vorab je Dienst festgelegt:

• unabhängigen Managementzugang und bestehende Admin-Sitzung halten,
• bei Portalen auf ein bereits geprüftes, unabhängiges externes Zertifikat zurückwechseln, falls dieses verfügbar und sicher zugewiesen ist,
• Peer-Trust und Clientprofile nur nach dokumentiertem Vorzustand zurücksetzen,
• einen vollständigen Backup-Restore nur einsetzen, wenn Auswirkungen, Neustart, SSMK und Verlust späterer Änderungen akzeptiert sind,
• bei unbekannter Abhängigkeit oder nicht reproduzierbarem Zertifikatszustand mit Beweisen an Sophos Support eskalieren.

Keine Shell-Datenbankänderung, kein massenhaftes Löschen von Zertifikaten, kein Service-Restart und keine zweite CA-Regeneration auf Verdacht. Der Change wird gestoppt, wenn ein kritischer Peer nicht koordiniert werden kann, der neue Trust Anchor nicht verteilt ist oder der Recovery-Weg nicht positiv getestet wurde.

Typische Fehler nach der Regeneration

Browser meldet eine nicht vertrauenswürdige Verbindung

Zertifikatskette des tatsächlich ausgelieferten FQDN prüfen. Ist das Serverzertifikat von der neuen Default CA signiert, muss genau diese CA im Trust Store liegen. Nicht pauschal die SecurityAppliance_SSL_CA importieren.

SSL VPN verbindet mit dem alten Profil nicht mehr

Ausgewähltes SSL-Serverzertifikat, neue CA, Portaldownload und sslvpn.log korrelieren. Eine neue .ovpn-Datei herunterladen und als neues Profil importieren. Alte und neue Profile nicht anhand des Dateinamens, sondern anhand von Zertifikat und erfolgreicher Verbindung unterscheiden.

IPsec bleibt nach dem CA-Wechsel down

Auf beiden Seiten CA-Import, Trusted-Status, Local/Remote certificate, ID und strongswan.log prüfen. Bei DER ASN1 DN kann die CA-Subject-Änderung zusätzlich die Identität beeinflussen. Keine Profile oder IDs auf Verdacht lockern.

HTTPS-Inspection zeigt Zertifikatsfehler

Zuerst die tatsächlich ausgewählte Signing CA prüfen. Wenn weiterhin SecurityAppliance_SSL_CA verwendet wird und unverändert ist, liegt der Fehler nicht automatisch an der neuen Default CA. Zertifikatskette, Decryption Rule und Endpoint Trust getrennt untersuchen.

Checkliste

• Grund und Scope der CA-Regeneration sind dokumentiert.
• Alte CA, Fingerprint, Backup, Passwort und SSMK sind gesichert.
• Alle Zertifikate, Dienste, Peers, Clients und Verteilungswege sind inventarisiert.
• Default, ApplianceCertificate und SecurityAppliance_SSL_CA sind getrennt bewertet.
• Wartungsfenster, Admin-Rückweg und Verantwortliche stehen bereit.
• Neue CA-Werte und Kryptografie sind mit allen Gegenstellen kompatibel.
• CA wurde erst im freigegebenen Fenster gespeichert und danach neu heruntergeladen.
• WebAdmin, Portale, SSL VPN, IPsec und weitere Dienste sind einzeln getestet.
• vpncertificate.log, configuration-audit.log und Dienstlogs sind gesichert.
• Rollback oder Support-Eskalation ist möglich, ohne unkontrollierte Shell-Eingriffe.

FAQ