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.

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 dodatkowego, niezależnego 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.

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. Pobrać wystawiony certyfikat podrzędnego CA.
8. Pobrać również certyfikat głównego CA, który podpisał podrzędny CA.

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. Otworzyć Certificates > Certificate authorities i odnaleźć zaimportowany CA.

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; ponowne przesłanie pliku w innym miejscu nie odtworzy brakującego powiązania klucza.

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

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. W zależności od ścieżki inspekcji wybór znajduje się w różnych miejscach:

• DPI: Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings
• Decryption Profile: Profiles > Decryption profiles
• Web Proxy: Web > General settings > HTTPS decryption and scanning

Jako CA do ponownego podpisywania można użyć tylko CA z przeznaczeniem Signing and validation i dostępnym kluczem prywatnym. Używanego CA podpisującego nie należy zmieniać na Validation only, ponieważ aktywna ścieżka ponownego podpisywania utraciłaby klucz.

W pilotażu:

1. Udokumentować obecny wybór i objęte nim reguły.
2. Wybrać nowy CA w planowanej ścieżce inspekcji.
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 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.

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:

1. Wyłączyć regułę pilotażową lub przywrócić poprzedni CA do ponownego podpisywania.
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

Jeśli certyfikat nie został zaimportowany przez pasujący CSR, SFOS nie może powiązać go z kluczem utworzonym na firewallu. Należy sprawdzić ścieżkę powiązania CSR i wystawiony certyfikat. 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