Importowanie CRL i unieważnianie certyfikatów na Sophos Firewall

Zewnętrzną Certificate Revocation List (CRL) importuje się w sekcji Certificates > Certificate revocation lists > Add. Plik musi pochodzić z urzędu certyfikacji, który wydał dany certyfikat. Przed przesłaniem należy sprawdzić issuer, podpis, thisUpdate, ewentualne nextUpdate oraz unieważnione numery seryjne. Widoczny wpis na liście nie jest później wystarczającym dowodem: konkretną usługę trzeba przetestować z ważnym certyfikatem oraz, w kontrolowanym środowisku testowym, z unieważnionym certyfikatem.

W przypadku certyfikatów podpisanych lokalnie procedura wygląda inaczej. SFOS może je samodzielnie unieważnić i automatycznie dodaje ich dane do CRL Default. Certyfikat podpisany zewnętrznie musi natomiast zostać unieważniony przez zewnętrzny urząd certyfikacji; firewall nie może samodzielnie utworzyć takiego unieważnienia.

Importowanie CRL w ośmiu krokach

1. Udokumentować dany certyfikat, issuer, numer seryjny i korzystającą z niego usługę firewalla.
2. Przygotować kopię zapasową, niezależny dostęp administracyjny i ważny certyfikat zastępczy.
3. Pobrać od wystawiającego urzędu certyfikacji aktualną CRL. Nie używać CRL z innego urzędu certyfikacji o podobnej nazwie.
4. Na komputerze administratora odczytać plik jako DER lub PEM i sprawdzić issuer, podpis, thisUpdate oraz ewentualną wartość nextUpdate.
5. Potwierdzić, że odpowiedni łańcuch CA znajduje się w Certificates > Certificate authorities.
6. W Certificates > Certificate revocation lists > Add wpisać jednoznaczną nazwę, wybrać plik CRL i kliknąć Save.
7. Wykonać zwykły test pozytywny z nadal ważnym certyfikatem oraz kontrolowany test negatywny z unieważnionym certyfikatem testowym.
8. Udokumentować właściciela, źródło i termin odnowienia przed nextUpdate albo przed następnym terminem w harmonogramie publikacji CA.

⚠️ Nie unieważniać certyfikatu przypisanego do produkcji wyłącznie w celu przetestowania funkcji ani nie edytować i nie regenerować w tym celu CA Default. Może to spowodować awarię WebAdmin, portali, VPN, innych usług administracyjnych lub tuneli. Unieważnienie należy najpierw sprawdzić za pomocą certyfikatu wystawionego specjalnie do tego celu i z potwierdzoną drogą odzyskiwania dostępu.

Rozróżnianie wygaśnięcia i unieważnienia

Certyfikat może być ważny jeszcze przez wiele miesięcy, a mimo to nie być już godny zaufania. Dzieje się tak na przykład wtedy, gdy private key został przejęty, właściciel utracił uprawnienia lub certyfikat nie może być już używany zgodnie z pierwotnym przeznaczeniem. Urząd certyfikacji unieważnia wtedy numer seryjny i publikuje ten status w CRL.

CRL zawiera między innymi:

• Issuer, czyli podmiot, który podpisał CRL;
• thisUpdate, czas wydania tej listy;
• nextUpdate, najpóźniejszy termin, w którym oczekiwana jest nowa lista; chociaż struktura ASN.1 dopuszcza brak tego pola, wystawcy CRL zgodni z RFC 5280 muszą je uwzględniać;
• numer seryjny i czas unieważnienia cofniętych certyfikatów;
• podpis cyfrowy umożliwiający sprawdzenie pochodzenia i integralności.

Sama nazwa pliku nie stanowi podstawy zaufania. Plik o nazwie vpn-current.crl może być nieaktualny lub należeć do innego issuing CA. Liczą się issuer, podpis, aktualność i numer seryjny konkretnego certyfikatu.

Podpis lokalny lub zewnętrzny

SFOS rozdziela dwa zakresy odpowiedzialności:

