Kontrolowane odnawianie Default CA na Sophos Firewall

Wbudowany urząd certyfikacji Default na Sophos Firewall nie jest zwykłym wpisem opisowym. Po zapisaniu jego ustawień SFOS automatycznie regeneruje CA. Powstaje nowy klucz, a tym samym nowy trust anchor. Dotychczasowe relacje zaufania nie dostosowują się do niego automatycznie.

Kontrolowane odnowienie nie zaczyna się więc od Save, lecz od pełnej listy zależności. Obejmuje ona lokalnie podpisane certyfikaty, WebAdmin i portale, profile SSL VPN, peery IPsec oparte na certyfikatach oraz systemy zewnętrzne, które ufają poprzedniemu CA.

⚠️ Ważne: CA Default należy odnawiać wyłącznie z wykorzystaniem sprawdzonego backupu, niezależnego dostępu administracyjnego, okna serwisowego i planu dla każdego zależnego serwisu. Kosmetyczna zmiana kraju, organizacji lub common name nie uzasadnia nieplanowanej regeneracji.

Odnawianie Default CA w dziesięciu krokach

1. Udokumentować przyczynę techniczną, właściciela zmiany, okno serwisowe i kryteria sukcesu.
2. Zidentyfikować wszystkie certyfikaty, serwisy, profile VPN, peery i klientów ufających bieżącemu CA Default.
3. Sprawdzić, czy rzeczywistym celem nie jest wyłącznie ApplianceCertificate albo oddzielny SecurityAppliance_SSL_CA.
4. Pozytywnie przetestować aktualny backup konfiguracji, SSMK, lokalny dostęp administratora i ścieżkę odzyskiwania.
5. Pobrać stary CA Default i zapisać jego fingerprint SHA-256, subject, numer seryjny oraz okres ważności.
6. Pisemnie zatwierdzić nowe dane CA, typ klucza i zgodność ze wszystkimi peerami.
7. W Certificates > Certificate authorities > Default wprowadzić przygotowane wartości i zapisać je dopiero w oknie serwisowym.
8. Pobrać nowy publiczny CA i w kontrolowany sposób rozprowadzić go do peerów, klientów i trust store’ów.
9. Oddzielnie przetestować WebAdmin, portale, SSL VPN, IPsec i każdy inny zależny serwis.
10. Udokumentować fingerprint, logi, wyniki testów i pozostałe stare profile. W przypadku błędu krytycznego użyć przygotowanej ścieżki odzyskiwania.

Rozróżnienie Default CA, ApplianceCertificate i Inspection CA

Sophos Firewall zawiera kilka obiektów o różnych zadaniach:

• Default: wewnętrzny CA dla lokalnie podpisanych certyfikatów.
• ApplianceCertificate: wbudowany certyfikat serwera używany domyślnie dla WebAdmin, portalu użytkownika i portalu przechwytującego. Jest podpisany przez CA Default i można go regenerować oddzielnie.
• SecurityAppliance_SSL_CA: oddzielny wbudowany CA do HTTPS Inspection i Re-Signing, jeśli został wybrany w konfiguracji TLS Inspection.

Obiektów tych nie wolno utożsamiać. Problem z pojedynczym ApplianceCertificate nie dowodzi uszkodzenia CA Default. Podobnie zmiana CA Default nie wykonuje automatycznie planowanej rotacji SecurityAppliance_SSL_CA.

Importowanie i przypisywanie certyfikatów na Sophos Firewall opisuje ogólną pracę z certyfikatami, kluczami prywatnymi, CSR i łańcuchami CA. Dla Inspection CA obowiązuje osobna procedura Dystrybucja certyfikatu CA dla HTTPS Scanning.

Kiedy regeneracja jest uzasadniona

Planowana zmiana może być konieczna, gdy:

• wcześniejszy klucz CA został w sposób potwierdzony lub prawdopodobny przejęty,
• CA traci ważność i nadal jest rzeczywiście używany produkcyjnie,
• tożsamość, typ klucza lub wymagania kryptograficzne są migrowane w sposób kontrolowany,
• Sophos Support wymaga regeneracji dla potwierdzonego problemu.

