Importowanie i przypisywanie certyfikatów w Sophos Firewall

Certyfikat jest gotowy do użycia w Sophos Firewall dopiero wtedy, gdy pasują do siebie cztery elementy: nazwa hosta, certyfikat serwera, klucz prywatny i łańcuch wystawiających urzędów certyfikacji (CA). Następnie certyfikat trzeba jeszcze przypisać do właściwej usługi. Sam wpis w Certificates > Certificates nie zmienia żadnego portalu ani reguły WAF.

W przypadku certyfikatu wewnętrznego lub publicznego urzędu certyfikacji najbezpieczniejsza standardowa procedura wygląda następująco:

1. W Certificates > Certificates > Add wygeneruj Certificate Signing Request (CSR).
2. Przekaż CSR do podpisania wybranemu urzędowi certyfikacji.
3. Zaimportuj wystawiony certyfikat za pomocą akcji importu przy istniejącym CSR.
4. Sprawdź w kolumnie Trusted, czy właściwy urząd certyfikacji jest zainstalowany, oraz zweryfikuj ważność w Valid until.
5. Przypisz certyfikat do wybranej usługi i przetestuj ją z urządzenia klienckiego.

W tej procedurze klucz prywatny powstaje na firewallu i nie musi go opuszczać. Można również przesłać certyfikat utworzony wcześniej poza firewallem, ale wymaga on pasującego klucza prywatnego oraz ewentualnie brakujących certyfikatów pośrednich i głównych CA.

Jeżeli plik PFX lub PEM jest już dostępny, skrócona procedura prowadzi przez Certificates > Certificates > Add > Upload certificate: wybierz format, prześlij certyfikat wraz z wymaganym kluczem prywatnym i hasłem, a następnie sprawdź właściwy urząd CA, okres ważności oraz przypisanie do usługi.

Która metoda obsługi certyfikatu będzie odpowiednia?

• Publiczny lub wewnętrzny urząd CA, nowy certyfikat: wygeneruj CSR na firewallu. Ogranicza to przenoszenie kluczy i zapobiega łatwemu pomyleniu par certyfikat–klucz.
• Istniejący certyfikat z kluczem prywatnym: prześlij certyfikat w formacie PEM, DER, CER lub PKCS12. Format, hasło i łańcuch CA muszą być prawidłowe.
• Let’s Encrypt dla publicznej usługi firewalla: wbudowany proces może obsługiwać wystawienie i odnawianie certyfikatu. Pełną procedurę opisuje artykuł Konfiguracja certyfikatów Let’s Encrypt w Sophos Firewall.
• Zewnętrzny certyfikat wildcard: utwórz go poza firewallem, a następnie zaimportuj. Planowanie i walidację DNS-01 opisuje artykuł Tworzenie certyfikatu wildcard Let’s Encrypt.

W przypadku certyfikatów WAF wewnętrzna nazwa obiektu certyfikatu może zawierać wyłącznie litery ASCII i cyfry, bez spacji ani znaków specjalnych. PublicVpnExampleCom2026 spełnia ten wymóg. Nazwa obiektu nie jest nazwą DNS; nazwa usługi pozostaje nazwą FQDN w SAN.

• Automatyzacja DigiCert lub innego publicznego CA: Odnawianie certyfikatu Sophos Firewall przez XML API i weryfikacja usług łączy wystawienie, przesłanie przez XML API, przypisanie do usługi i zewnętrzny test listenera w jedną kontrolowaną procedurę end-to-end.
• Wyłącznie dla wewnętrznych, zarządzanych klientów: lokalnie podpisany certyfikat może wystarczyć, jeżeli wszystkie urządzenia klienckie ufają wewnętrznemu urzędowi CA, który go wystawił.

Certyfikat samopodpisany lub podpisany lokalnie nie musi korzystać ze słabego szyfrowania. Bez wdrożonego łańcucha zaufania klient nie może jednak wiarygodnie potwierdzić tożsamości i wyświetla ostrzeżenie. Dlatego w przypadku publicznie dostępnych portali i aplikacji WAF zwykle lepszym rozwiązaniem jest publiczny urząd CA.

Wbudowany wniosek Let’s Encrypt

W Certificates > Certificates > Add wybierz Request Let’s Encrypt certificate, wpisz nazwę i dodaj FQDN w Domains. HTTP-01 nie obsługuje adresów IP ani domen wildcard. W Hosted address wybierz publiczny adres WAN, na który wskazują domeny. Jeśli publiczny adres ma router przed firewallem, jego DNAT dla TCP 80 musi przekazywać walidację na interfejs WAN firewalla; na samym firewallu żadna reguła DNAT nie może przekierowywać tego adresu i portu poza obsługę walidacji. Sprawdź istniejące publikacje i zaplanuj zmianę, zamiast usuwać reguły bez analizy.

Po Save kolumna Type pokazuje Let’s Encrypt CSR. Walidacja może potrwać kilka minut; pobierz i przypisz certyfikat dopiero po pojawieniu się Valid from, Valid until i zielonego znacznika Trusted. Nieprawidłowej lub nieistniejącej domeny nie można poprawić w istniejącym wniosku: popraw DNS i wybór domen, usuń tylko nieudany wniosek i utwórz nowy. Podlinkowana wyżej procedura Let’s Encrypt opisuje wymagania, odnowienie i kontrolę usług.

