Konfiguracja podrzędnego urzędu CA do inspekcji TLS na Sophos Firewall

Na potrzeby inspekcji TLS Sophos Firewall musi ponownie podpisywać certyfikaty odwiedzanych miejsc docelowych HTTPS. Zamiast wbudowanego CA SecurityAppliance_SSL_CA można użyć dedykowanego podrzędnego firmowego CA. Zarządzane klienty nadal ufają wtedy własnemu głównemu CA organizacji, a klucz prywatny podrzędnego CA pozostaje na firewallu.

Bezpieczna procedura obejmuje sześć kroków:

1. Wygenerować na Sophos Firewall żądanie CSR dla nowego podrzędnego CA.
2. Zlecić podpisanie CSR przez Enterprise CA Microsoft AD CS przy użyciu szablonu Subordinate Certification Authority.
3. Zaimportować wystawiony certyfikat CA bezpośrednio przy istniejącym CSR.
4. Dodać odpowiedni główny CA do firewalla jako Validation only.
5. Wybrać podrzędny CA jako CA do ponownego podpisywania i początkowo używać go tylko w regule pilotażowej.
6. Sprawdzić łańcuch certyfikatów, rzeczywisty ruch HTTPS, logi i wycofanie zmiany.

⚠️ CA do ponownego podpisywania może wystawiać certyfikaty dla obcych domen. Jego klucz prywatny jest zatem szczególnie wrażliwy. CA może być używany wyłącznie w przeznaczonej ścieżce inspekcji i nie może być eksportowany ani przekazywany w zgłoszeniach. Bez sprawdzonej drogi odzyskiwania nie należy aktywować go produkcyjnie.

Ta procedura jest opisana dla AD CS w trybie Enterprise CA. Sophos wyraźnie zaznacza, że udokumentowana metoda nie dotyczy Standalone CA. Inna wewnętrzna infrastruktura PKI również może wystawić podrzędny CA, wymaga jednak własnej procedury zatwierdzonej przez właściciela PKI.

Alternatywnie CSR i CA można wygenerować narzędziem zewnętrznym, takim jak OpenSSL. Wygenerowane zewnętrznie podrzędne i główne CA przesyła się w Certificates > Certificate authorities; CA podpisujący bez pasującego CSR na firewallu wymaga również swojego klucza prywatnego przekazanego zgodnie z zatwierdzonym procesem PKI. Główny CA pozostaje bez klucza prywatnego. Jest to inna ścieżka przesyłania kluczy, a nie opisany poniżej import CSR. Podrzędny CA może też służyć do konfiguracji TLS poczty elektronicznej; poniższa aktywacja i weryfikacja dotyczą tylko ruchu WWW i nie aktywują konfiguracji TLS poczty.

Kiedy podrzędny CA ma sens

Własny podrzędny CA sprawdza się przede wszystkim w zarządzanych sieciach firmowych, w których klienty już ufają wewnętrznemu głównemu CA. Dzięki temu nie trzeba dystrybuować na każde urządzenie dodatkowej, niezależnej kotwicy zaufania Sophos. Rotację, unieważnianie i odpowiedzialność można włączyć w istniejące zasady zarządzania PKI.

Rozwiązanie nie jest jednak automatycznie prostsze. Firewall otrzymuje klucz pozwalający podpisywać certyfikaty na potrzeby inspekcji TLS. CA musi więc mieć ściśle określony cel, udokumentowanych właścicieli, ograniczony okres ważności oraz sprawdzone procedury unieważniania i odnawiania.

W mniejszych środowiskach bez własnej PKI wbudowany CA Sophos jest często prostszym rozwiązaniem. Dystrybucja certyfikatu CA Sophos Firewall do inspekcji TLS opisuje jego wybór i wdrożenie na klientach. Prawidłowe wdrożenie inspekcji TLS na Sophos Firewall przedstawia cały proces pilotażowy i obsługę wyjątków.

Przygotowanie projektu CA i drogi odzyskiwania

Przed utworzeniem CSR należy określić przeznaczenie, nazwy i zależności. Przykład:

• nazwa obiektu SFOS: SFOS-TLS-Inspection-SubCA-2026
• Common Name: SFOS TLS Inspection SubCA 2026
• wystawiający główny CA: Example Enterprise Root CA
• planowane użycie: wyłącznie inspekcja TLS i deszyfrowanie HTTPS na FW01
• sieć pilotażowa: 10.20.30.0/24

Są to wartości przykładowe i należy je zastąpić własną konwencją nazewnictwa, PKI oraz grupą pilotażową. Osobny CA dla każdego firewalla lub jasno wydzielonego klastra inspekcji ułatwia później przypisanie, unieważnianie i rotację.

Przed zmianą muszą być dostępne:

• aktualna kopia konfiguracji i działający niezależny dostęp administracyjny,
• dokumentacja obecnego CA do ponownego podpisywania i jego dystrybucji na klienty,
• dostęp do Enterprise CA AD CS oraz zgoda właściciela PKI,
• mała zarządzana grupa testowa z działającą drogą odzyskiwania,
• plan unieważnienia, odnowienia i kontrolowanego powrotu do poprzedniego CA.

Tworzenie i przywracanie kopii zapasowej Sophos Firewall opisuje procedurę backupu i odtwarzania. Kopia zapasowa nie zastępuje dokumentacji aktualnie wybranego CA do ponownego podpisywania ani klientów, którzy mu ufają.

Generowanie CSR na Sophos Firewall

CSR jest generowany na firewallu, aby klucz prywatny powstał na nim i nie musiał być przenoszony między AD CS, stacją administratora a firewallem.

1. Otworzyć Certificates > Certificates.
2. Wybrać Add.
3. W Action wybrać Generate certificate signing request (CSR).
4. Wprowadzić jednoznaczną nazwę, na przykład SFOS-TLS-Inspection-SubCA-2026.
5. Wybrać typ i długość klucza lub krzywą oraz bezpieczny hash zgodnie z własną polityką PKI. Sophos pokazuje w przykładzie RSA, 2048 bitów i SHA-256; są to wartości przykładowe produktu, a nie uniwersalne wymagania.
6. Wprowadzić atrybuty podmiotu i Subject Alternative Names zatwierdzone przez wewnętrzną PKI.
7. Zapisać CSR i otworzyć go ikoną pobierania.
8. Użyć Copy to clipboard i przekazać CSR wyłącznie przez autoryzowany proces AD CS.

CSR nie zawiera klucza prywatnego. Nadal należy do kontrolowanego procesu PKI, ponieważ określa tożsamość, klucz publiczny i żądane przeznaczenie CA.

W sekcji Subject name attributes formularz CSR zawiera Country name, State, Locality name, Organization name, Organization unit name, Common name i Email address. Należy wprowadzić dane tożsamości zatwierdzone przez PKI, a nie dane dowolnej odwiedzanej witryny. Subject Alternative Names przyjmuje nazwy DNS lub adresy IP, na przykład web.exampleorg.com, fd12:3456:789a:1:: lub 203.0.113.10. Te wartości z przykładu produktu nie są wymaganiami dla CA inspekcji; SAN należy uzgodnić z właścicielem PKI.

Wystawienie podrzędnego CA w AD CS

CSR z Sophos należy przesłać na stronie rejestracji WWW właściwego Enterprise CA AD CS:

1. Otworzyć Request a certificate.
2. Wybrać Advanced certificate request.
3. Wkleić kompletny CSR.
4. Jako Certificate template wybrać Subordinate Certification Authority.
5. Sprawdzić żądanie zgodnie z wewnętrznym procesem zatwierdzania i wystawić je przez Submit.
6. W sekcji Certificate Issued wybrać odpowiedni format, na przykład Base 64 encoded.
7. Wybrać Download certificate, aby pobrać wystawiony certyfikat podrzędnego CA.
8. Na stronie początkowej AD CS otworzyć Download a CA certificate, wybrać główny CA, który podpisał podrzędny CA, a następnie wybrać Download CA certificate i Save.

Ważna granica EKU: Jeżeli wystawiony certyfikat CA zawiera sekcję Extended Key Usage, dla tego celu podpisywania musi ona obejmować TLS Web Server Authentication. Jeśli tej wartości brakuje, certyfikatu nie należy używać produkcyjnie jako CA do ponownego podpisywania. Właściciel PKI musi poprawić szablon CA i wystawić nowy certyfikat.