Pojedynczy nieudany download VPN, ostrzeżenie przeglądarki bez analizy łańcucha, kosmetyczna zmiana subject lub stara komenda z forum nie są wystarczającymi powodami. W przypadku problemu z .ovpn i ApplianceCertificate należy najpierw systematycznie sprawdzić pobieranie konfiguracji SSL VPN.

Inwentaryzacja zależności przed zmianą

Certyfikaty i przypisane serwisy

W Certificates > Certificates należy zapisać co najmniej nazwę, subject, issuer, ważność i rzeczywiste przypisanie każdego lokalnie podpisanego certyfikatu. W zależności od środowiska dotyczy to:

• WebAdmin, portalu użytkownika i portalu przechwytującego,
• certyfikatu serwera SSL VPN,
• IPsec site-to-site i remote access z Digital certificate,
• WAF, SMTP, API lub innych serwisów TLS,
• samodzielnie wygenerowanych certyfikatów klienta lub serwera poza firewallem.

Widoczny certyfikat nie jest automatycznie zależnością. Liczy się to, czy używa go serwis produkcyjny i czy peer ufa wystawiającemu CA Default.

Systemy ufające i ścieżki dystrybucji

Należy również udokumentować:

• przeglądarki i systemy operacyjne z zaimportowanym starym CA,
• MDM, GPO lub dystrybucję oprogramowania dla nowego CA,
• peery IPsec z zaimportowanym Default.pem, Remote CA lub mapowaniem DN,
• użytkowników SSL VPN i ścieżkę dystrybucji nowych profili .ovpn,
• monitoring, klientów API lub integracje korzystające z certificate pinning,
• dostęp administracyjny HA, awaryjny i zewnętrzny.

Jeśli nie wiadomo, kto rozprowadził poprzedni CA lub które peery mu ufają, zmianę należy zatrzymać.

Zabezpieczenie stanu początkowego i ścieżki odzyskiwania

Przed oknem serwisowym należy pobrać CA Default w Certificates > Certificate authorities. Archiwum zawiera część publiczną, ale nie automatycznie oddzielny, użyteczny eksport klucza prywatnego.

Dane PEM można sprawdzić tylko do odczytu na komputerze administratora:

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

Dla pliku DER należy określić format wejściowy:

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

Fingerprint i wynik należy zapisać w stanie początkowym wraz z nazwą firewalla, numerem seryjnym, buildem SFOS i ticketem zmiany. Plików certyfikatów i wewnętrznych danych PKI nie należy dołączać bez zabezpieczenia do publicznych zgłoszeń.

Należy także zewnętrznie zachować aktualny backup Sophos Firewall wraz z hasłem i SSMK. Restore zastępuje całą konfigurację, restartuje firewall i może wycofać późniejsze zmiany. Jest to ostatnia planowana ścieżka odzyskiwania, a nie szybka funkcja cofania dla CA.

Przygotowanie okna serwisowego

Przed Save wszystkie poniższe punkty muszą być potwierdzone:

• lokalne konto admin lub drugi administrator przetestowany z sieci zarządzającej,
• dostępna konsola lub inna niezależna ścieżka odzyskiwania,
• nowe wartości CA i kryptografia zgodne ze wszystkimi systemami peer,
• dostępni właściciele peerów VPN, MDM/GPO i portali,
• przygotowane nowe profile, dystrybucja do trust store’ów i konta testowe,
• wystarczający czas na pełny restore backupu, jeśli będzie potrzebny.

W klastrze HA obsługiwaną zmianę WebAdmin należy wykonać na bieżącym Primary. SFOS nie dokumentuje nieprzerwanej ciągłości CA ani sesji dla tej zmiany. Po planowanym failoverze należy więc ponownie sprawdzić nowe logowania i wszystkie serwisy krytyczne. Nie należy edytować CA niezależnie na obu nodes.

Aktualizacja Default CA w SFOS

1. Otworzyć Certificates > Certificate authorities.
2. Kliknąć Default. Samej nazwy nie można zmienić.
3. Sprawdzić Country, State, Locality, Organization, Organizational unit, Common name i adres e-mail.
4. W Private key settings świadomie wybrać RSA lub Elliptic curve, odpowiednią długość klucza albo krzywą oraz Secure hash.
5. Porównać wartości z ticketem zmiany i listą zgodności.
6. Kliknąć Save wyłącznie w oknie serwisowym.