Różnice między certyfikatem, CA, kluczem prywatnym i CSR

Te cztery elementy pełnią różne funkcje:

• Certyfikat serwera: zawiera tożsamość, informacje o kluczu publicznym, objęte nim nazwy i okres ważności. Jest prezentowany klientowi.
• Klucz prywatny: potwierdza, że firewall może używać certyfikatu. Nie wolno go umieszczać w zgłoszeniach, zrzutach ekranu ani publicznych repozytoriach.
• Certyfikaty CA: tworzą łańcuch zaufania od wystawiającego pośredniego urzędu CA do głównego urzędu CA. Nie jest do tego potrzebny prywatny klucz urzędu CA.
• CSR: zawiera żądanie wystawienia certyfikatu i klucz publiczny. Gdy CSR powstaje na firewallu, powiązany z nim klucz prywatny pozostaje na urządzeniu.

Informacje i działania na liście certyfikatów

Domyślnie dla WebAdmin, User Portal i Captive Portal wybrany jest ApplianceCertificate. Istniejąca konfiguracja może być inna; przed zmianą zawsze sprawdź faktyczne przypisanie do usługi.

W Certificates > Certificates SFOS po wskazaniu nazwy certyfikatu wyświetla Subject, Issuer i Purpose. Dostępne działania pozwalają skopiować certyfikat lub pobrać go jako plik .crt; pobrany plik nie zawiera klucza prywatnego. Opcja Regenerate jest dostępna tylko dla wbudowanego ApplianceCertificate. Certyfikaty podpisane lokalnie można bezpośrednio unieważnić; SFOS automatycznie dodaje je do listy CRL Default. Kontrolowaną procedurę unieważniania opisuje artykuł Certificate Revocation Lists na Sophos Firewall.

Urząd CA używany do TLS Inspection pełni inną funkcję niż certyfikat serwera dla WebAdmin lub WAF. Podczas deszyfrowania ten urząd CA podpisuje nowe certyfikaty dla klientów. Jego wybór i dystrybucję opisuje artykuł Dystrybucja certyfikatu CA Sophos Firewall do TLS Inspection.

Szyfrowane pobieranie przez POP3 i IMAP ma również własne przypisanie TLS w Email > General settings. Skanowanie i testowanie POP3 oraz IMAP na Sophos Firewall wyjaśnia współdziałanie CA serwera poczty, weryfikacji certyfikatu, opcji skanowania i reguły zapory.

Jeśli firewall ma zostać w tym celu włączony do firmowej PKI, artykuł Konfiguracja podrzędnego urzędu CA do inspekcji TLS na Sophos Firewall opisuje proces CSR, AD CS, EKU i importu dedykowanego CA do ponownego podpisywania.

Wbudowany CA Default jest trust anchor dla lokalnie podpisanych certyfikatów. Zapisanie jego ustawień regeneruje CA i może wpłynąć na portale, SSL VPN, peery IPsec oraz klientów, którzy mu ufają. Kontrolowane odnawianie Default CA na Sophos Firewall przedstawia bezpieczną procedurę zmiany.

Okres ważności i łańcuch zaufania nie wystarczają, jeśli certyfikat został przedwcześnie unieważniony. Osobna procedura CRL wyjaśnia, jak importować, aktualizować i sprawdzać lokalne oraz zewnętrzne Certificate Revocation Lists na Sophos Firewall.

W trybie FIPS 140-3 SFOS dodatkowo weryfikuje nowo wygenerowane i zaimportowane certyfikaty pod kątem dozwolonych algorytmów klucza oraz skrótu. Włączenie tego trybu to oddzielna migracja z resetem fabrycznym, a nie zwykła zmiana certyfikatu.

Typy CA i obecność kluczy

W Certificates > Certificate authorities kolumna Type odróżnia CA firewalla od zewnętrznych CA:

• Internal: Default podpisuje certyfikaty generowane lokalnie; można edytować jego ustawienia i pobrać publiczny certyfikat.
• Built-in firewalla: SecurityAppliance_SSL_CA to wbudowany CA do podpisywania przy deszyfrowaniu. Można go pobrać i regenerować.
• Zewnętrzne Built-in: dostarczone, globalnie zaufane główne CA. Ten typ nie oznacza, że firewall posiada ich klucze prywatne.
• Uploaded: własne CA przesłane do Validation only lub Signing and validation.

Ikona klucza prywatnego potwierdza jego faktyczną obecność na firewallu. Zwykłe pobranie CA służy dystrybucji publicznego certyfikatu. Jeśli potrzebny jest pakiet odtwarzania z kluczami CA, otwórz Backup and firmware > Import export > Export selective configuration: wybierz CertificateAuthority, następnie Apply selected items, Export i Download. Chroń pakiet jak sekret i nie rozprowadzaj go na klientach; procedura eksportu selektywnego podlinkowana poniżej opisuje hasło, SSMK i ponowny import.

Regenerate rotuje CA; nie naprawia braku Trusted. Wygaśnięcie lub kompromitacja mogą wymagać rotacji, ale najpierw trzeba sprawdzić zależne usługi i zaufanie klientów. Sam zapis zmian w Default uruchamia regenerację. Dla SecurityAppliance_SSL_CA stosuj podlinkowany wyżej rollout CA do inspekcji, a dla Default osobną procedurę odnowienia.

