Rozprowadź certyfikat CA Sophos Firewall dla TLS Inspection

Gdy Sophos Firewall odszyfrowuje połączenia HTTPS za pomocą TLS Inspection lub HTTPS Scanning, tworzy dla sprawdzanego połączenia nowy certyfikat i podpisuje go przy użyciu lokalnego urzędu certyfikacji (CA). Klienci muszą ufać temu CA; w przeciwnym razie przeglądarka wyświetli ostrzeżenie lub aplikacja przerwie połączenie.

Sophos Firewall domyślnie udostępnia wbudowany CA SecurityAppliance_SSL_CA. Jego certyfikat można pobrać w Certificates > Certificate authorities i rozprowadzić na zarządzanych urządzeniach klienckich. Nie wystarczy jednak zainstalować dowolny certyfikat CA firmy Sophos. Musi on odpowiadać urzędowi, który faktycznie ponownie podpisuje połączenia w aktywnej konfiguracji inspekcji TLS.

Środowisko z własną firmową PKI może zamiast tego wystawić dedykowany podrzędny CA do inspekcji TLS na Sophos Firewall. Ta ścieżka pozostawia klucz podpisujący na firewallu i wiąże zaufanie z istniejącym firmowym głównym CA, ale wymaga kontrolowanego procesu PKI i pilotażu.

Oprócz wbudowanego CA można zaimportować urząd podpisujący utworzony zewnętrznie albo wygenerować na zaporze Certificate Signing Request (CSR) i zlecić zewnętrznemu CA, np. Active Directory Certificate Services, wystawienie podrzędnego urzędu podpisującego. W przypadku zewnętrznego CA na zaporę trzeba zaimportować zarówno podrzędny urząd podpisujący, jak i jego główny CA. Klientom potrzebna jest właściwa publiczna kotwica zaufania i wymagana publiczna ścieżka certyfikacji, nie prywatny klucz podpisujący. Podlinkowana procedura PKI opisuje wystawienie; poniższe kroki obejmują wybór, dystrybucję i weryfikację.

SecurityAppliance_SSL_CA nie jest wbudowanym CA Default dla lokalnie podpisanych certyfikatów. Jeśli ta druga kotwica zaufania wymaga planowanej wymiany, obowiązuje procedura Kontrolowane odnawianie Default CA na Sophos Firewall. Nie należy zastępować obu obiektów CA razem na podstawie przypuszczeń.

W zależności od trybu pracy wybór ten sprawdza się w różnych miejscach: w przypadku reguł SSL/TLS Inspection opartych na DPI istotny jest urząd certyfikacji w Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings. Decryption Profile przypisany do reguły może zastąpić te wartości globalne. W przypadku serwera Web Proxy urząd certyfikacji do HTTPS Scanning znajduje się w Web > General settings > HTTPS decryption and scanning. Jeśli aktywna ścieżka wybiera inny urząd certyfikacji niż ten, któremu ufają klienci, wystąpią błędy certyfikatu, mimo że urząd certyfikacji Sophos został rozdystrybuowany.

Artykuł Jak prawidłowo wdrożyć TLS Inspection na Sophos Firewall opisuje całe wdrożenie. Ten przewodnik koncentruje się na dystrybucji certyfikatu CA w systemach Windows i macOS oraz w przeglądarce Firefox.

Do czego służy ten certyfikat

Certyfikat Sophos Firewall CA nie jest certyfikatem serwera dla WebAdmin, WAF lub VPN Portal. Jest to podstawa zaufania, z jakim klienci akceptują połączenia HTTPS ponownie podpisane przez firewall.

Warto rozróżnić poszczególne elementy:

• Firewall CA: podpisuje nowo wygenerowane certyfikaty podczas TLS Inspection.
• Re-Signing CA lub HTTPS Scanning CA: konkretnie wybrany urząd certyfikacji używany przez zaporę w trybie DPI lub Web Proxy.
• Magazyn zaufanych certyfikatów klienta: decyduje, czy przeglądarki i aplikacje ufają temu urzędowi certyfikacji.
• Reguła SSL/TLS Inspection: decyduje, który ruch ma być odszyfrowany.
• Profil deszyfrowania: określa rygor sprawdzania certyfikatów, wersji TLS i obsługi błędów.
• Lista wykluczeń: uniemożliwia odszyfrowanie problematycznych lub celowo wykluczonych celów.

Zatem sama dystrybucja CA nie aktywuje TLS Inspection. Dystrybucja uniemożliwia zarządzanym klientom wyświetlanie ostrzeżeń o certyfikatach dla odszyfrowanego ruchu HTTPS. To, czy ruch zostanie rzeczywiście odszyfrowany, zależy od reguł zapory sieciowej, zasad sieciowych, reguł SSL/TLS Inspection, profili deszyfrowania i wyjątków.

Dystrybucja CA nie zastępuje prawidłowej kontroli protokołów. Reguły SSL/TLS Inspection obejmują ruch TCP. Jeśli ruch WWW korzysta z QUIC lub HTTP/3 na UDP 443, inspekcja przebiega inaczej i wymaga osobnego podejścia.

