Sophos Firewall CRL importieren und Zertifikate sperren

Eine externe Certificate Revocation List (CRL) importiert man unter Certificates > Certificate revocation lists > Add. Die Datei muss von der CA stammen, die das betroffene Zertifikat ausgestellt hat. Vor dem Upload werden Aussteller, Signatur, thisUpdate, nextUpdate und die gesperrten Seriennummern geprüft. Danach reicht ein sichtbarer Listeneintrag nicht als Erfolg: Der konkrete Dienst muss mit einem gültigen und, in einer kontrollierten Testumgebung, mit einem gesperrten Zertifikat geprüft werden.

Für lokal signierte Zertifikate ist der Ablauf anders. Diese kann SFOS selbst sperren und ergänzt die Details automatisch in der lokalen CRL. Ein extern signiertes Zertifikat wird dagegen bei der externen CA gesperrt; die Firewall kann diese Sperrung nicht selbst erzeugen.

CRL in acht Schritten importieren

1. Betroffenes Zertifikat, Aussteller, Seriennummer und verwendeten Firewall-Dienst dokumentieren.
2. Backup, unabhängigen Managementzugang und ein gültiges Ersatzzertifikat vorbereiten.
3. Bei der ausstellenden CA eine aktuelle vollständige CRL beziehen. Keine CRL einer ähnlich benannten anderen CA verwenden.
4. Die Datei auf einem Admin-Computer als DER oder PEM lesen und Aussteller, Signatur sowie thisUpdate und nextUpdate prüfen.
5. Kontrollieren, dass die zugehörige CA-Kette unter Certificates > Certificate authorities vorhanden ist.
6. Unter Certificates > Certificate revocation lists > Add einen eindeutigen Namen eintragen, die CRL-Datei auswählen und Save anklicken.
7. Einen normalen Positivtest mit einem weiterhin gültigen Zertifikat und einen kontrollierten Negativtest mit einem gesperrten Testzertifikat durchführen.
8. Owner, Bezugsquelle und Erneuerungstermin vor nextUpdate dokumentieren.

⚠️ Kein produktiv zugewiesenes Zertifikat und keine Default CA nur für einen Funktionstest sperren. Bei WebAdmin, Portalen, VPN oder anderen Managementdiensten können sonst Zugänge und Tunnel ausfallen. Die Sperrung wird zuerst mit einem eigens dafür ausgestellten Testzertifikat und einem vorhandenen Rückweg geprüft.

Ablaufdatum und Sperrung unterscheiden

Ein Zertifikat kann noch Monate gültig sein und trotzdem nicht mehr vertrauenswürdig sein. Das ist beispielsweise der Fall, wenn der Private Key kompromittiert wurde, der Inhaber die Berechtigung verloren hat oder das Zertifikat nicht mehr für den ursprünglichen Zweck verwendet werden darf. Die CA sperrt dann die Seriennummer und veröffentlicht diesen Status in einer CRL.

Eine CRL enthält unter anderem:

• den Issuer, also die Stelle, welche die CRL signiert hat;
• thisUpdate, den Ausgabezeitpunkt dieser Liste;
• nextUpdate, den spätesten Zeitpunkt, zu dem die CA eine neue Liste ankündigt;
• Seriennummer und Sperrzeitpunkt der widerrufenen Zertifikate;
• eine digitale Signatur, mit der sich Herkunft und Unverändertheit prüfen lassen.

Der Dateiname allein besitzt keine Vertrauenswirkung. Eine Liste namens vpn-current.crl kann veraltet sein oder zu einer anderen Issuing CA gehören. Entscheidend sind Aussteller, Signatur, Aktualität und die Seriennummer des konkreten Zertifikats.

Lokal oder extern signiert

SFOS trennt zwei Verantwortlichkeiten:

• Lokal signiertes Zertifikat: Die Firewall hat das Zertifikat mit ihrer internen CA signiert. Es kann unter Certificates > Certificates gesperrt werden. SFOS trägt die Sperrung automatisch in die zugehörige lokale CRL ein.
• Extern signiertes Zertifikat: Eine externe Unternehmens- oder öffentliche CA hat das Zertifikat ausgestellt. Nur diese CA kann die Sperrung veröffentlichen. Die aktuelle CRL wird anschliessend als Datei auf die Firewall geladen.