Przygotowanie nazw, okresu ważności i łańcucha

Przed importem należy ustalić, jaką nazwę faktycznie będą otwierać użytkownicy i systemy. Współczesne aplikacje klienckie sprawdzają przede wszystkim Subject Alternative Names (SAN). Sam Common Name nie jest wiarygodnym zamiennikiem.

Przykład:

• otwierany adres URL: https://vpn.example.com
• nazwa certyfikatu w SFOS: PublicVpnExampleCom2026
• SAN w certyfikacie: vpn.example.com
• DNS: vpn.example.com wskazuje na przewidziany dostęp do firewalla lub WAF

vpn.example.com jest przykładem i należy zastąpić go własnym FQDN. Jeżeli administrator łączy się przez adres IP lub inny alias, certyfikat będzie pasował tylko wtedy, gdy ta nazwa lub ten adres IP również znajduje się w SAN.

Przed zmianą sprawdź:

• Data, godzina i NTP firewalla są prawidłowe.
• Wszystkie wymagane FQDN znajdują się jako SAN w żądaniu lub certyfikacie.
• Klucz prywatny i certyfikat tworzą pasującą parę.
• Pośredni i główny urząd CA są znane.
• Data wygaśnięcia i odpowiedzialność za odnowienie są udokumentowane.
• Dotychczasowy certyfikat i jego przypisania pozostają dostępne na potrzeby wycofania zmiany.

Preferuj synchronizację czasu z domyślnym lub własnym serwerem NTP. Nieprawidłowy czas ustawiony ręcznie może uniemożliwić import certyfikatów. Przy błędzie importu najpierw sprawdź rzeczywisty czas, zamiast zmieniać okres ważności certyfikatu.

Generowanie certyfikatu podpisanego lokalnie

Dla usługi wewnętrznej SFOS może podpisać certyfikat bezpośrednio za pomocą wbudowanego urzędu Default. Jest to właściwe rozwiązanie tylko wtedy, gdy urządzenia łączące się z usługą już ufają temu CA albo otrzymują jego publiczny certyfikat w kontrolowany sposób. W przypadku usług dostępnych publicznie zazwyczaj lepszym wyborem jest certyfikat wystawiony przez publiczny urząd CA.

W Certificates > Certificates > Add należy wybrać Generate locally-signed certificate. Następnie podaje się jednoznaczną nazwę i wymagany okres ważności; domyślnie SFOS proponuje jeden rok. Key type (RSA lub Elliptic curve), długość klucza albo krzywa oraz Secure hash muszą odpowiadać wymaganiom kryptograficznym organizacji i możliwościom klientów.

Pole Common name jest obowiązkowe w sekcji Subject. SFOS początkowo uzupełnia pola Country name, State, Locality name, Organization name, Organization unit name i kontaktowy adres e-mail danymi z licencji; przed zapisaniem należy sprawdzić każdą wartość pod kątem rzeczywistej organizacji i zamierzonego zastosowania. W Subject Alternative Names należy wprowadzić wszystkie używane nazwy DNS oraz wymagane adresy IPv4 lub IPv6.

Wymagany jest co najmniej jeden SAN albo Certificate ID. Certificate ID w Advanced settings służy wyłącznie do zgodności ze starszymi wersjami SFOS i nie zastępuje prawidłowej listy SAN dla współczesnych klientów HTTPS. Po użyciu Save należy sprawdzić wystawcę Default, okres ważności, wpisy SAN i późniejsze przypisanie do usługi.

Użyj kalendarzy Valid from i Valid until. Większe klucze RSA zwiększają koszt szyfrowania i deszyfrowania; dobieraj długość według polityki bezpieczeństwa i zgodności klientów, zamiast zawsze wybierać największą.

Dla certyfikatów podpisywanych lokalnie i CSR pola Country name, State i Locality name oznaczają kraj, region i miasto; Organization name właściciela certyfikatu, a Organization unit name odpowiedzialny dział. Distinguished name aktualizuje się wraz ze zmianą tych danych. Każdy SAN DNS, IPv4 lub IPv6 dodaj do listy przyciskiem plus i sprawdź całą listę przed Save.

Dla starszych wersji SFOS Advanced settings > Certificate ID oferuje DNS, IP address, Email i DER ASN1 DN [X.509]. DNS to rozwiązywalna nazwa domeny, IP address własny adres publiczny, a Email adres kontaktowy. DER ASN1 DN [X.509] zapewnia tożsamość distinguished name chronionego obiektu. Dobieraj typ według wymagań drugiej strony; ten starszy identyfikator nie zastępuje SAN HTTPS, również w CSR.

Zalecana metoda: generowanie CSR na firewallu

Tworzenie CSR

1. Otwórz Certificates > Certificates.
2. Wybierz Add.
3. W sekcji Action wybierz Generate certificate signing request (CSR).
4. Nadaj jednoznaczną nazwę wewnętrzną, na przykład PublicVpnExampleCom2026.
5. Wybierz wymagane ustawienia Key type, długość klucza lub krzywą oraz Secure hash zgodnie z własnymi wymaganiami bezpieczeństwa i wymaganiami urzędu CA.
6. W polu Common name wpisz główny FQDN, na przykład vpn.example.com.
7. W sekcji Subject Alternative Names dodaj co najmniej faktycznie używaną nazwę DNS.
8. Zapisz i pobierz CSR za pomocą ikony pobierania.