Przed wdrożeniem

Przed dystrybucją powinno być jasne, którzy klienci mają korzystać z TLS Inspection. Certyfikatu CA nie należy instalować bez kontroli na każdym urządzeniu, lecz wyłącznie na zarządzanych urządzeniach firmowych.

Przygotowanie:

• Zdefiniuj grupę testową lub testową jednostkę organizacyjną.
• Ustal tryb pracy: DPI, Web Proxy lub oba warianty.
• Udokumentuj wybrany urząd certyfikacji w SSL/TLS inspection settings, używanych Decryption Profiles i Web General settings.
• Udokumentuj procedurę cofania zmian i obsługi wyjątków.
• Pobierz certyfikat CA tylko z własnej zapory ogniowej.
• Najpierw przetestuj dystrybucję na kilku urządzeniach.
• Sprawdź przeglądarki, aplikacje biznesowe i aktualizacje po dystrybucji.
• Osobno oceń urządzenia mobilne i aplikacje z własnym magazynem zaufanych certyfikatów lub mechanizmem certificate pinning.
• Usuń stare lub nieużywane już certyfikaty CA z magazynu zaufania klienta.

⚠️ Uwaga: Jeśli urząd certyfikacji lub klucz prywatny zostały naruszone, redystrybucja nie wystarczy. Następnie należy zregenerować urząd certyfikacji na zaporze ogniowej, ponownie go rozdystrybuować, a stary urząd certyfikacji usunąć z klientów.

Wybierz sposób dystrybucji

Prawidłowa ścieżka dystrybucji zależy od sposobu zarządzania urządzeniami.

• Klienci domeny Windows: użyj GPO, aby wdrożyć certyfikat w Trusted Root Certification Authorities. To zalecany sposób w klasycznych środowiskach Active Directory.
• Windows bez domeny: Użyj MDM, Intune lub importu lokalnego. Import lokalny jest bardziej odpowiedni do testów lub pojedynczych urządzeń.
• macOS: Użyj profilu MDM lub pęku kluczy System. Instalacja ręczna jest bardziej odpowiednia do testowania lub małych środowisk.
• Firefox: użyj magazynu zaufanych certyfikatów Windows lub polityk firmowych Mozilla Enterprise Policies. Zachowanie Firefoksa należy sprawdzić osobno.
• BYOD lub urządzenia prywatne: normalnie nie dystrybuuj. TLS Inspection należy do zarządzanych urządzeń korporacyjnych.
• Serwery: dystrybuuj certyfikat tylko tam, gdzie oceniono zasadność inspekcji konkretnych usług serwerowych. Ruch wychodzący serwerów może wiązać się z innymi zagrożeniami i wyjątkami.

W środowisku produkcyjnym musi istnieć możliwość wycofania wdrożenia. Jeśli certyfikat CA jest dystrybuowany przez GPO, MDM lub politykę, trzeba również przetestować usunięcie starego certyfikatu CA z urządzeń. Nie należy mylić usunięcia z magazynu zaufania z unieważnieniem certyfikatu w PKI.

Pobierz certyfikat CA z Sophos Firewall

Przygotowanie reguły Web Proxy i CA

Na potrzeby pilotażu Web Proxy otwórz Rules and policies > Firewall rules, wybierz IPv4 lub IPv6 i utwórz regułę przez Add firewall rule > New firewall rule. Możesz nadać jej dowolną nazwę, np. TLS-CA-Pilot, ustawić Source zones na LAN, Source networks and devices na sieć pilotażową, Destination zones na WAN, a Destination networks na planowane cele. Dostosuj strefy, sieci i cele do rzeczywistej ścieżki; nie zezwalaj wszystkim klientom na dostęp tylko po to, aby przetestować certyfikat.

Przed zmianami zapisz poprzednie wartości reguły i wybór CA na potrzeby wycofania zmian. Osobno sprawdź HTTPS scanning certificate authority (CA) w Web > General settings > HTTPS decryption and scanning, najpierw rozprowadź jego publiczny certyfikat na wszystkie objęte pilotażem urządzenia i potwierdź zaufanie na podstawie fingerprintu. Wspólny CA Web Proxy jest globalny: jego zmiana nie jest pilotażem CA dla jednej reguły, obejmuje wszystkich klientów Web Proxy i wymaga wcześniejszego zaufania na tych urządzeniach oraz okna serwisowego.

Dopiero potem w wybranej regule zapory, w Security features > Web filtering, wybierz odpowiednią politykę WWW, włącz Scan HTTP and decrypted HTTPS, Use web proxy instead of DPI engine oraz wyraźnie Decrypt HTTPS during web proxy filtering i zapisz przez Save. Sama opcja skanowania nie odszyfrowuje; wybór CA w Web > General settings nie zastępuje opcji odszyfrowywania w regule zapory.

Przy pierwszej konfiguracji sprawdź w Certificates > Certificate authorities > Default, czy wszystkie ustawienia Default CA są skonfigurowane. Jest to kontrola konfiguracji, nie polecenie regeneracji CA ani powód, by rozprowadzać Default zamiast aktywnego SecurityAppliance_SSL_CA.