Eine extern bereitgestellte CRL ist kein Ersatz für die zugehörige CA-Kette. Zertifikat, Issuing CA, mögliche Intermediate CAs und CRL müssen zusammenpassen. Wie man Zertifikate, Private Keys, CSR und CA-Ketten unterscheidet, erklärt Zertifikate auf Sophos Firewall importieren und zuweisen.

CRL-Datei sicher vorbereiten

Vor einer Änderung wird zuerst der aktuelle Zustand festgehalten:

• Name, Issuer und Seriennummer des betroffenen Zertifikats;
• CRL-Aussteller und Bezugsquelle;
• aktuelles thisUpdate und nextUpdate;
• betroffener Dienst und dessen funktionierender Positivtest;
• zuständiger PKI-Owner;
• Backup und Rückweg, falls eine Zertifikatsprüfung produktiven Zugriff blockiert.

Die Firewallzeit muss stimmen. Ein falsches Datum kann Zertifikate und Sperrlisten veraltet oder noch nicht gültig erscheinen lassen. Die Zeitbasis und NTP-Konfiguration werden bei Bedarf mit Sophos Firewall Systemzeit und NTP konfigurieren geprüft.

Zertifikat und CRL einander zuordnen

Auf einem Admin-Computer zeigt OpenSSL Aussteller und Seriennummer eines PEM-Zertifikats:

openssl x509 -in client-cert.pem -issuer -serial -noout

client-cert.pem wird durch die lokale Zertifikatsdatei ersetzt. Der Befehl liest nur Metadaten und zeigt keinen Private Key.

Eine DER-codierte CRL wird so geprüft:

openssl crl -in corp-issuing-ca.crl -inform DER -issuer -lastupdate -nextupdate -crlnumber -noout

Für eine PEM-codierte CRL wird DER durch PEM ersetzt. corp-issuing-ca.crl ist ein Beispielname und wird durch die Datei der eigenen Issuing CA ersetzt. Der angezeigte Issuer muss zur geplanten Zertifikatskette passen, und nextUpdate darf für den vorgesehenen Betriebszeitraum nicht bereits überschritten sein.

Signatur und gesperrte Seriennummern prüfen

Die Signatur wird gegen eine vorbereitete CA-Datei geprüft:

openssl crl -in corp-issuing-ca.crl -inform DER -CAfile corp-ca-chain.pem -verify -noout

corp-ca-chain.pem enthält das Zertifikat des CRL-Signers und die für dessen Prüfung benötigte CA-Kette. Die Datei wird vom PKI-Verantwortlichen bereitgestellt und nicht aus einer beliebigen Downloadquelle zusammengesetzt. Wenn die CA eine PEM-CRL liefert, wird auch hier DER durch PEM ersetzt.

Für die vollständigen CRL-Details einschliesslich gesperrter Seriennummern verwendet man:

openssl crl -in corp-issuing-ca.crl -inform DER -text -noout

Bei grossen Unternehmens-CAs kann die Ausgabe lang sein. Sie enthält zwar keinen Private Key, aber interne PKI-Metadaten und Seriennummern. Die Ausgabe wird deshalb nicht ungefiltert in öffentliche Tickets, Chats oder Screenshots kopiert.

Externe CRL auf SFOS importieren

Eine externe CRL wird nur von der zuständigen CA oder aus deren vertrauenswürdigem PKI-Prozess übernommen. Eine Datei aus einem alten Ticket oder einem nicht dokumentierten Fileshare ist keine belastbare Quelle.

1. Certificates > Certificate revocation lists öffnen.
2. Add auswählen.
3. Einen eindeutigen Namen eintragen, beispielsweise Corp-Issuing-CA-CRL.
4. Die vorab geprüfte .crl-Datei auswählen.
5. Save anklicken.
6. Kontrollieren, dass der neue Eintrag in der CRL-Liste erscheint.
7. Den geplanten Positiv- und Negativtest des betroffenen Dienstes ausführen.
8. nextUpdate, Owner und Bezugsquelle im Betriebsdokument festhalten.