Przykładowe wartości CH, Zurich, Example AG, IT Security, fw01.example.com i pki@example.com są wyłącznie danymi dokumentacyjnymi. Należy zastąpić je własną organizacją, rzeczywistym odniesieniem do firewalla i zatwierdzoną konwencją nazewnictwa PKI.

⚠️ Save jest punktem przełączenia. SFOS automatycznie regeneruje CA Default. Ponowne wprowadzenie wcześniejszych wartości subject nie przywraca starego klucza ani fingerprintu.

Bezpośrednio potem należy pobrać nowy CA Default i wykonać tę samą kontrolę OpenSSL. Po regeneracji oczekiwany jest nowy fingerprint SHA-256. Nieoczekiwane pola, błąd pobierania lub stan, którego nie można udokumentować, są warunkami zatrzymania.

Kontrolowana migracja zależnych serwisów

WebAdmin i portale

W Administration > Admin and user settings należy sprawdzić, który certyfikat wybrano dla WebAdmin, portalu użytkownika i portalu przechwytującego. Jeśli używany jest lokalnie podpisany certyfikat z nowym CA, klienci uzyskujący dostęp muszą ufać nowemu CA.

Podczas testu należy pozostawić otwartą istniejącą sesję Full Admin. Nowe prywatne okna przeglądarki testują FQDN, łańcuch certyfikatu i logowanie z planowanego źródła zarządzania. Komenda CLI resetująca certyfikat WebAdmin do domyślnego certyfikatu urządzenia nie jest rollbackiem starego klucza CA.

SSL VPN

Jeśli SSL VPN używa ApplianceCertificate lub innego lokalnie podpisanego certyfikatu serwera, po zmianie ustawień CA Default użytkownicy muszą pobrać i zaimportować nowy plik .ovpn. Istniejąca nazwa pliku ani zielony status tunelu ze starym profilem nie są wystarczającą walidacją.

Co najmniej jeden użytkownik pilotażowy pobiera nowy profil przez planowaną ścieżkę portalu, ustanawia świeże połączenie i testuje DNS, trasy oraz rzeczywisty ruch aplikacyjny. Stare profile należy wycofać z dystrybucji dopiero po udanej migracji wszystkich użytkowników.

Peery IPsec oparte na certyfikatach

W przypadku Digital certificate peery Sophos Firewall wymieniają swoje certyfikaty CA. Jeśli peer wcześniej importował zdalny Default.pem, nowy publiczny CA należy w kontrolowany sposób zastąpić lub dodać na peerze i ponownie sprawdzić mapowanie.

Pełna konfiguracja połączenia pozostaje w artykule Konfiguracja IPsec site-to-site na Sophos Firewall. Przy zmianie CA należy przetestować co najmniej zestawienie IKE, Child SA, oba kierunki ruchu i rzeczywiste aplikacje. Sam zielony tunel nie potwierdza ścieżki powrotnej.

HTTPS Inspection i inne ścieżki podpisywania

Dla HTTPS Inspection należy najpierw ustalić Signing CA faktycznie wybrany w Web > General settings. Jeśli jest to SecurityAppliance_SSL_CA lub zewnętrzny CA, nie należy go ponownie dystrybuować tylko dlatego, że CA Default został zregenerowany.

Ścieżkę podpisywania należy włączyć do zmiany wyłącznie wtedy, gdy potwierdzono, że korzysta ze zmienionego CA Default lub zależnego certyfikatu. Dzięki temu zmiany trust store’ów ograniczają się do rzeczywiście dotkniętych endpointów.

Sprawdzenie wyniku i logów

Walidacja oddziela konfigurację od działania:

1. Pobrać nowy CA i udokumentować subject, issuer, numer seryjny, ważność oraz fingerprint SHA-256.
2. W Certificates > Certificates sprawdzić issuer, Trusted i odpowiednie obiekty certyfikatów.
3. Oddzielnie przetestować WebAdmin, portale, SSL VPN, IPsec i inne przypisane serwisy.
4. W vpncertificate.log sprawdzić operację CA i certyfikatu z czasu zmiany.
5. W configuration-audit.log sprawdzić administratora, czas i obsługiwane dane przed/po.
6. W odpowiednich logach serwisów korelować tylko błędy i sukcesy należące do testu.