Pobieranie publicznego certyfikatu CA

Na Sophos Firewall certyfikat jest pobierany w interfejsie internetowym:

1. Zaloguj się jako administrator w Sophos Firewall.
2. Otwórz Certificates > Certificate authorities.
3. Znajdź urząd certyfikacji SecurityAppliance_SSL_CA lub celowo użyty własny urząd certyfikacji.
4. Pobierz certyfikat za pomocą ikony pobierania.
5. Następnie sprawdź, czy w aktywnej konfiguracji inspekcji TLS wybrano ten sam urząd certyfikacji.

Certyfikat jest wówczas zwykle dostępny jako SecurityAppliance_SSL_CA.pem. Ten plik zawiera publiczną część urzędu certyfikacji i może być rozpowszechniany wśród klientów. Klucz prywatny nie może być rozpowszechniany wśród klientów.

W pilotażu ręcznym można udostępnić sprawdzony plik publiczny w firmowym intranecie lub przez kontrolowaną wysyłkę e-mail. Użytkownicy zapisują go lokalnie i przed nadaniem zaufania porównują jego tożsamość ze szczegółami certyfikatu udokumentowanymi oddzielnie. Dla większych grup preferowane są GPO lub MDM.

W SFOS 22 można także pobrać faktycznie wybrany urząd certyfikacji bezpośrednio w miejscu jego użycia. W ścieżce DPI ikona pobierania znajduje się obok pól Re-sign RSA with i Re-sign EC with. Jeśli wybrano dwa różne urzędy certyfikacji, klienci objęci inspekcją muszą ufać obu. W ścieżce Web Proxy ikona znajduje się obok pola HTTPS scanning certificate authority (CA). Pobranie certyfikatu w miejscu użycia zmniejsza ryzyko rozesłania nieaktywnego obiektu CA o podobnej nazwie.

Plik należy traktować jako element konfiguracji związany z bezpieczeństwem. Część publiczna nie jest hasłem, ale określa, któremu urzędowi certyfikacji będą ufać klienci. Dlatego plik powinien pochodzić z własnej zapory produkcyjnej, mieć kontrolowaną wersję lub przynajmniej być przechowywany w sposób identyfikowalny i nie powinien być ponownie wykorzystywany ze starych projektów. Przed dystrybucją należy zapisać Subject, Issuer, numer seryjny, okres ważności i fingerprint widoczne w szczegółach certyfikatu. Po imporcie wartości te trzeba porównać na co najmniej jednym kliencie pilotażowym; sama nazwa wyświetlana nie jest wiarygodnym potwierdzeniem tożsamości.

Istnieją dwie dodatkowe ścieżki sprawdzania aktywnego urzędu certyfikacji:

• Tryb DPI: Otwórz Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings i porównaj wybrany tam urząd certyfikacji z pobranym plikiem. Jeśli aktywna reguła używa Decryption Profile, sprawdź także przypisany w nim Re-Signing CA.
• Web Proxy: Otwórz Web > General settings > HTTPS decryption and scanning i sprawdź urząd certyfikacji skanujący HTTPS.

To sprawdzenie zapobiega typowemu błędowi wdrożenia: domyślny urząd certyfikacji jest dystrybuowany na klientach, podczas gdy zapora używa już innego urzędu certyfikacji w Decryption Profile lub w Web Proxy.

Windows: Dystrybuuj certyfikat poprzez obiekt GPO

W środowiskach Active Directory zalecaną metodą są zasady grupowe. Edge, Chrome i wiele aplikacji Windows ufa magazynowi certyfikatów Windows.

Zalecana ścieżka w zarządzaniu zasadami grupy:

Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities > Certificates

Procedura:

1. Otwórz Zarządzanie zasadami grupy na kontrolerze domeny lub kliencie administracyjnym.
2. Użyj istniejącego GPO z podstawową konfiguracją klientów albo utwórz nowe GPO dla grupy testowej inspekcji TLS.
3. Przejdź do ścieżki Trusted Root Certification Authorities > Certificates.
4. Kliknij prawym przyciskiem myszy listę certyfikatów.
5. Wybierz All Tasks > Import.
6. Zaimportuj SecurityAppliance_SSL_CA.pem.
7. Powiąż GPO z planowaną testową jednostką organizacyjną. W razie potrzeby użyj grupy zabezpieczeń w filtrowaniu zabezpieczeń, nie jako celu powiązania GPO.
8. Uruchom gpupdate /force na kliencie testowym lub poczekaj na regularną aktualizację.

W środowiskach produkcyjnych obiekt GPO nie powinien być stosowany bezpośrednio na wszystkich komputerach. Testowa jednostka organizacyjna zmniejsza ryzyko w przypadku nieprawidłowego zaimportowania certyfikatu lub nieoczekiwanej reakcji aplikacji.

Windows: Zainstaluj certyfikat lokalnie

Certyfikat można zaimportować lokalnie dla poszczególnych urządzeń testowych. Istnieją dwa rozsądne warianty:

• Magazyn certyfikatów komputera lokalnego: obejmuje wszystkich użytkowników urządzenia i zwykle jest właściwy dla zarządzanych klientów.
• Magazyn certyfikatów bieżącego użytkownika: obejmuje tylko zalogowanego użytkownika i czasem wystarcza do testów.

W przypadku komputera lokalnego:

1. Zaloguj się jako administrator lokalny.
2. Uruchom certlm.msc.
3. Otwórz Trusted Root Certification Authorities > Certificates.
4. Kliknij prawym przyciskiem myszy listę certyfikatów.
5. Wybierz All Tasks > Import.
6. Importuj SecurityAppliance_SSL_CA.pem.

certmgr.msc może być użyte alternatywnie dla bieżącego użytkownika.

Po zaimportowaniu należy ponownie uruchomić przeglądarki i aplikacje. W przypadku niektórych aplikacji sensowne jest wylogowanie się lub ponowne uruchomienie klienta.

macOS: ustaw zaufanie do certyfikatu w pęku kluczy

W systemie macOS certyfikat jest importowany za pośrednictwem dostępu do pęku kluczy.

Dla pojedynczego użytkownika można także użyć pęku kluczy login: otwórz pobrany plik dwukrotnym kliknięciem w Keychain Access, sprawdź jego tożsamość i wybierz Always Trust. Safari również korzysta z tego zaufania macOS. We wdrożeniu zarządzanym obejmującym całe urządzenie nadal właściwe są System lub MDM; nie myl zakresu użytkownika z zakresem systemowym.

Procedura:

1. Skopiuj SecurityAppliance_SSL_CA.pem na komputer Mac.
2. Otwórz certyfikat, klikając dwukrotnie.
3. Wdróż w pęku kluczy System lub zarządzanym profilu MDM.
4. Otwórz certyfikat i w sekcji Trust wybierz Always Trust.
5. Potwierdź zmianę za pomocą konta administratora.
6. Uruchom ponownie przeglądarkę i aplikacje objęte zmianą.

W większych środowiskach macOS dystrybucja powinna odbywać się za pośrednictwem MDM. Instalacja ręczna jest bardziej odpowiednia do testowania lub pojedynczych urządzeń.

Urządzenia mobilne z Sophos Mobile

⚠️ Android: instalacja certyfikatu nie oznacza zgody na odszyfrowywanie. Sophos opisuje import CA, ale ze względu na błędy certyfikatów zaleca też wykluczenie wszystkich urządzeń z Androidem z inspekcji SSL/TLS w trybie DPI. Dlatego ten przewodnik domyślnie zakłada wykluczenie wszystkich urządzeń z Androidem z DPI. Poniższe kroki importu i testowania HTTPS w Androidzie dotyczą wyłącznie osobno zatwierdzonego pilotażu na zarządzanych urządzeniach, o wąskim zakresie: udokumentowana potrzeba biznesowa musi uzasadniać odstępstwo dla wskazanych urządzeń i aplikacji. Przed zatwierdzeniem sprawdź rzeczywiście używany magazyn zaufania i każdą objętą aplikację; w razie błędów wycofaj pilotaż i przywróć wykluczenie. Instalacja przez MDM nie rozwiązuje certificate pinning ani zaufania we wszystkich aplikacjach. Zalecenie DPI nie jest ogólnym stwierdzeniem o zgodności z Web Proxy; ta ścieżka również wymaga osobnej weryfikacji aplikacji.

Ręczny pilotaż mobilny

Jeśli urządzenie nie akceptuje pliku PEM, może być potrzebna konwersja do zgodnego formatu certyfikatu, np. .der, .cer lub .crt. Samo rozszerzenie nie określa kodowania; nigdy nie używaj pliku klucza prywatnego. Nazwy menu zależą od wersji Androida i producenta. Przykład dla Pixela używa Settings > Security & location > Advanced > Encryption & credentials:

1. W Credential storage wybierz Install from storage lub Install from SD card.
2. W oknie wyboru pliku wskaż lokalizację przez Menu > Open from i otwórz publiczny certyfikat.
3. Wprowadź PIN urządzenia, nadaj certyfikatowi rozpoznawalną nazwę i wybierz VPN and apps dla tego pilotażu aplikacji; Wi-Fi jest drugą oferowaną kategorią. Potwierdź przez OK.
4. Sprawdź tożsamość i import w User credentials, a następnie przetestuj odszyfrowane żądanie HTTPS. Udany import nie gwarantuje, że każda aplikacja Android zaufa magazynowi certyfikatów użytkownika.

W ręcznym pilotażu iOS udostępnij i zaimportuj publiczny plik CA na urządzeniu. W Settings > General > About > Certificate Trust Settings > Enable full trust for root certificates włącz zaufanie wyłącznie dla zidentyfikowanego certyfikatu głównego i przetestuj HTTPS. Nie włączaj kilku nieznanych głównych CA.

Centralna dystrybucja przez politykę urządzeń