Corp-Issuing-CA-CRL ist nur ein Beispielname. Er wird durch eine Bezeichnung ersetzt, aus der die tatsächliche Issuing CA und der Zweck hervorgehen. Der Name sollte nicht lediglich Current oder New CRL lauten, weil diese Angaben nach wenigen Monaten keinen eindeutigen Besitzer mehr erkennen lassen.

Die aktuelle SFOS-22-Hilfe dokumentiert in dieser Maske keinen automatischen Abruf über eine HTTP- oder LDAP-URL. Ein einmaliger Upload ist deshalb kein dauerhafter Betriebsprozess. Vor nextUpdate wird bei der CA eine neue Liste bezogen, erneut geprüft und über den freigegebenen CRL-Prozess auf SFOS aktualisiert. Die bisherige Liste wird nicht entfernt, bevor die neue Datei akzeptiert und der betroffene Dienst erneut geprüft wurde.

Lokal signiertes Zertifikat sperren

Ein lokal signiertes Zertifikat wird direkt auf der Firewall gesperrt. Vorher muss geklärt sein, ob es noch WebAdmin, Portal, VPN, WAF, SMTP oder einen anderen Dienst absichert. Falls ja, wird zuerst ein gültiges Ersatzzertifikat zugewiesen und getestet.

1. Unter Certificates > Certificates das lokal signierte Zertifikat identifizieren.
2. Subject, Issuer, Zweck und Dienstzuweisung nochmals kontrollieren.
3. Backup und unabhängigen Managementzugang bestätigen.
4. In der Zertifikatszeile die Revoke-Aktion für genau dieses Zertifikat ausführen.
5. Unter Certificates > Certificate revocation lists die CRL der zugehörigen lokalen CA suchen.
6. Download auswählen. SFOS liefert ein .tar-Archiv, aus dem die .crl-Datei extrahiert wird.
7. Die heruntergeladene CRL mit OpenSSL lesen und die Seriennummer des Testzertifikats vergleichen.
8. Den eigentlichen Dienst erneut positiv und negativ testen.

Sophos erlaubt diese direkte Sperrung nur für lokal signierte Zertifikate. Erscheint die Revoke-Aktion bei einem externen Zertifikat nicht, ist das kein UI-Fehler. Die externe CA muss das Zertifikat sperren und eine aktualisierte CRL ausstellen.

Wirkung der Sperrliste prüfen

Ein erfolgreicher Upload bestätigt nur, dass SFOS die Datei angenommen hat. Er beweist nicht allein, dass der gewünschte Dienst die CRL im konkreten Authentifizierungspfad auswertet. Eine belastbare Abnahme besteht deshalb aus mehreren Ebenen:

1. Datei: Issuer, Signatur, thisUpdate, nextUpdate und Seriennummer stimmen.
2. SFOS-Liste: Der erwartete CRL-Eintrag ist nach dem Speichern sichtbar.
3. Positivtest: Ein weiterhin gültiges Zertifikat derselben geplanten Vertrauenskette funktioniert.
4. Negativtest: Ein eigens ausgestelltes und gesperrtes Testzertifikat wird im Wartungsfenster abgelehnt.
5. Dienstlog: Zeitpunkt, Zertifikat und Ablehnungsgrund passen zum Test.
6. Betrieb: Nach einer CRL-Aktualisierung und nach einem geplanten HA-Failover wird eine neue Verbindung erneut geprüft.

Der passende Log hängt vom Dienst ab. Bei zertifikatsbasiertem IPsec ist charon.log eine wichtige Spur; die vollständige VPN-Analyse steht unter Sophos Firewall IPsec VPN Troubleshooting. Andere Funktionen verwenden andere Logs. Die Zuordnung zu access_server.log, sslvpn.log, csc.log oder weiteren Dateien beschreibt Sophos Firewall Service-Logs richtig zuordnen.

Packet Capture kann Verbindungsaufbau und Abbruch sichtbar machen, beweist aber nicht automatisch eine CRL-Entscheidung. Für diesen Nachweis sind Dienstlog, Zertifikatsdaten und der kontrollierte Testfall wichtiger.

CRLs im Betrieb aktuell halten