Sprawdź także pozostałe pola Subject i kontaktowy adres e-mail. SFOS może wstępnie uzupełnić je danymi z licencji, ale dotyczą konkretnego żądania certyfikatu i nie wolno przyjmować ich bez weryfikacji.

Wewnętrzna nazwa certyfikatu jest tylko oznaczeniem w SFOS. Nie musi odpowiadać FQDN, ale powinna wskazywać przeznaczenie i rok odnowienia. Wpisy SAN są natomiast częścią technicznej weryfikacji tożsamości i muszą pasować do późniejszego adresu URL.

Formularz CSR obsługuje też SAN DNS, IPv4 i IPv6 oraz opisane wyżej starsze typy Certificate ID. Po zapisie CSR pojawia się na liście certyfikatów. Akcja wyświetlania otwiera okno pozwalające skopiować wniosek lub pobrać go jako .csr. Przekazuj tylko wniosek, nigdy klucz prywatny; CA może na tej podstawie wystawić podrzędny CA zamiast certyfikatu serwera.

Podpisanie CSR

Przekaż pobrany CSR właściwemu publicznemu lub wewnętrznemu urzędowi certyfikacji. Jeżeli ma być używany klucz prywatny utworzony na firewallu, nie zlecaj generowania nowych plików klucza. Następnie urząd CA dostarczy podpisany certyfikat serwera oraz, zależnie od dostawcy, dodatkowe certyfikaty pośrednie.

Przed importem sprawdź:

• Urząd CA podpisał właściwy CSR.
• Lista SAN zawiera wszystkie zatwierdzone nazwy.
• Okres ważności i wystawca odpowiadają zamówieniu lub wewnętrznej polityce.
• Dostępny jest kompletny łańcuch CA.

Importowanie podpisanego certyfikatu do CSR

1. Otwórz Certificates > Certificates.
2. W wierszu właściwego CSR wybierz akcję importu w sekcji Manage.
3. Prześlij wystawiony certyfikat lub wklej jego treść.
4. Wybierz przeznaczenie odpowiednie dla wystawionego obiektu:
   • Certificate only: wystawiony certyfikat serwera lub klienta zostanie zapisany w Certificates > Certificates.
   • Certificate authority only: ta opcja dotyczy CA wystawionego na podstawie CSR, na przykład podrzędnego CA. Następnie pojawi się ono w Certificates > Certificate authorities.
   • Certificate and certificate authority: przesyłany plik zawiera zarówno wystawiony certyfikat, jak i jego główny lub podrzędny CA.
5. Wykonaj Import certificate.

Przy imporcie CA SFOS początkowo używa wartości Common Name jako nazwy CA; można ją zmienić przed importem. Certyfikat lub certyfikat CA wystawiony na podstawie CSR zostaje powiązany z odpowiednim kluczem prywatnym zapisanym na firewallu. Następnie SFOS usuwa wpis CSR. Dlatego przed importem dokładnie sprawdź, czy wybrano właściwy wiersz CSR.

Przesyłanie istniejącego certyfikatu z kluczem prywatnym

Jeżeli certyfikat i klucz zostały już utworzone poza firewallem:

1. Otwórz Certificates > Certificates > Add.
2. Wybierz Upload certificate.
3. Nadaj jednoznaczną nazwę.
4. Wybierz istniejący format pliku.
5. Prześlij certyfikat i dane klucza wymagane przez wybrany format.
6. Jeżeli klucz prywatny jest zaszyfrowany, wprowadź jego hasło.
7. Zapisz.

SFOS obsługuje następujące formaty certyfikatów:

• PEM (.pem): kodowanie Base64; certyfikat i klucz prywatny zwykle znajdują się w oddzielnych plikach.
• DER (.der) / CER (.cer): DER jest binarny; .cer może zawierać kodowanie DER lub PEM. Sprawdź rzeczywiste kodowanie, nie tylko rozszerzenie. Klucz prywatny jest osobno.
• PKCS7 (.p7b): może zawierać certyfikaty i łańcuch, ale nie klucz prywatny.
• PKCS12 (.pfx lub .p12): może zawierać razem certyfikat serwera, łańcuch CA i klucz prywatny.

Obsługiwane są klucze RSA i ECC. SFOS akceptuje hasło importowanego klucza prywatnego o długości maksymalnie 30 znaków. To ograniczenie produktu nie uzasadnia używania niezabezpieczonego klucza prywatnego: na czas transferu ustaw silne hasło mieszczące się w limicie, a po imporcie usuń plik z niezabezpieczonych lokalizacji tymczasowych.

Uzupełnianie brakującego łańcucha CA

W Certificates > Certificates zielony wpis w kolumnie Trusted oznacza, że właściwy urząd CA jest zainstalowany w SFOS. Jeżeli go brakuje, najpierw sprawdź wystawcę i łańcuch:

1. Otwórz Certificates > Certificate authorities.
2. Wybierz Add.
3. Prześlij brakujący pośredni lub główny certyfikat CA albo wklej jego treść.
4. Dla samego łańcucha zaufania wybierz Validation only.
5. Zapisz i ponownie sprawdź status Trusted certyfikatu serwera.