Przed importem należy w podglądzie certyfikatu sprawdzić wystawcę, podmiot, ważność, Basic Constraints oraz, jeśli występuje, Extended Key Usage. Plikom głównego i podrzędnego CA należy nadać jednoznaczne nazwy, aby nie pomylić ich z certyfikatami serwerowymi.

Import podrzędnego i głównego CA

Import podrzędnego CA przy istniejącym CSR

1. Otworzyć Certificates > Certificates.
2. Wybrać akcję importu przy utworzonym wcześniej CSR.
3. Wybrać certyfikat podrzędnego CA wystawiony przez AD CS.
4. Wybrać Certificate authority only. SFOS rozpoznaje typ CA i wyświetla jego opcje.
5. Sprawdzić nazwę i wybrać Import certificate.
6. W Certificates > Certificate authorities otworzyć filtr obok Name, wprowadzić nazwę CA i wybrać Apply.

SFOS automatycznie kojarzy klucz prywatny odpowiadający CSR z podrzędnym CA. Dlatego na liście CA przy tym CA musi być widoczna ikona klucza prywatnego. Jeśli jej brakuje, CA nie jest gotowy do podpisywania. Ogólny import CA w Certificates > Certificate authorities > Add może również rozpoznać pasujący istniejący CSR. Opisany tutaj import bezpośrednio przy CSR uwidacznia powiązanie, ale nie jest jedyną udokumentowaną ścieżką. Bez pasującego CSR lub klucza prywatnego ponowne przesłanie certyfikatu nie tworzy klucza podpisującego.

Dodanie głównego CA wyłącznie do walidacji

Przykład krok po kroku Sophos nazywa przeznaczenie Validation, a opis pola CA — Validation only. Chodzi tu o tę samą bezpieczną rolę: certyfikat głównego CA tylko do walidacji, bez jego klucza prywatnego; nie wybierać dla głównego CA Signing and validation. Przy przesyłaniu wybrać plik w Certificate przez Browse.

1. Otworzyć Certificates > Certificate authorities i wybrać Add.
2. Przesłać certyfikat głównego CA, który wystawił podrzędny CA.
3. W Use certificate for pozostawić Validation only.
4. Porównać nazwę i fingerprint z zatwierdzoną dokumentacją głównego CA.
5. Zapisać i ponownie sprawdzić łańcuch podrzędnego CA.

Firewall nie potrzebuje klucza prywatnego głównego CA. Signing and validation jest przeznaczone wyłącznie dla podrzędnego CA, którego klucz prywatny znajduje się już na firewallu dzięki CSR. Importowanie i przypisywanie certyfikatów na Sophos Firewall wyjaśnia ogólne różnice między certyfikatem, CSR, kluczem prywatnym i łańcuchem CA.

Wybór CA do inspekcji TLS

Sam import nie zmienia ruchu. Nowy CA jest najpierw aktywowany w ściśle ograniczonym pilotażu. DPI ma wybór globalny i możliwość jego zastąpienia dla pojedynczej reguły, natomiast Web Proxy ma osobny wybór:

• DPI, globalnie: Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings
• DPI, dla reguły: Decryption Profile przypisany w Profiles > Decryption profiles może odziedziczyć albo zastąpić wybór globalny.
• Web Proxy: Web > General settings > HTTPS decryption and scanning

Ustawienia DPI zawierają osobne pola Re-sign RSA with i Re-sign EC with. Odnoszą się one do tego, czy oryginalny certyfikat witryny został podpisany przy użyciu RSA, czy EC. W każdym z tych pól SFOS dopuszcza CA z kluczem RSA lub EC. Zwykle można więc wybrać ten sam podrzędny CA w obu polach. Drugi CA z kluczem EC jest przydatny głównie wtedy, gdy aplikacja akceptuje tylko określony typ certyfikatu; wszystkie objęte nim urządzenia końcowe również muszą mu ufać.