Eine CRL braucht einen Owner und einen Erneuerungsprozess. Besonders bei einer externen CA darf die Aktualisierung nicht von der Erinnerung einer einzelnen Person abhängen.

Sinnvolle Betriebsdaten sind:

• verantwortliches PKI- oder Firewall-Team;
• exakte CA und vertrauenswürdige Bezugsquelle;
• erwartetes Aktualisierungsintervall;
• nextUpdate der aktuell importierten Liste;
• betroffene Firewall-Dienste und Testfälle;
• letzter erfolgreicher Positiv- und Negativtest;
• Vorgehen für eine ausserplanmässige Sperrung nach Key-Kompromittierung.

Nach einer dringenden Zertifikatssperrung wartet man nicht bis zum normalen Review-Termin. Die externe CA stellt eine aktualisierte CRL bereit, die geprüft, importiert und am betroffenen Dienst abgenommen wird. Vor Änderungen an produktiven Zertifikaten bleibt ein aktuelles Firewall-Backup mit geprüftem Rückweg vorhanden.

In einem HA-Cluster wird nicht allein aus einem sichtbaren Eintrag auf beiden Nodes auf identisches Laufzeitverhalten geschlossen. Nach einem geplanten Failover wird eine frische Verbindung aufgebaut und das Log des Nodes geprüft, der den Test tatsächlich verarbeitet hat.

Fehler systematisch eingrenzen

SFOS lehnt die CRL-Datei ab

Zuerst auf dem Admin-Computer prüfen, ob die Datei wirklich eine CRL und ob sie DER- oder PEM-codiert ist. Ein umbenanntes Zertifikat, ein HTML-Download einer Portalfehlerseite oder ein beschädigtes Archiv ist keine gültige Sperrliste. Danach Issuer, Signatur und CA-Kette kontrollieren.

Die Datei nicht mit Online-Konvertern oder unbekannten Webseiten umwandeln. Falls ein anderes Format benötigt wird, erfolgt die Konvertierung lokal mit OpenSSL oder die CA liefert die CRL erneut im passenden Format.

Import funktioniert, das gesperrte Zertifikat aber weiterhin auch

Diese Punkte in Reihenfolge prüfen:

• Stammt Zertifikat und CRL wirklich von derselben Issuing CA?
• Steht die Seriennummer des Zertifikats in der CRL?
• Ist die CRL aktuell oder liegt nextUpdate bereits in der Vergangenheit?
• Stimmt die Firewallzeit?
• Verwendet der Test tatsächlich das erwartete Zertifikat und nicht ein anderes Zertifikat aus Cache, Profil oder Dienstzuweisung?
• Wurde eine neue Verbindung aufgebaut oder nur eine bestehende Sitzung weiterverwendet?
• Zeigt das dienstspezifische Log eine Zertifikats- oder Revocation-Prüfung?

Fehlt eine dieser Grundlagen, wird nicht mit Service-Restarts oder Änderungen an der Default CA experimentiert. Zuerst werden CA, Seriennummer, aktuelle CRL und echter Verbindungsweg bewiesen.

Ein externes Zertifikat lässt sich auf SFOS nicht sperren

Das ist die erwartete Produktgrenze. Die Firewall kann nur lokal signierte Zertifikate selbst sperren. Bei einem extern signierten Zertifikat wird die Sperrung beim externen CA-Betreiber ausgelöst und anschliessend dessen neue CRL importiert.

Nach einer lokalen Sperrung fällt ein Dienst aus

Zuerst über den vorbereiteten Management- oder Konsolenzugang arbeiten. Dem betroffenen Dienst wird ein zuvor geprüftes gültiges Ersatzzertifikat zugewiesen. Das gesperrte Zertifikat wird nicht wieder als produktive Lösung eingeplant. Danach Dienst, Logs und tatsächliche Zertifikatsausgabe erneut prüfen.

Wenn unklar ist, welche Dienste von der CA oder CRL abhängen, werden keine weiteren Zertifikate gesperrt und keine Sperrlisten gelöscht. Stattdessen Konfiguration, Zertifikatszuweisungen und Supportdaten sichern und den Fall mit PKI-Verantwortlichen oder Sophos Support eingrenzen.

FAQ