W przypadku większej liczby zarządzanych urządzeń z systemem Android, iOS i iPadOS CA należy rozprowadzić za pomocą polityki MDM. Sophos Mobile może dodać certyfikat główny bezpośrednio do już przypisanej polityki urządzeń. Apple zaleca MDM lub Apple Configurator; w przypadku Apple Configurator najpierw tworzy się profil konfiguracji na macOS. Następnie podłącz jedno lub więcej urządzeń iOS do Maca, aby zainstalować profil zawierający certyfikat CA.

Przykład dla iOS i iPadOS w Sophos Mobile:

Certyfikaty główne zainstalowane na urządzeniach iOS i iPadOS przez MDM lub Apple Configurator są automatycznie zaufane, inaczej niż przy imporcie ręcznym. Poniższa kontrola nie jest poleceniem zmiany zaufania, które już jest włączone.

1. Otwórz Policies > iOS & iPadOS.
2. Wybierz politykę już przypisaną do planowanych urządzeń.
3. Na stronie Edit policy wybierz Add > Root certificate.
4. W Root certificate użyj Upload a file, aby przesłać wyłącznie publiczny certyfikat CA, któremu urządzenia mają ufać zgodnie z zaplanowanym łańcuchem. Dla SecurityAppliance_SSL_CA jest to publiczna część CA pobrana z SFOS.
5. Zapisz przez Apply, a następnie Save.
6. Na liście polityk użyj strzałki i wybierz Update devices. Jeśli ta opcja nie jest dostępna, zmiana zostanie rozprowadzona podczas następnej automatycznej synchronizacji.

W przypadku Androida certyfikat główny dodaje się analogicznie do polityki Android. Następnie nie należy polegać wyłącznie na stanie polityki. W iOS kontrola znajduje się w Settings > General > About > Certificate Trust Settings, a w Androidzie w Settings > Security > Advanced > Encryption & credentials > User credentials. Ostatecznym dowodem pozostaje rzeczywiste odszyfrowane żądanie HTTPS.

W iOS należy w tym miejscu sprawdzić stan zaufania do właściwego certyfikatu głównego, po potwierdzeniu jego tożsamości na podstawie udokumentowanego fingerprintu. Jeśli zaufanie jest nadal wyłączone, w sekcji Enable full trust for root certificates należy je włączyć wyłącznie dla tego certyfikatu głównego. Jeśli certyfikat jest już zaufany, ustawienie należy pozostawić bez zmian; następnie ponowić odszyfrowane żądanie HTTPS, aby zweryfikować wynik.

Klucz prywatny CA do ponownego podpisywania nigdy nie może trafić do Sophos Mobile ani na endpoint. Rozprowadzany jest wyłącznie publiczny certyfikat CA. Należy zacząć od małej grupy pilotażowej i przetestować również wycofanie CA.

Sprawdź certyfikat na zarządzanych urządzeniach

Po dystrybucji należy sprawdzić na co najmniej jednym urządzeniu testowym na platformę, czy urząd certyfikacji rzeczywiście trafił do właściwego magazynu zaufanych certyfikatów.

• Magazyn certyfikatów komputera Windows: Otwórz certlm.msc i wyszukaj CA w Trusted Root Certification Authorities > Certificates.
• Magazyn bieżącego użytkownika systemu Windows: Otwórz certmgr.msc i sprawdź magazyn zaufania użytkownika.
• macOS: Otwórz dostęp do pęku kluczy i sprawdź status zaufania w pęku kluczy System.
• Firefox: Otwórz Settings > Privacy & Security > Certificates > View Certificates.

Jeśli certyfikat znajduje się tylko w magazynie użytkownika, ale aplikacja oczekuje magazynu komputera, przeglądarka może działać, a inna aplikacja może nadal wyświetlać błędy certyfikatu. I odwrotnie, przeglądarki posiadające własny magazyn zaufanych certyfikatów mogą zignorować dystrybucję systemu Windows lub macOS, jeśli nie są odpowiednio skonfigurowane.

Firefox w systemie Windows

Dla jednego profilu testowego można też wykonać import ręczny: otwórz Settings > Privacy & Security > Certificates > View Certificates > Authorities > Import, wybierz publiczny plik CA i kliknij Open. W oknie Downloading Certificate zaznacz wyłącznie Trust this CA to identify websites dla urzędu, którego tożsamość została już sprawdzona, i kliknij OK. Uruchom Firefox ponownie i przetestuj odszyfrowaną ścieżkę HTTPS. Import do profilu nie zastępuje centralnej dystrybucji.

Aktualne wersje Firefoksa w systemie Windows domyślnie przeszukują magazyn certyfikatów systemu operacyjnego w poszukiwaniu dodatkowo zainstalowanych głównych urzędów certyfikacji. Jeśli urząd certyfikacji Sophos Firewall jest dystrybuowany przez GPO do magazynu komputera Windows, drugi import do osobnej bazy Firefoksa zwykle nie jest potrzebny. To zachowanie jest sterowane w Firefoksie przez Allow Firefox to automatically trust third-party root certificates you install, ustawienie security.enterprise_roots.enabled lub zasadę firmową ImportEnterpriseRoots.

W zarządzanych środowiskach Windows istnieją zatem dwie właściwe metody:

• Użycie magazynu zaufania systemu Windows: zalecany sposób standardowy, jeśli urząd certyfikacji jest już dystrybuowany przez komputerowy obiekt GPO. Automatyczne używanie urzędów CA systemu operacyjnego musi pozostać włączone w zarządzanej konfiguracji Firefoksa.
• Bezpośredni import certyfikatu przez Mozilla Enterprise Policy: alternatywa, gdy zaufanie Firefoksa jest świadomie zarządzane oddzielnie lub magazyn systemu operacyjnego nie ma być używany.

W pierwszym wariancie urząd certyfikacji przejęty z Windows może działać bez pojawienia się jako osobno zaimportowany wpis w menedżerze certyfikatów Firefoksa. Decydujące są wtedy magazyn komputera Windows i rzeczywisty test HTTPS. Poniższa instrukcja GPO opisuje drugi wariant z Install Certificates.

Pobierz szablony GPO przeglądarki Firefox

Mozilla udostępnia szablony zasad w serwisie GitHub. Potrzebne są między innymi:

• firefox.admx
• mozilla.admx
• firefox.adml
• mozilla.adml

Pliki można pobrać z Repozytorium szablonów zasad Mozilli lub jako policy_templates.zip.

Importuj szablony

Skopiuj firefox.admx i mozilla.admx bezpośrednio do wybranego folderu PolicyDefinitions. Odpowiadające im pliki firefox.adml i mozilla.adml umieść w podfolderze właściwym dla języka, nie obok plików ADMX.

Typowa ścieżka lokalna:

C:\Windows\PolicyDefinitions

W przypadku magazynu Central Store w domenie użyj zamiast tego \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions. Zastąp oba wystąpienia <domain> nazwą DNS swojej domeny AD. Jeśli istnieje Central Store, umieść szablony Mozilli właśnie tam; kopia wyłącznie w folderze lokalnym nie wystarczy do edycji domenowych GPO.

Zachowaj foldery językowe z pobranego pakietu i użyj plików ADMX oraz ADML z tej samej wersji szablonów. Przykładowo angielskie pliki ADML umieść w C:\Windows\PolicyDefinitions\en-US albo, jeśli używasz Central Store, w \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions\en-US. Pozostałe wymagane języki skopiuj do odpowiednich podfolderów z pakietu. en-US jest przykładem języka szablonów, a nie wymaganiem wynikającym z języka tego artykułu.

Otwórz ponownie edytor zasad grupy i sprawdź, czy Administrative Templates > Mozilla > Firefox > Certificates > Install Certificates jest widoczne bez błędów zasobów. Jeśli brakuje tej zasady, popraw folder docelowy, podfolder językowy i zgodność wersji przed dalszą konfiguracją zasady certyfikatu.

Skonfiguruj zasady przeglądarki Firefox

Certyfikat jest następnie wprowadzany do zasad grupy w ramach zasad przeglądarki Firefox:

Administrative Templates > Mozilla > Firefox > Certificates > Install Certificates

Procedura:

1. Włącz zasadę Install Certificates.
2. Wprowadź nazwę pliku certyfikatu, na przykład SecurityAppliance_SSL_CA.pem.
3. Skopiuj plik certyfikatu do oczekiwanego katalogu profilu użytkownika za pośrednictwem obiektu GPO lub dystrybucji oprogramowania.

W zależności od wersji przeglądarki Firefox i konfiguracji zasad, certyfikaty są odczytywane z następujących katalogów:

%USERPROFILE%\AppData\Local\Mozilla\Certificates
%USERPROFILE%\AppData\Roaming\Mozilla\Certificates

Po następnej sesji przeglądarki Firefox certyfikat powinien być widoczny w Menedżerze certyfikatów przeglądarki Firefox.

Sprawdź działanie

Po dystrybucji powinieneś nie tylko sprawdzić, czy certyfikat istnieje. Liczy się to, czy TLS Inspection działa poprawnie.

Przydatne testy:

1. Uruchom ponownie klienta testowego lub ponownie zaloguj użytkownika.
2. Otwórz przeglądarkę i wyświetl stronę HTTPS odszyfrowaną przez Sophos Firewall.
3. Pokaż certyfikat witryny w przeglądarce.
4. Sprawdź, czy łańcuch certyfikatów przebiega przez SecurityAppliance_SSL_CA, czy dokładnie przez wybrany urząd certyfikacji Sophos.
5. Powiąż nowe żądanie na zaporze ze źródłem, celem i czasem, ustal rzeczywisty tryb pracy i wykonaj odpowiednie kontrole opisane poniżej.
6. Testuj kluczowe aplikacje biznesowe, usługi aktualizacji, narzędzia do współpracy i dostawców tożsamości.

DPI: W Rules and policies > SSL/TLS inspection rules sprawdź pasującą regułę inspekcji, jej akcję, Decryption Profile i CA do ponownego podpisywania. W Log Viewer > SSL/TLS inspection powiąż to samo nowe żądanie ze źródłem, celem i czasem, a następnie sprawdź odszyfrowywanie i zastosowaną regułę lub akcję. Sprawdź także wykluczenia DPI.

