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, ein vorhandenes 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 Default 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 die aktuelle 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, thisUpdate sowie ein vorhandenes 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 beziehungsweise vor dem nächsten Termin gemäss CA-Publikationsintervall dokumentieren.

⚠️ Kein produktiv zugewiesenes Zertifikat nur für einen Funktionstest sperren und die Default CA dafür weder bearbeiten noch regenerieren. 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 Zeitpunkt, zu dem spätestens eine neue Liste erwartet wird; die ASN.1-Struktur erlaubt zwar ein fehlendes Feld, RFC-5280-konforme CRL-Aussteller müssen es aber setzen;
• 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 Default CA signiert. Es kann unter Certificates > Certificates gesperrt werden. SFOS trägt die Sperrung automatisch in die Default 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.

Wirkung und Abhängigkeiten vorab klären

Eine Sperrung veröffentlicht den Status einer Seriennummer. Sie löscht weder das Zertifikatsobjekt noch ersetzt sie ein Zertifikat, das einem Dienst zugewiesen ist. Wirksam wird die Sperrung erst dort, wo die prüfende Gegenstelle die passende aktuelle CRL tatsächlich auswertet. Die SFOS-22-Hilfe nennt für importierte CRLs keine vollständige Liste auswertender Dienste. Deshalb wird die Wirkung nie aus dem Import allein abgeleitet, sondern pro tatsächlichem Zertifikatspfad geprüft.

Vor einer lokalen Sperrung werden mindestens diese Abhängigkeiten inventarisiert:

• Unter Administration > Admin and user settings > Admin console and end-user interaction > Certificate teilen sich WebAdmin Console, User Portal, VPN Portal, Captive Portal sowie die beiden SPX-Portale eine Zertifikatsauswahl. Ist genau dieses Zertifikat betroffen, müssen alle verwendeten Portale in den Change- und Rückwegplan.
• SSL VPN, zertifikatsbasiertes IPsec, WAF, SMTP und API-Integrationen werden nur dann aufgenommen, wenn Konfiguration und Verbindungsprüfung eine tatsächliche Abhängigkeit vom Zertifikat, seiner CA oder der CRL zeigen.
• Auch externe Gegenstellen und Clients zählen: Ein exportiertes Profil oder ein Trust Store kann eine ältere CA oder CRL weiterverwenden, obwohl die Firewall-Liste aktuell aussieht.

Die konkreten Zuweisungsstellen und der sichere Zertifikatswechsel sind im verlinkten Artikel zum Zertifikatsmanagement beschrieben. Vor der Sperrung wird einem betroffenen Serverdienst zuerst ein gültiges Ersatzobjekt zugewiesen und mit einer neuen Verbindung geprüft. Bei Clientzertifikaten wird stattdessen ein neuer Clientnachweis ausgestellt, verteilt und positiv getestet.

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, vorhandenes nextUpdate und, falls vorhanden, die CRL-Nummer;
• 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. nextUpdate darf für den vorgesehenen Betriebszeitraum nicht bereits überschritten sein. Fehlt das Feld, gilt die Kompatibilität mit SFOS als ungeklärt: Beim PKI-Verantwortlichen wird eine korrigierte CRL angefordert; vor einem produktiven Import braucht es einen kontrollierten Test oder eine Bestätigung von Sophos Support.

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 beziehungsweise das CA-Publikationsintervall, 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 beziehungsweise vor dem nächsten Termin gemäss dokumentiertem Publikationsintervall der CA wird eine neue Liste bezogen, erneut geprüft und über den freigegebenen CRL-Prozess auf SFOS aktualisiert. Die zuvor freigegebene Datei bleibt als Nachweis erhalten, bis die neue Datei akzeptiert und der betroffene Dienst erneut geprüft wurde. Sie wird nicht als Rollback für eine wirksame Sperrung verwendet.

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 Default CRL 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.

Die dokumentierte SFOS-Oberfläche bietet für eine lokale Sperrung keinen Undo-Schritt. Deshalb ist das Ersatzobjekt der normale Rückweg für den Dienst; das gesperrte Zertifikat wird nicht wieder produktiv eingeplant. Ein vollständiger Backup-Restore ist wegen Neustart und Verlust späterer Änderungen nur der vorab bewertete letzte Rückweg, nicht die Routinekorrektur einer Sperrung. Bei einer externen CRL bleibt die zuvor freigegebene Datei erhalten. Falls die neue Liste nicht akzeptiert wird oder der Diensttest scheitert, wird der Rollout gestoppt und der dokumentierte Vorzustand beibehalten; bei unklarem Laufzeitstatus wird nicht gelöscht, sondern mit Belegen an Sophos Support eskaliert.

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, ein vorhandenes nextUpdate, eine vorhandene CRL-Nummer 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 oder das dokumentierte Publikationsintervall der CA;
• 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, liegt ein vorhandenes nextUpdate bereits in der Vergangenheit oder ist das dokumentierte Publikationsintervall überschritten?
• 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