Śledzenie zmian konfiguracji za pomocą configuration-audit.log objaśnia audit trail. Nie każdy serwis zapisuje ten sam poziom szczegółów w configuration-audit.log, dlatego walidacja funkcjonalna pozostaje obowiązkowa.

Rollback i warunki zatrzymania

Zregenerowany CA nie ma prostego przełącznika Undo. Ponowne zapisanie poprzedniego tekstu nie przywraca starego klucza prywatnego.

Dlatego ścieżkę odzyskiwania należy wcześniej określić dla każdego serwisu:

• utrzymać niezależny dostęp administracyjny i istniejącą sesję administratora,
• przełączyć portale z powrotem na wcześniej zweryfikowany, niezależny certyfikat zewnętrzny, jeśli jest dostępny i można go bezpiecznie przypisać,
• przywracać zaufanie peerów i profile klientów tylko zgodnie z udokumentowanym stanem poprzednim,
• pełnego restore backupu używać tylko wtedy, gdy akceptowane są skutki, restart, SSMK i utrata późniejszych zmian,
• eskalować do Sophos Support z dowodami, gdy zależność jest nieznana lub stanu certyfikatu nie można odtworzyć.

Nie należy wykonywać zmian bazy danych w shellu, masowo usuwać certyfikatów, restartować serwisów ani ponownie regenerować CA na podstawie podejrzenia. Zmianę należy zatrzymać, jeśli nie można skoordynować krytycznego peera, nowy trust anchor nie został rozprowadzony albo ścieżka odzyskiwania nie została pozytywnie przetestowana.

Typowe błędy po regeneracji

Przeglądarka zgłasza niezaufane połączenie

Sprawdzić łańcuch certyfikatów rzeczywiście dostarczany dla FQDN. Jeśli certyfikat serwera jest podpisany przez nowy CA Default, dokładnie ten CA musi znajdować się w trust store. Nie importować bez potrzeby SecurityAppliance_SSL_CA.

SSL VPN nie łączy się już ze starym profilem

Skorelować wybrany certyfikat serwera SSL, nowy CA, pobieranie z portalu i sslvpn.log. Pobrać nowy plik .ovpn i zaimportować go jako nowy profil. Stare i nowe profile rozróżniać na podstawie certyfikatu i udanego połączenia, a nie nazwy pliku.

IPsec pozostaje down po zmianie CA

Po obu stronach sprawdzić import CA, status Trusted, Local/Remote certificate, ID i strongswan.log. Przy DER ASN1 DN zmiana subject CA może również wpłynąć na tożsamość. Nie poluzowywać profili ani ID na podstawie podejrzenia.

HTTPS Inspection pokazuje błędy certyfikatów

Najpierw sprawdzić faktycznie wybrany Signing CA. Jeśli SecurityAppliance_SSL_CA jest nadal używany i nie został zmieniony, błąd nie wynika automatycznie z nowego CA Default. Oddzielnie zbadać łańcuch certyfikatu, Decryption Rule i zaufanie endpointu.

Lista kontrolna

• Przyczyna i zakres regeneracji CA są udokumentowane.
• Stary CA, fingerprint, backup, hasło i SSMK są zabezpieczone.
• Wszystkie certyfikaty, serwisy, peery, klienci i ścieżki dystrybucji są zinwentaryzowane.
• Default, ApplianceCertificate i SecurityAppliance_SSL_CA oceniono oddzielnie.
• Okno serwisowe, administracyjna ścieżka odzyskiwania i osoby odpowiedzialne są gotowe.
• Nowe wartości CA i kryptografia są zgodne ze wszystkimi peerami.
• CA zapisano wyłącznie w zatwierdzonym oknie i następnie pobrano.
• WebAdmin, portale, SSL VPN, IPsec i inne serwisy przetestowano oddzielnie.
• Zabezpieczono vpncertificate.log, configuration-audit.log i logi serwisów.
• Rollback lub eskalacja do supportu są możliwe bez niekontrolowanych zmian w shellu.

FAQ