Decryption Profile przypisany do Inspection Rule może celowo odziedziczyć wybór globalny przez Use CAs defined in SSL/TLS settings. Jeśli zamiast tego w profilu zostaną ustawione własne wartości Re-sign RSA with i Re-sign EC with, zastąpią ustawienia globalne dla tej reguły. Przed pilotażem należy zatem sprawdzić zarówno globalny wybór CA, jak i profil faktycznie przypisany do reguły.

Jako CA do ponownego podpisywania można użyć tylko CA z przeznaczeniem Signing and validation i dostępnym kluczem prywatnym. Nie zmieniać używanego CA podpisującego na Validation only; nie nadawałby się już do aktywnego ponownego podpisywania. Nie wynika z tego, czy SFOS usuwa zapisany klucz.

Najpierw zabezpieczyć zakres pilotażu: Zmiana globalnego CA DPI wpływa również na istniejące reguły, których profile dziedziczą wybór globalny. Dla izolowanego pilotażu DPI użyć osobnego Decryption Profile z jawnymi wartościami CA i przypisać go wyłącznie do reguły pilotażowej już ograniczonej do grupy testowej. Nie edytować profilu współdzielonego z produkcją. Nowa reguła pilotażowa nie izoluje globalnego wyboru CA Web Proxy; jeśli skanowanie proxy już działa, potrzebna jest osobno zatwierdzona zmiana obejmująca wszystkich klientów, których dotyczy. Do tego czasu pozostawić obecny globalny CA bez zmian.

W pilotażu:

1. Udokumentować obecny wybór i objęte nim reguły.
2. Wybrać nowy CA dla certyfikatów RSA i EC w planowanej ścieżce inspekcji, a w przypadku DPI sprawdzić, czy przypisany Decryption Profile dziedziczy, czy zastępuje wybór globalny.
3. Ograniczyć regułę do zdefiniowanej grupy testowej lub sieci pilotażowej.
4. Sprawdzić łańcuch CA na klientach pilotażowych. W domenie AD firmowy główny CA powinien być już zaufany, ale pełny łańcuch do nowego podrzędnego CA nadal musi być poprawnie budowany.
5. Wygenerować rzeczywiste żądanie HTTPS i wspólnie sprawdzić szczegóły certyfikatu, Inspection Rule, Decryption Profile oraz wpis w logu.

Szeroką zmianę produkcyjną należy wykonać dopiero po zaliczeniu pilotażu. Wybranie CA nie aktywuje automatycznie Inspection Rule, a zaufanie klienta nie dowodzi, że ruch jest rzeczywiście odszyfrowywany.

Weryfikacja API: oddzielenie wyboru CA od przełączników globalnych

Podczas sprawdzania lub automatyzowania wyboru CA za pośrednictwem XML API należy rozróżniać pola w obiekcie SSLTLSInspectionSettings. Dokumentacja referencyjna dla SFOS 22.0 i 23.0 wymienia te same pola; nie stanowi to dowodu, że konkretna zapora pomyślnie zastosowała już daną zmianę.

• RSACA i ECCA określają wybór CA do ponownego podpisywania certyfikatów serwerów RSA i EC, odpowiednio do Re-sign RSA with i Re-sign EC with. Wartością jest nazwa przewidzianego obiektu CA, na przykład SFOS-TLS-Inspection-SubCA-2026, a nie ścieżka do pliku certyfikatu, klucz prywatny ani wartość aktywacyjna. Wybór nie tworzy ani nie importuje CA i nie dystrybuuje zaufania do klientów. Wcześniej opisane wymagania dotyczące przeznaczenia do podpisywania, klucza prywatnego, łańcucha i nadpisań profilu pozostają w mocy; w przypadku używania dwóch różnych CA klienci objęci zmianą muszą być w stanie zweryfikować oba łańcuchy.

• SSLTLSEngine włącza lub wyłącza silnik TLS, a SSLTLSInspection — globalną inspekcję SSL/TLS; oba pola przyjmują Enabled lub Disabled. Pola te nie określają ani wyboru CA, ani stanu pojedynczej reguły pilotażowej. Rotacja CA nie jest powodem do zmiany tych globalnych przełączników. Dokumentacja referencyjna API podaje dla obu wartość domyślną Enabled; przy wprowadzaniu zmiany liczy się jednak odczytany stan rzeczywisty, a nie wartość domyślna z dokumentacji.