• Certyfikat podpisany lokalnie: Firewall podpisał certyfikat przy użyciu wewnętrznego CA Default. Można go unieważnić w Certificates > Certificates. SFOS automatycznie dodaje unieważnienie do CRL Default.
• Certyfikat podpisany zewnętrznie: Certyfikat został wydany przez zewnętrzny firmowy lub publiczny urząd certyfikacji. Tylko ten urząd może opublikować unieważnienie. Aktualny plik CRL jest następnie przesyłany do firewalla.

CRL dostarczona zewnętrznie nie zastępuje odpowiedniego łańcucha CA. Certyfikat, issuing CA, ewentualne intermediate CA i CRL muszą do siebie pasować. Artykuł Importowanie i przypisywanie certyfikatów na Sophos Firewall wyjaśnia różnice między certyfikatami, private keys, CSR i łańcuchami CA.

Najpierw ustalenie skutków i zależności

Unieważnienie publikuje status numeru seryjnego. Nie usuwa obiektu certyfikatu ani nie zastępuje certyfikatu przypisanego do usługi. Działa dopiero tam, gdzie strona weryfikująca certyfikat rzeczywiście sprawdza odpowiednią aktualną CRL. Pomoc SFOS 22 nie zawiera pełnej listy usług sprawdzających zaimportowane CRL. Dlatego nie należy wnioskować o egzekwowaniu unieważnienia na podstawie samego importu, lecz potwierdzić je dla każdej rzeczywistej ścieżki certyfikatu.

Przed lokalnym unieważnieniem należy zinwentaryzować co najmniej następujące zależności:

• W Administration > Admin and user settings > Admin console and end-user interaction > Certificate WebAdmin Console, User Portal, VPN Portal, Captive Portal oraz oba portale SPX korzystają z jednego wyboru certyfikatu. Jeśli to dany certyfikat, każdy używany portal musi znaleźć się w planie zmiany i odzyskiwania.
• SSL VPN, IPsec oparty na certyfikatach, WAF, SMTP i integracje API należy uwzględniać tylko wtedy, gdy konfiguracja i kontrola połączenia potwierdzają rzeczywistą zależność od certyfikatu, jego CA lub CRL.
• Należy uwzględnić także zewnętrzne peery i klientów. Wyeksportowany profil lub trust store może nadal używać starszej CA albo CRL, mimo że lista na firewallu wygląda na aktualną.

Powiązany artykuł o zarządzaniu certyfikatami wskazuje konkretne miejsca przypisania i bezpieczną procedurę zmiany certyfikatu. Przed unieważnieniem należy przypisać objętej usłudze serwerowej ważny obiekt zastępczy i sprawdzić go przy użyciu nowego połączenia. W przypadku certyfikatów klienta trzeba zamiast tego wystawić i rozprowadzić nowe poświadczenie klienta oraz wykonać test pozytywny.

Bezpieczne przygotowanie pliku CRL

Przed zmianą należy zapisać aktualny stan:

• nazwę, issuer i numer seryjny danego certyfikatu;
• wystawcę CRL i zaufane źródło;
• aktualną wartość thisUpdate, ewentualne nextUpdate i, jeśli występuje, numer CRL;
• objętą zmianą usługę i jej działający test pozytywny;
• odpowiedzialnego właściciela PKI;
• kopię zapasową i drogę odzyskiwania dostępu na wypadek zablokowania dostępu produkcyjnego przez walidację certyfikatu.

Czas firewalla musi być prawidłowy. Błędna data może sprawić, że certyfikaty i listy unieważnień będą wyglądać na nieaktualne lub jeszcze nieważne. W razie potrzeby źródło czasu i konfigurację NTP można sprawdzić zgodnie z artykułem Konfigurowanie czasu systemowego i NTP na Sophos Firewall.

Dopasowanie certyfikatu i CRL

Na komputerze administratora OpenSSL wyświetla issuer i numer seryjny certyfikatu PEM:

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

client-cert.pem należy zastąpić lokalnym plikiem certyfikatu. Polecenie odczytuje tylko metadane i nie wyświetla private key.