Web Proxy: Potwierdź regułę zapory, która rzeczywiście pasuje, jej politykę WWW oraz Decrypt HTTPS during web proxy filtering. Sprawdź wspólny HTTPS scanning certificate authority (CA) w Web > General settings i obowiązujące wyjątki w Web > Exceptions. W Log Viewer powiąż odpowiednie dzienniki filtrowania WWW/proxy dla tego samego nowego żądania ze źródłem, celem i czasem; wystawca i łańcuch certyfikatu w przeglądarce muszą odpowiadać wybranemu CA. Reguły inspekcji SSL/TLS nie sterują odszyfrowywaniem Web Proxy. Wpis odszyfrowywania DPI nie jest tu ani gwarantowany, ani wymagany; sam wpis filtrowania WWW nie dowodzi odszyfrowania.

Jeśli przeglądarka nadal pokazuje oryginalny publiczny certyfikat witryny, połączenie nie zostało odszyfrowane. W DPI sprawdź regułę inspekcji i wykluczenia; w Web Proxy pasującą regułę zapory, opcję odszyfrowywania i wyjątki WWW. Inna ścieżka ruchu lub QUIC/HTTP/3 również może ominąć oczekiwaną ścieżkę TCP.

Jeśli ostrzeżenie przeglądarki zniknie, ale aplikacje nadal zgłaszają błędy, przyczyną często nie jest sam certyfikat. Może nią być certificate pinning lub własny magazyn zaufania. W DPI sprawdź też Decryption Profile, regułę inspekcji i wykluczenia TLS; w Web Proxy regułę zapory i wyjątki WWW zgodnie z kontrolami powyżej.

W przypadku ruchu sieciowego należy dodatkowo sprawdzić, czy QUIC lub HTTP/3 omija oczekiwaną inspekcję. Artykuł Jak prawidłowo blokować QUIC i HTTP/3 na Sophos Firewall wyjaśnia, dlaczego Block QUIC protocol pozostaje istotny w filtrowaniu sieci, skanowaniu złośliwego oprogramowania i TLS Inspection.

Typowe błędy

• Przeglądarka w dalszym ciągu wyświetla ostrzeżenie o certyfikacie: Urząd certyfikacji prawdopodobnie nie znajduje się we właściwym magazynie zaufanych certyfikatów. Sprawdź magazyn zaufanych certyfikatów Windows, macOS lub Firefox.
• Chrome działa, Firefox nie: sprawdź, czy Firefox może używać dodatkowo zainstalowanych głównych urzędów certyfikacji systemu operacyjnego lub czy obowiązuje osobna Mozilla Enterprise Policy. Następnie uruchom Firefox ponownie i przetestuj rzeczywistą ścieżkę HTTPS.
• Poszczególne aplikacje przerywają połączenie: Prawdopodobną przyczyną jest certificate pinning lub własna weryfikacja certyfikatu. W DPI sprawdź dzienniki SSL/TLS i wykluczenia TLS; w Web Proxy dzienniki filtrowania WWW/proxy i Web > Exceptions, zawsze dla tego samego żądania.
• Działają tylko niektórzy klienci: GPO nie jest stosowane albo zostało powiązane z niewłaściwą jednostką organizacyjną. Sprawdź wynik gpresult i powiązanie GPO.
• Certyfikat CA jest zainstalowany, ale ostrzeżenie pozostaje: rozprowadzony certyfikat może nie odpowiadać CA wybranemu w Decryption Profile, SSL/TLS inspection settings lub Web General settings.
• DPI działa, Web Proxy nie lub odwrotnie: Użyj opisanych powyżej kontroli rzeczywistego trybu: reguła inspekcji, profil i dzienniki SSL/TLS dla DPI; reguła zapory, opcja odszyfrowywania, wspólny CA, wyjątki WWW i dzienniki filtrowania WWW/proxy dla Web Proxy.
• Ostrzeżenia po regeneracji CA: Na klientach może brakować nowego aktywnego CA. Najpierw rozprowadź jego publiczny certyfikat i sprawdź fingerprint. Stary, nieprzejęty CA usuń dopiero wtedy, gdy żadna aktywna ścieżka już go nie używa; w razie przejęcia zastosuj procedurę awaryjną.
• Źródła URL lub filtrowanie WWW nie działają zgodnie z oczekiwaniami: ruch HTTPS może nie być odszyfrowywany. Sprawdź ustawienia TLS Inspection i politykę WWW.
• Certyfikat jest obecny, ale ruch nie jest odszyfrowany: W DPI może brakować pasującej reguły inspekcji; w Web Proxy opcji odszyfrowywania w regule zapory albo może obowiązywać wyjątek WWW. Wykonaj kontrole właściwe dla trybu i potwierdź rzeczywistą ścieżkę ruchu.
• Nie działają tylko aplikacje mobilne lub pojedyncze urządzenia klienckie: Uwzględnij własne magazyny zaufania, certificate pinning i weryfikację każdej aplikacji. Domyślnie wyklucz Android z DPI; osobno zatwierdzony pilotaż Androida musi wrócić do wykluczenia w razie błędów. Inne wyjątki oceniaj punktowo, zamiast globalnie wyłączać inspekcję.