• TLS13Decryption określa globalny sposób obsługi połączeń TLS 1.3: Decrypt as 1.3 lub Downgrade to TLS 1.2 and decrypt, z udokumentowaną wartością domyślną Decrypt as 1.3. Pole nie wybiera CA podpisującego ani działania pojedynczej reguły inspekcji. Obniżenie wersji protokołu nie jest zatem sposobem naprawienia brakującego łańcucha CA ani brakującego klucza podpisującego; przy zmianie wyłącznie CA zatwierdzone ustawienie TLS 1.3 pozostaje niezmienione.

Również SSLv2SSLv3, SSLCompression i SSLConnectionsExceeded stanowią odrębne globalne ustawienia dotyczące odpowiednio starszych protokołów, kompresji SSL i przekroczenia limitu połączeń SSL. Każde z nich przyjmuje Allow without decryption, Drop lub Reject; API podaje dla każdego Allow without decryption jako wartość domyślną, a nie zalecenie dotyczące bezpieczeństwa. Podczas rotacji CA tych ustawień nie resetuje się przy okazji do wartości przykładowych.

Przed zmianą za pośrednictwem API należy zapisać faktycznie przechowywane wartości globalne, obie nazwy obiektów CA, nadpisania profili i reguły objęte zmianą oraz określić dokładny sposób przywrócenia poprzedniego stanu. Dokumentacja referencyjna oznacza wymienione pola jako opcjonalne; nie dowodzi to, że pominięte pola pozostają niezmienione w każdej wersji oprogramowania układowego. Bez potwierdzonego dla konkretnej kompilacji zachowania przy aktualizacji i przywracaniu nie należy wykonywać zautomatyzowanego wywołania zapisu. Udokumentowana odpowiedź API 200 oznacza powodzenie operacji, a 500 — błąd operacji; nawet komunikat o powodzeniu nie zastępuje ponownego odczytu zapisanych wartości i testu z użyciem nowych połączeń HTTPS. Nieoczekiwana wartość lub niejasny stan wstrzymuje rozszerzanie pilotażu.

Weryfikacja działania i bezpieczeństwa

Udany test obejmuje kilka dowodów:

1. W Certificates > Certificate authorities główny CA jest obecny jako Validation only.
2. Podrzędny CA ma przypisane Signing and validation i wyświetla ikonę klucza prywatnego.
3. Klient pilotażowy ufa głównemu CA i potrafi zbudować pełny łańcuch.
4. Celowo odszyfrowana witryna HTTPS prezentuje certyfikat serwera podpisany przez nowy podrzędny CA.
5. Hostname, pierwotny cel i stan przeglądarki są prawidłowe, bez nieoczekiwanego ostrzeżenia o certyfikacie.
6. Log Viewer pokazuje oczekiwaną SSL/TLS Inspection Rule i działanie dla dokładnie tego testu.
7. Źródło spoza pilotażu pozostaje na poprzedniej ścieżce.

Osobno należy przetestować aplikacje z certificate pinning, własnymi magazynami zaufania lub wrażliwymi ścieżkami aktualizacji. Jedno udane żądanie w przeglądarce nie wystarcza do zatwierdzenia całego wdrożenia.

W ramach odbioru należy przetestować zarówno certyfikat serwera RSA, jak i EC w przewidzianej ścieżce DPI oraz w każdym przypadku porównać prezentowanego wystawcę, pełny łańcuch głównego i podrzędnych CA, zaufanie po stronie klienta, faktycznie przypisany profil oraz działanie odnotowane w logach. W przypadku różnych CA podpisujących należy osobno zweryfikować oba łańcuchy zaufania. Dodatkowo należy potwierdzić, że przełączniki globalne, sposób obsługi TLS 1.3 i pozostałe ustawienia globalne odpowiadają udokumentowanemu stanowi sprzed zmiany oraz że źródło spoza pilotażu pozostaje niezmienione. Jest to zakres weryfikacji do przeprowadzenia we własnym środowisku, a nie wykonany tutaj test urządzenia.

Rotacja i wycofanie zmiany