Przy bezpośrednim przesyłaniu CA SFOS automatycznie rozpoznaje format pliku X.509; obsługiwane są .pem, .der i .cer. Jeśli CA odpowiada CSR utworzonemu na firewallu, SFOS przejmuje nazwę CSR i ustawia przeznaczenie Signing and validation, ponieważ powiązany klucz prywatny znajduje się już na firewallu. Następnie sprawdź ikonę klucza prywatnego. Użycie jako CA do ponownego podpisywania należy do oddzielnej procedury dla podrzędnego CA TLS Inspection.

Publiczny certyfikat głównego lub pośredniego urzędu CA nie potrzebuje klucza prywatnego do weryfikacji. Opcja Signing and validation jest przeznaczona wyłącznie dla urzędu CA, za pomocą którego firewall ma sam podpisywać certyfikaty i którego klucz prywatny świadomie zapisano na firewallu.

Import zewnętrznego CA do podpisywania bez pasującego CSR na firewallu

Ta procedura dotyczy pośredniego CA utworzonego zewnętrznie, którym firewall będzie podpisywać certyfikaty, a nie certyfikatu serwera ani łańcucha służącego wyłącznie do weryfikacji. Potrzebne są certyfikat CA i własny klucz prywatny tego CA, sprawdzone jako pasująca para. Nie przenoś klucza głównego CA na firewall. CSR generowany na firewallu pozostaje preferowaną metodą, ponieważ nie wymaga transportu kluczy.

Jeśli CA do podpisywania zawiera Extended Key Usage (EKU), musi uwzględniać TLS Web Server Authentication. Nie zmieniaj CA używanego już do ponownego podpisywania na Validation only: utraci funkcję podpisywania potrzebną do ponownego szyfrowania odszyfrowanego ruchu SSL/TLS. Przed zmianą zachowaj backup, dotychczasowy wybór CA i informacje o zależnościach.

Przed przypisaniem sprawdź też wszystkie planowane wybory CA do ponownego podpisywania: Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings, Profiles > Decryption profiles oraz Web > General settings w HTTPS decryption and scanning. Można tam używać tylko CA z Signing and validation. CA z zielonym Trusted, ale bez klucza do podpisywania, nie jest zamiennikiem.

1. Otwórz Certificates > Certificate authorities i wybierz Add, nie listę certyfikatów serwera.
2. Prześlij certyfikat pośredniego CA lub wklej jego treść. SFOS automatycznie rozpoznaje .pem, .der i .cer.
3. SFOS szuka pasującego CSR na firewallu. Jeśli go znajdzie, przejmuje jego nazwę i Signing and validation; klucz prywatny jest już na firewallu. W razie potrzeby zmień proponowaną nazwę i wybierz Save. Nie trzeba przesyłać dodatkowego klucza.
4. Bez pasującego CSR pojawiają się dodatkowe opcje. W Use certificate for wybierz Signing and validation dla tego CA do podpisywania.
5. Prześlij Private key tego pośredniego CA, nie klucz prywatny certyfikatu serwera. Wprowadź hasło klucza do szyfrowania; może zawierać maksymalnie 30 znaków. Do transferu użyj chronionego klucza i silnego hasła mieszczącego się w limicie.
6. Wprowadź jednoznaczną nazwę CA lub zmień proponowaną nazwę, a następnie wybierz Save.
7. Oddzielnie prześlij lub wklej powiązany główny CA przez Certificates > Certificate authorities > Add, ustaw Use certificate for na Validation only i wybierz Save. Weryfikuje pośredni CA i nie potrzebuje do tego klucza prywatnego.
8. W Certificates > Certificates sprawdź zielony znacznik Trusted przy zaimportowanym certyfikacie serwera. Następnie w Certificates > Certificate authorities otwórz filtr obok Type, wybierz Uploaded i kliknij Apply. Przy pośrednim/podrzędnym CA musi pojawić się ikona klucza prywatnego; potwierdza obecność klucza do podpisywania, a nie powodzenie testu ruchu.

Jeśli brakuje Trusted, sprawdź wystawcę i pełny łańcuch; jeśli brakuje ikony klucza, sprawdź parę CA-klucz, import i hasło przed przypisaniem CA. Sam import nie zmienia wyboru CA do inspekcji TLS. Firmowy CSR/AD CS, wybór ruchu i test pilotażowy pozostają w powiązanej procedurze podrzędnego CA TLS Inspection. Przy późniejszej zmianie zachowaj poprzedni wybór do wycofania zmiany; nowe wpisy usuwaj dopiero po potwierdzeniu braku zależności. Powrót do poprzedniego CA nie cofa transferu klucza: usuń pliki importu z niezabezpieczonych lokalizacji tymczasowych i zachowaj chronione kopie odzyskiwania zgodnie z polityką PKI.

Upgrade do SFOS 21: kontrola zarezerwowanych nazw CA

Podczas upgrade’u do SFOS 21 NC-146082 może zablokować migrację. Przyczyną nie jest ważność certyfikatu, lecz istniejący wpis CA o nazwie, której SFOS 21 potrzebuje dla wbudowanych CA Let’s Encrypt:

Lets_Encrypt_R10
Lets_Encrypt_R11
Lets_Encrypt_R12
Lets_Encrypt_R13
Lets_Encrypt_R14
Lets_Encrypt_E5
Lets_Encrypt_E6
Lets_Encrypt_E7
Lets_Encrypt_E8
Lets_Encrypt_E9

Przed oknem serwisowym:

1. Utworzyć świeży backup konfiguracji i przygotować hasło backupu oraz Secure Storage Master Key.
2. W Certificates > Certificate authorities wyszukać dokładne nazwy. Jeśli nie ma zgodności, NC-146082 nie wymaga żadnej zmiany.
3. W przypadku zgodności udokumentować typ, Subject, Issuer, przeznaczenie i obecność ikony klucza. Ikona oznacza, że firewall posiada klucz prywatny CA.
4. CA z kluczem prywatnym dodatkowo wyeksportować w Backup and firmware > Import export > Export selective configuration jako CertificateAuthority. Bezpieczną procedurę dla pakietu, SSMK i ponownego importu opisuje Selektywny eksport i import konfiguracji. Następnie ustalić, które certyfikaty i usługi zależą od tej CA, na przykład VPN, WebAdmin i portale, WAF, SMTP TLS lub TLS Inspection.
5. Wpis skonfigurowany przez administratora usunąć dopiero po zastąpieniu wszystkich zależności lub potwierdzeniu, że nie są już potrzebne. Następnie ponowić upgrade.

Nie usuwać wbudowanej CA. Jeśli WebAdmin odmawia usunięcia, brakuje pierwotnego klucza prywatnego lub odwołanie pozostaje niejasne, należy przerwać upgrade i skontaktować się z pomocą techniczną Sophos. Zmiany w bazie danych lub Advanced Shell nie są bezpieczną alternatywą.

Po aktualizacji należy sprawdzić, czy wbudowane CA Let’s Encrypt są dostępne, zależne certyfikaty ponownie mają stan Trusted, a powiązane usługi działają.

Przypisywanie certyfikatu do właściwej usługi

Przed przypisaniem: przygotowanie wycofania zmiany

Zmiany certyfikatu nie należy rozpoczynać od usunięcia starego wpisu:

1. Zaimportuj nowy certyfikat i kompletny łańcuch CA.
2. Sprawdź SAN, wystawcę, okres ważności i Trusted.
3. Udokumentuj dotychczasowe przypisanie i objęte nim usługi.
4. Najpierw przypisz nowy certyfikat do jednego celu przypisania. Grupa WebAdmin i portali jest przełączana wspólnie, natomiast reguły WAF i SMTP można zmieniać osobno.
5. Przetestuj wszystkie usługi objęte tym celem przypisania przy użyciu ich rzeczywistych FQDN i portów.
6. W razie błędu natychmiast ponownie wybierz stary certyfikat.
7. Kolejno przełączaj pozostałe cele przypisania i za każdym razem je sprawdzaj.
8. Usuń stary certyfikat dopiero wtedy, gdy nie ma już żadnych odwołań, a nowa konfiguracja działa stabilnie.

WAF i SMTP można przełączać kolejno. WebAdmin, User Portal, VPN Portal, Captive Portal i oba portale SPX są natomiast przełączane jednocześnie za pomocą wspólnego wyboru certyfikatu.

Pełną procedurę dotyczącą FQDN portalu, rejestracji hasła, Reply Portal i przepływu poczty opisano w Konfiguracja i testowanie szyfrowania poczty SPX.

Podczas zmiany w WebAdmin pozostaw również otwartą istniejącą sesję administratora i alternatywny lokalny dostęp administracyjny, dopóki logowanie i certyfikat nie zostaną sprawdzone przez docelowy FQDN.

WebAdmin i portale

W Administration > Admin and user settings > Admin console and end-user interaction wybiera się wspólny certyfikat dla następujących usług:

• WebAdmin Console
• User Portal
• VPN Portal
• Captive Portal
• SPX Registration Portal
• SPX Reply Portal

W polu Certificate wybierz nowy certyfikat i zapisz za pomocą Apply. Certyfikat musi obejmować wszystkie FQDN, pod którymi dostępne są używane usługi. Jeżeli na przykład admin.example.com służy do WebAdmin, a vpn.example.com do VPN Portal, obie nazwy muszą znajdować się w SAN albo trzeba ujednolicić plan adresów URL.

W przypadku administracji wyłącznie wewnętrznej SFOS może również zabezpieczyć nazwę WebAdmin certyfikatem podpisanym lokalnie. W Certificates > Certificates > Add wybierz Generate locally-signed certificate, a następnie w polach Common name oraz DNS names wpisz dokładnie rozwiązywalną wewnętrznie nazwę hosta firewalla, na przykład fw01.example.com. Następnie w Administration > Admin and user settings ustaw tę samą wartość jako Hostname, wybierz nowy Certificate i włącz Use the firewall’s configured hostname.

Aby przeglądarki ufały temu certyfikatowi, pobierz publiczny certyfikat CA Default z Certificates > Certificate authorities, rozpakuj archiwum i rozprowadź Default.der lub Default.pem jako Default.crt na zarządzane urządzenia końcowe. Artykuł Dystrybucja certyfikatu CA Sophos Firewall do inspekcji TLS opisuje bezpieczną dystrybucję i kontrolę w systemach Windows, macOS oraz Firefox. Rozprowadzany jest wyłącznie publiczny certyfikat CA, nigdy klucz prywatny.