Rotacja urzędu certyfikacji i sytuacja awaryjna

CA nie powinien być używany przez lata bez nadzoru nad datą ważności, pochodzeniem i dystrybucją jego certyfikatu. W środowiskach produkcyjnych warto wdrożyć prosty proces zarządzania cyklem życia CA.

Wbudowany urząd SecurityAppliance_SSL_CA można zregenerować. Nie jest to jednak bezpieczny etap przygotowawczy: stary i nowy urząd certyfikacji nie stają się automatycznie równolegle zaufane na wszystkich klientach. Przy planowanej zmianie DPI z okresem nakładania należy użyć osobno przygotowanego urzędu podpisującego i przetestować go w Decryption Profile o wąskim zakresie. Web Proxy ma natomiast tylko globalne pole HTTPS scanning certificate authority (CA). Jego zmiana obejmuje całą ścieżkę Web Proxy i dlatego wymaga okna serwisowego; wcześniej wszystkie objęte nią urządzenia klienckie muszą ufać nowemu publicznemu certyfikatowi CA. W obu przypadkach klucz prywatny pozostaje na zaporze.

Planowana zmiana:

1. Zapisz aktywny wybór CA, fingerprinty i wszystkie odwołania. Przygotuj osobny urząd podpisujący bez regenerowania wbudowanego CA jako pierwszego kroku.
2. Rozprowadź wyłącznie publiczny certyfikat lub wymaganą publiczną ścieżkę CA: najpierw do grupy pilotażowej DPI albo do wszystkich objętych klientów przed globalną zmianą Web Proxy.
3. W trybie DPI aktywuj nowy CA za pomocą Decryption Profile o wąskim zakresie i sprawdź Issuer, wpis w dzienniku oraz aplikacje grupy pilotażowej.
4. Po udanym pilotażu DPI rozprowadź publiczny certyfikat do wszystkich objętych urządzeń zarządzanych i potwierdź import na podstawie fingerprintu.
5. Zmień pozostałe pola DPI albo globalny CA Web Proxy. Za pomocą nowych połączeń sprawdź, czy podpisuje je nowy CA i czy działa oczekiwana reguła.
6. Usuń stary CA z magazynów zaufania klientów dopiero wtedy, gdy żadna ścieżka inspekcji już się do niego nie odwołuje, a wszystkie objęte urządzenia otrzymały nowy CA.

Postępowanie awaryjne w razie przejęcia klucza:

1. W razie potrzeby ogranicz lub tymczasowo wyłącz TLS Inspection w kontrolowany sposób.
2. Zamień urząd certyfikacji, którego dotyczy problem, w zaporze ogniowej.
3. Wdróż nowy urząd certyfikacji za pośrednictwem zdefiniowanej trasy dystrybucji.
4. Usuń stary urząd certyfikacji ze wszystkich magazynów zaufanych certyfikatów.
5. Sprawdź wyjątki, Log Viewer i aplikacje, których to dotyczy.
6. Udokumentuj zmianę w systemie obsługi incydentów lub zarządzania zmianami.

Ważne: zaatakowany urząd certyfikacji nie jest normalnym problemem z certyfikatem. Jeśli osoba atakująca kontroluje klucz prywatny, klienci mogą ufać fałszywym certyfikatom. Następnie należy konsekwentnie usuwać stary urząd certyfikacji.

Przy zwykłym rollbacku najpierw przywróć w ścieżce inspekcji wcześniej udokumentowany urząd certyfikacji albo wyłącz regułę pilotażową. Urząd rozesłany wyłącznie na potrzeby pilota usuń dopiero wtedy, gdy nowe połączenie ponownie pokaże poprzedniego Issuer lub pierwotną, nieodszyfrowaną ścieżkę. Odebranie zaufania klientom, gdy zapora nadal podpisuje tym urzędem, powoduje błędy certyfikatu. Nie usuwaj współdzielonych ani nadal używanych urzędów certyfikacji.

Obsługa i konserwacja

Certyfikat urzędu certyfikacji powinien być częścią procesu operacyjnego:

• Udokumentuj datę ważności CA i osoby odpowiedzialne.
• Wykonuj regenerację urzędu certyfikacji wyłącznie jako zaplanowaną zmianę.
• Po migracji usuń stary urząd certyfikacji z klientów.
• Regularnie sprawdzaj dystrybucję za pośrednictwem GPO lub MDM.
• Dokumentuj i okresowo przeglądaj wyjątki TLS.
• Uruchom proces obsługi incydentu i zmiany CA, jeśli istnieje podejrzenie przejęcia prywatnego klucza podpisującego lub zapory. Utrata klienta zawierającego wyłącznie publiczny certyfikat CA nie oznacza przejęcia klucza podpisującego.

Jeśli dokonasz zmiany w TLS Inspection, powinieneś także sprawdzić reguły zapory sieciowej, których to dotyczy, profile deszyfrowania i listy wykluczeń. W przeciwnym razie klient zaufa urzędowi certyfikacji, ale zapora nadal nie będzie odszyfrowywać żądanego ruchu.

Często zadawane pytania