Podrzędny CA należy odnowić przed upływem ważności. Podczas kontrolowanego przejścia nowy i stary CA muszą być jednoznacznie rozróżnialne. Nowy CA jest najpierw wystawiany, importowany i sprawdzany na klientach pilotażowych, a dopiero potem stopniowo wybierany w ścieżce inspekcji.

W razie błędu należy użyć przygotowanej drogi odzyskiwania:

Przy wycofywaniu zmiany CA najlepiej przywrócić poprzedni CA lub profil. Samo wyłączenie reguły pilotażowej nie gwarantuje ani poprzedniego CA, ani poprzedniego odszyfrowywania: może zadziałać kolejna reguła. Najpierw sprawdzić rzeczywistą ścieżkę zastępczą, a po zmianie ponownie zweryfikować certyfikat i logi.

Wycofanie zmiany CA przywraca wyłącznie zmiany CA i profili wynikające z pilotażu do zapisanego stanu sprzed zmiany. Bezwarunkowe ustawienie SSLTLSEngine lub SSLTLSInspection na Disabled albo zmiana TLS13Decryption nie przywraca ani poprzedniego CA, ani poprzedniej ścieżki ochrony. Następnie należy ponownie odczytać zapisany wybór i nadpisania oraz sprawdzić łańcuch certyfikatów i logi z użyciem nowych połączeń. Jeśli nie ma potwierdzonego sposobu przywrócenia poprzedniego stanu, nie należy kontynuować wdrożenia.

1. Przywrócić poprzednie CA do ponownego podpisywania lub poprzedni profil deszyfrowania. Regułę pilotażową wyłączyć tylko wtedy, gdy uprzednio zweryfikowana dalsza ścieżka przetwarzania przywraca zatwierdzony stan sprzed zmiany; nie wyłączać bezwarunkowo globalnego silnika ani inspekcji.
2. W nowym procesie przeglądarki sprawdzić, czy poprzednia ścieżka certyfikatów znów działa.
3. Nie usuwać nowego CA, dopóki odwołują się do niego reguły, Decryption Profiles lub ustawienia Web Proxy.
4. Zaangażować właściciela PKI, jeśli EKU, łańcuch, szablon lub stan unieważnienia są niejasne.
5. Nie używać dalej przejętych kluczy; unieważnić CA, wystawić nowy i kontrolowanie oczyścić magazyny zaufania.

CA usuwa się dopiero wtedy, gdy żadna konfiguracja już się do niego nie odwołuje, stara ścieżka nie jest potrzebna i spełniono wymagania retencji oraz audytu.

Precyzyjne diagnozowanie błędów

Brakuje ikony klucza prywatnego

Sprawdzić istniejący CSR, wystawiony dla niego certyfikat i automatyczne powiązanie klucza. Import w Certificates > Certificate authorities > Add również zależy od znalezienia pasującego CSR przez SFOS. Jeśli pasującego CSR brakuje lub certyfikat do niego nie pasuje, powiązanie nie jest potwierdzone. Nie wolno importować kluczy prywatnych ze zgłoszeń, wiadomości e-mail ani niekontrolowanych lokalizacji.

Nie można wybrać CA do ponownego podpisywania

Sprawdzić przeznaczenie CA, ikonę klucza prywatnego i rozszerzenia certyfikatu. Jeżeli występuje Extended Key Usage, musi zawierać TLS Web Server Authentication. Główny CA z Validation only celowo nie jest dostępny do ponownego podpisywania.

Klient zgłasza niezaufany łańcuch

Sprawdzić główny i podrzędny CA, ich fingerprinty oraz magazyn zaufania danego klienta. Następnie porównać wystawcę faktycznie prezentowanego w przeglądarce z CA wybranym w SFOS. Sama obecność głównego CA na firewallu lub kliencie nie dowodzi, że aktywny jest właściwy CA do ponownego podpisywania.

Przeglądarka działa, ale aplikacja nie

Aplikacja może korzystać z własnego magazynu zaufania lub certificate pinning. Najpierw należy udokumentować cel, klienta, Inspection Rule i czas błędu. Nie należy tworzyć globalnego wyjątku Don't decrypt; problem trzeba zawęzić w małym pilotażu i zatwierdzić tylko niezbędny wyjątek z udokumentowanym uzasadnieniem.

FAQ