Zmiana nazwy na Default.crt zmienia tylko nazwę pliku; nie konwertuje DER na PEM ani nie ustanawia zaufania. Użyj formatu obsługiwanego przez okno importu i porównaj fingerprint SHA-256 własnego CA Default przed importem i po nim. Sam zgodny hostname nie usuwa błędu zaufania: poprawne muszą być też zaufanie do CA, SAN i ważność. Następnie sprawdź nowe połączenie przeglądarki i logowanie przez docelowy FQDN; nie pomijaj pozostałych ostrzeżeń.

⚠️ Ta metoda usuwa ostrzeżenie przeglądarki tylko na zarządzanych urządzeniach, które ufają CA Default. Nie sprawia, że certyfikat staje się publicznie zaufany. Jeśli CA Default zostanie później wygenerowany ponownie, certyfikaty i dystrybucję zaufania trzeba odnowić w kontrolowany sposób.

Certyfikat VPN Portal zabezpiecza stronę HTTPS, z której użytkownicy pobierają profile i oprogramowanie klienckie. Nie staje się automatycznie certyfikatem Local lub Remote tunelu IPsec.

Artykuł Konfiguracja IPsec Site-to-Site z certyfikatami wyjaśnia współdziałanie CA, Certificate ID, Local Certificate i Remote Certificate między dwoma firewallami.

Przywracanie domyślnego certyfikatu WebAdmin przez konsolę

Jeśli po błędnym przypisaniu certyfikatu WebAdmin przestaje działać, sprawny dostęp CLI do Main Menu może służyć jako ścieżka break-glass. Najpierw należy udokumentować używany FQDN, poprzednie przypisanie certyfikatu i oczekiwany fingerprint. Istniejącą otwartą sesję administratora należy zachować.

Jeśli aktualnie otwarta jest opcja 4. Device Console, należy najpierw wrócić do Main Menu. Następnie należy otworzyć 2. System Configuration > 4. Reset Default Web Admin Certificate i potwierdzić reset przez y. SFOS ustawia dla konsoli WebAdmin domyślny certyfikat urządzenia. Operacja nie przywraca ani wcześniej wybranego certyfikatu, ani starego klucza prywatnego CA Default i nie regeneruje tej CA. Dostarczona CA Default jest również częścią łańcucha HTTPS stron blokowania i ostrzegania web proxy, ale opcja 4 nie resetuje tej funkcji proxy. Dlatego przy lokalnie podpisanym certyfikacie domyślnym może pojawić się ostrzeżenie przeglądarki lub błąd nazwy.

Po komunikacie o powodzeniu należy ponownie otworzyć WebAdmin wyłącznie przez przewidzianą ścieżkę zarządzania, sprawdzić rzeczywiście prezentowany certyfikat i przetestować nowe logowanie. Ponieważ WebAdmin i kilka portali korzystają z tego samego wyboru certyfikatu, należy również sprawdzić wszystkie używane portale. Następnie można kontrolowanie ponownie przypisać naprawiony certyfikat produkcyjny w Administration > Admin and user settings. Reset z konsoli jest ścieżką odzyskiwania, a nie trwałym rozwiązaniem zaufania publicznego.

WAF

W przypadku publikacji WAF edytuj odpowiednią regułę w Rules and policies > Firewall, włącz HTTPS, wybierz nowy certyfikat w polu HTTPS certificate i zapisz. Reguła korzysta z opcji Protect with web server protection. SNI, domena w regule i SAN w certyfikacie muszą wskazywać tę samą nazwę hosta.

Zmiana reguły WAF ponownie uruchamia reguły Web Server Protection i zrywa istniejące połączenia. Dlatego w środowisku produkcyjnym zmianę certyfikatu należy przeprowadzać w oknie serwisowym. Pełny proces publikacji i kontroli opisuje artykuł Sophos Firewall WAF: bezpieczna publikacja serwera WWW.

SMTP TLS w trybie MTA

W Email > General settings > SMTP TLS configuration pole TLS certificate wykorzystuje, zależnie od konfiguracji, certyfikat CA lub serwera do skanowania połączeń SMTP przez TLS. Przed zmianą udokumentuj dotychczasowe przeznaczenie, weryfikację certyfikatów oraz objęte zmianą połączenia przychodzące i wychodzące. Jeśli firewall prezentuje własną tożsamość serwera w publicznej komunikacji SMTP, zalecany jest do tego certyfikat publicznego urzędu CA. Po wybraniu Apply przetestuj oba kierunki ruchu z faktycznie używanymi trybami TLS. Pozostałą konfigurację przepływu poczty opisuje artykuł Sophos Firewall Mail Protection w trybie MTA.

Po zmianie utwórz aktualną kopię zapasową Sophos Firewall oraz udokumentuj datę wygaśnięcia, właściciela i termin kolejnego odnowienia.

Kontrola certyfikatu i sposobu jego dostarczania

Sprawdzanie pliku przed importem

Na komputerze administratora można odczytać certyfikat PEM za pomocą OpenSSL:

openssl x509 -in firewall.pem -noout -subject -issuer -dates -ext subjectAltName -fingerprint -sha256