CRL zakodowaną w DER sprawdza się następująco:

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

Dla CRL zakodowanej w PEM należy zastąpić DER wartością PEM. corp-issuing-ca.crl jest przykładową nazwą i należy ją zastąpić plikiem własnego issuing CA. Wyświetlony issuer musi pasować do planowanego łańcucha certyfikatów. Termin nextUpdate nie może być przekroczony dla planowanego okresu eksploatacji. Jeśli pola nie ma, zgodność z SFOS pozostaje niepotwierdzona: należy poprosić właściciela PKI o poprawioną CRL i nie importować jej produkcyjnie, dopóki kontrolowany test lub Sophos Support nie potwierdzi zgodności.

Sprawdzanie podpisu i unieważnionych numerów seryjnych

Podpis sprawdza się względem przygotowanego pliku CA:

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

corp-ca-chain.pem zawiera certyfikat podmiotu podpisującego CRL oraz łańcuch CA potrzebny do jego weryfikacji. Plik dostarcza osoba odpowiedzialna za PKI; nie należy składać go z przypadkowych źródeł pobierania. Jeśli urząd certyfikacji dostarcza CRL w formacie PEM, również tutaj należy zastąpić DER wartością PEM.

Pełne dane CRL wraz z unieważnionymi numerami seryjnymi można wyświetlić poleceniem:

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

W przypadku dużych firmowych urzędów certyfikacji wynik może być długi. Nie zawiera on private key, ale zawiera wewnętrzne metadane PKI i numery seryjne. Dlatego niefiltrowanego wyniku nie należy wklejać do publicznych zgłoszeń, czatów ani zrzutów ekranu.

Importowanie zewnętrznej CRL do SFOS

Zewnętrzną CRL należy pozyskiwać wyłącznie od odpowiedzialnego urzędu certyfikacji lub z jego zaufanego procesu PKI. Plik ze starego zgłoszenia lub nieudokumentowanego udziału plikowego nie jest wiarygodnym źródłem.

1. Otworzyć Certificates > Certificate revocation lists.
2. Wybrać Add.
3. Wpisać jednoznaczną nazwę, na przykład Corp-Issuing-CA-CRL.
4. Wybrać wcześniej sprawdzony plik .crl.
5. Kliknąć Save.
6. Potwierdzić, że nowy wpis pojawia się na liście CRL.
7. Wykonać zaplanowane testy pozytywny i negatywny danej usługi.
8. Zapisać nextUpdate lub interwał publikacji CA, właściciela i źródło w dokumentacji operacyjnej.

Corp-Issuing-CA-CRL jest tylko nazwą przykładową. Należy ją zastąpić nazwą wskazującą rzeczywisty issuing CA i przeznaczenie. Nie należy stosować nazw takich jak Current lub New CRL, ponieważ po kilku miesiącach nie wskazują już jednoznacznego właściciela.

Aktualna pomoc SFOS 22 nie dokumentuje na tej stronie automatycznego pobierania przez adres URL HTTP lub LDAP. Jednorazowe przesłanie nie jest więc trwałym procesem operacyjnym. Przed nextUpdate albo przed następnym terminem w udokumentowanym harmonogramie publikacji CA należy pobrać nową listę, ponownie ją sprawdzić i zaktualizować na SFOS w ramach zatwierdzonego procesu CRL. Poprzednio zatwierdzony plik należy zachować jako dowód, dopóki nowy plik nie zostanie zaakceptowany, a dana usługa ponownie przetestowana. Nie wolno używać go do cofnięcia skutecznego unieważnienia.

Unieważnianie lokalnie podpisanego certyfikatu

Lokalnie podpisany certyfikat unieważnia się bezpośrednio na firewallu. Najpierw trzeba ustalić, czy nadal chroni WebAdmin, portal, VPN, WAF, SMTP lub inną usługę. Jeśli tak, należy najpierw przypisać i przetestować ważny certyfikat zastępczy.