Zastąp firewall.pem lokalną ścieżką do pliku. Wynik powinien pokazać oczekiwany Subject, wystawcę, okres ważności, wymagane wpisy SAN i odcisk SHA-256. Polecenie nie odczytuje klucza prywatnego.

W przypadku certyfikatu wygenerowanego zewnętrznie klucz publiczny wyprowadzony z klucza prywatnego musi być zgodny z kluczem publicznym certyfikatu:

(
tmpdir=$(mktemp -d)
trap 'rm -rf -- "$tmpdir"' EXIT
openssl x509 -in firewall.pem -pubkey -noout > "$tmpdir/cert-public-key.pem" &&
  openssl pkey -in firewall.key -pubout > "$tmpdir/key-public-key.pem" &&
  cmp "$tmpdir/cert-public-key.pem" "$tmpdir/key-public-key.pem"
)

Zastąp firewall.key lokalną ścieżką do klucza prywatnego. W przypadku zaszyfrowanego klucza openssl pkey interaktywnie poprosi o hasło. Gdy klucze publiczne są identyczne, cmp nie wyświetla żadnego wyniku; w przeciwnym razie pary nie wolno importować. Pliki tymczasowe zawierają tylko klucze publiczne, ale mimo to po porównaniu są usuwane. Nigdy nie wyświetlaj ani nie przesyłaj klucza prywatnego i nie dołączaj go do zgłoszenia.

Sprawdzanie usługi HTTPS z zewnątrz

Przetestuj WebAdmin, portale i WAF z komputera administratora za pomocą OpenSSL:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts -verify_hostname vpn.example.com -verify_return_error </dev/null

Zastąp FQDN i port rzeczywistymi danymi usługi HTTPS. Parametr -servername wysyła nazwę przez SNI, aby w przypadku wielu celów WAF lub portali wybrany został właściwy certyfikat. -showcerts pokazuje wszystkie certyfikaty wysłane przez usługę; serwer zwykle nie musi wysyłać głównego CA. W wyniku muszą pojawić się oczekiwany certyfikat serwera i pośrednie CA wymagane do zbudowania łańcucha. Verification: OK dodatkowo potwierdza kontrolę nazwy hosta i łańcucha względem magazynu zaufania komputera testowego. Obecny już w nim pośredni CA może jednak ukryć niekompletny łańcuch dostarczany przez serwer.

W przypadku wewnętrznego urzędu CA komputer administratora musi już mu ufać lub otrzymać go jawnie jako kotwicę zaufania do testu. W przeciwnym razie błąd weryfikacji może dotyczyć urządzenia testowego, mimo że firewall dostarcza właściwy łańcuch.

Sprawdzanie SMTP z STARTTLS

SMTP na porcie 25 lub 587 zwykle rozpoczyna połączenie bez szyfrowania i dopiero za pomocą STARTTLS przechodzi na TLS. Wymaga to osobnego testu:

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -verify_hostname mail.example.com -verify_return_error </dev/null

Zastąp mail.example.com i port 25 FQDN usługi SMTP oraz faktycznie używanym portem STARTTLS. W przypadku niejawnego TLS na porcie 465 nie używa się -starttls smtp. Również tutaj oczekiwany certyfikat, nazwa hosta i komunikat Verification: OK muszą być zgodne.

Dodatkowo sprawdź w przeglądarce lub kliencie:

• Adres URL używa jednego z uwzględnionych SAN.
• Wystawca i data wygaśnięcia odpowiadają nowemu certyfikatowi.
• Nie pojawia się ostrzeżenie o certyfikacie.
• Oczekiwana usługa WebAdmin, usługa portalowa, WAF lub pocztowa działa.
• Test zewnętrzny nie widzi nadal certyfikatu load balancera lub reverse proxy umieszczonego przed firewallem.

Typowe błędy i kolejny krok kontroli

• Pole Trusted pozostaje puste: brakuje pośredniego urzędu CA, zaimportowano niewłaściwy urząd CA lub łańcuch nie należy do certyfikatu serwera. Sprawdź wystawcę i kolejność urzędów CA.
• Import jest odrzucany: sprawdź format pliku, hasło klucza prywatnego, limit 30 znaków, parę certyfikat–klucz i czas systemowy.
• Przeglądarka zgłasza nieprawidłową nazwę: otwieranego FQDN lub adresu IP nie ma w SAN. Porównaj adres URL, DNS i nazwy w certyfikacie.
• Przeglądarka nadal wyświetla stary certyfikat: usługa nadal korzysta ze starego przypisania albo serwer proxy znajdujący się przed firewallem kończy połączenie TLS. Sprawdź za pomocą openssl s_client i SNI bezpośrednio na oczekiwanym celu.
• WAF dostarcza niewłaściwy certyfikat: sprawdź Hosted Address, Listen Port, Domain, SNI i kolejność nakładających się reguł WAF.
• Ostrzeżenie pojawia się tylko na niektórych klientach: sprawdź Trust Store, certyfikaty pośrednie, czas systemowy oraz ewentualne ograniczenia Certificate Pinning na danym kliencie.
• Po zmianie portal jest niedostępny: ponownie wybierz stary certyfikat, a następnie oddzielnie sprawdź FQDN, port, Device Access i łańcuch certyfikatów.

FAQ