1. W Certificates > Certificates zidentyfikować lokalnie podpisany certyfikat.
2. Ponownie sprawdzić subject, issuer, przeznaczenie i przypisanie do usługi.
3. Potwierdzić kopię zapasową i niezależny dostęp administracyjny.
4. W wierszu certyfikatu wykonać akcję revoke dokładnie dla tego certyfikatu.
5. W Certificates > Certificate revocation lists znaleźć CRL Default.
6. Wybrać Download. SFOS udostępnia archiwum .tar, z którego wyodrębnia się plik .crl.
7. Odczytać pobraną CRL za pomocą OpenSSL i porównać numer seryjny certyfikatu testowego.
8. Ponownie wykonać pozytywny i negatywny test właściwej usługi.

Sophos pozwala na takie bezpośrednie unieważnienie wyłącznie w przypadku lokalnie podpisanych certyfikatów. Brak akcji revoke przy certyfikacie zewnętrznym nie jest błędem interfejsu. Zewnętrzny urząd certyfikacji musi unieważnić certyfikat i wydać zaktualizowaną CRL.

Udokumentowany interfejs SFOS nie oferuje cofnięcia lokalnego unieważnienia. Obiekt zastępczy jest więc normalną drogą odzyskania usługi; unieważnionego certyfikatu nie należy ponownie wdrażać produkcyjnie. Pełne odtworzenie kopii zapasowej uruchamia firewall ponownie i może usunąć późniejsze zmiany, dlatego jest tylko wcześniej ocenionym rozwiązaniem ostatniej szansy, a nie rutynową korektą. W przypadku zewnętrznej CRL należy zachować wcześniej zatwierdzony plik. Jeśli nowa lista zostanie odrzucona lub test usługi zakończy się niepowodzeniem, należy zatrzymać wdrożenie i zachować udokumentowany poprzedni stan. Gdy stan runtime jest niejasny, nie należy usuwać wpisów, lecz przekazać dowody do Sophos Support.

Sprawdzanie działania listy unieważnień

Udane przesłanie potwierdza tylko, że SFOS zaakceptował plik. Nie dowodzi samo w sobie, że właściwa usługa sprawdza CRL w konkretnym procesie uwierzytelniania. Wiarygodny test odbiorczy składa się więc z kilku warstw:

1. Plik: Issuer, podpis, thisUpdate, ewentualne nextUpdate, ewentualny numer CRL i numer seryjny są prawidłowe.
2. Lista SFOS: Oczekiwany wpis CRL jest widoczny po zapisaniu.
3. Test pozytywny: Nadal ważny certyfikat z planowanego łańcucha zaufania działa.
4. Test negatywny: Specjalnie wystawiony i unieważniony certyfikat testowy zostaje odrzucony w oknie serwisowym.
5. Log usługi: Czas, certyfikat i przyczyna odrzucenia odpowiadają testowi.
6. Eksploatacja: Po aktualizacji CRL i po planowanym failover HA należy ponownie zestawić i sprawdzić nowe połączenie.

Właściwy log zależy od usługi. W przypadku IPsec opartego na certyfikatach ważnym śladem jest charon.log; pełna analiza VPN znajduje się w artykule Rozwiązywanie problemów z IPsec VPN na Sophos Firewall. Inne funkcje korzystają z innych logów. Artykuł Prawidłowe przypisywanie logów usług Sophos Firewall przyporządkowuje funkcje do access_server.log, sslvpn.log, csc.log i innych plików.

Packet Capture może pokazać zestawienie i przerwanie połączenia, ale nie dowodzi automatycznie decyzji CRL. Dla takiego dowodu ważniejsze są log usługi, dane certyfikatu i kontrolowany przypadek testowy.

Utrzymywanie aktualnych CRL

CRL potrzebuje właściciela i procesu odnawiania. Zwłaszcza w przypadku zewnętrznego urzędu certyfikacji aktualizacja nie może zależeć od pamięci jednej osoby.

Przydatne dane operacyjne obejmują:

• odpowiedzialny zespół PKI lub firewall;
• dokładny urząd certyfikacji i zaufane źródło;
• oczekiwany interwał aktualizacji;
• nextUpdate aktualnie zaimportowanej listy lub udokumentowany interwał publikacji CA;
• objęte usługi firewalla i przypadki testowe;
• ostatni udany test pozytywny i negatywny;
• procedurę nieplanowanego unieważnienia po przejęciu key.

Po pilnym unieważnieniu certyfikatu nie należy czekać do zwykłego terminu przeglądu. Zewnętrzny urząd certyfikacji dostarcza zaktualizowaną CRL, którą trzeba sprawdzić, zaimportować i przetestować w odpowiedniej usłudze. Przed zmianą certyfikatów produkcyjnych należy zachować aktualną kopię zapasową firewalla ze sprawdzoną drogą odzyskiwania.

W klastrze HA nie należy wnioskować o identycznym działaniu tylko na podstawie wpisu widocznego na obu węzłach. Po planowanym failover należy ustanowić nowe połączenie i sprawdzić log na węźle, który faktycznie przetwarzał test.

Systematyczne zawężanie błędów

SFOS odrzuca plik CRL

Najpierw na komputerze administratora należy sprawdzić, czy plik rzeczywiście jest CRL i czy został zakodowany jako DER lub PEM. Certyfikat ze zmienioną nazwą, pobrana strona HTML z błędem portalu albo uszkodzone archiwum nie są prawidłową listą unieważnień. Następnie należy sprawdzić issuer, podpis i łańcuch CA.

Nie należy konwertować pliku za pomocą konwerterów online ani nieznanych stron internetowych. Jeśli potrzebny jest inny format, konwersję należy wykonać lokalnie za pomocą OpenSSL albo poprosić urząd certyfikacji o ponowne dostarczenie CRL w wymaganym formacie.

Import działa, ale unieważniony certyfikat również

Sprawdzić kolejno:

• Czy certyfikat i CRL rzeczywiście pochodzą z tego samego issuing CA?
• Czy numer seryjny certyfikatu znajduje się w CRL?
• Czy CRL jest aktualna, czy ewentualne nextUpdate znajduje się już w przeszłości albo upłynął udokumentowany interwał publikacji?
• Czy czas firewalla jest prawidłowy?
• Czy test rzeczywiście używa oczekiwanego certyfikatu, a nie innego certyfikatu z pamięci podręcznej, profilu lub przypisania usługi?
• Czy zestawiono nowe połączenie, czy jedynie kontynuowano istniejącą sesję?
• Czy log właściwy dla usługi pokazuje sprawdzanie certyfikatu lub revocation?

Jeśli brakuje którejkolwiek z tych podstaw, nie należy eksperymentować z restartami usług ani zmianami Default CA. Najpierw trzeba potwierdzić CA, numer seryjny, aktualną CRL i rzeczywisty tor połączenia.

Zewnętrznego certyfikatu nie można unieważnić na SFOS

Jest to oczekiwane ograniczenie produktu. Firewall może samodzielnie unieważniać tylko lokalnie podpisane certyfikaty. W przypadku certyfikatu podpisanego zewnętrznie trzeba zlecić unieważnienie zewnętrznemu urzędowi certyfikacji, a następnie zaimportować jego nową CRL.

Usługa przestaje działać po lokalnym unieważnieniu

Najpierw należy skorzystać z przygotowanego dostępu administracyjnego lub konsolowego. Do danej usługi przypisać wcześniej sprawdzony ważny certyfikat zastępczy. Unieważnionego certyfikatu nie należy ponownie planować jako rozwiązania produkcyjnego. Następnie ponownie sprawdzić usługę, logi i faktycznie prezentowany certyfikat.

Jeśli nie wiadomo, które usługi zależą od CA lub CRL, nie należy unieważniać kolejnych certyfikatów ani usuwać list unieważnień. Zamiast tego trzeba zabezpieczyć konfigurację, przypisania certyfikatów i dane wsparcia oraz przeanalizować przypadek z osobami odpowiedzialnymi za PKI lub z Sophos Support.

FAQ