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.
• 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.

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.

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.

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: public-vpn-example-com-2026
• 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.

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 public-vpn-example-com-2026.
5. Wybierz wymagane ustawienia Key Type, długość klucza lub krzywą oraz funkcję skrótu 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.

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.

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. Jako przeznaczenie zwykle wybierz Certificate only. Jeżeli ten sam plik zawiera również łańcuch CA, wybierz odpowiednie przeznaczenie certyfikatu i CA.
5. Wykonaj Import certificate.

SFOS przypisuje certyfikat do klucza prywatnego znajdującego się na firewallu, a następnie 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) i CER (.cer): binarne formaty certyfikatów; klucz prywatny znajduje się w oddzielnym pliku.
• 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.

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.

Upgrade do SFOS 21 lub nowszej wersji: kontrola zarezerwowanych nazw CA

Podczas pierwszego upgrade’u starszej instalacji do SFOS 21 lub nowszej wersji NC-146082 może zablokować migrację. Przyczyną nie jest ważność certyfikatu, lecz istniejący wpis CA o nazwie, której SFOS 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. 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 jednej usługi.
5. Przetestuj tę usługę przy użyciu jej rzeczywistego FQDN i portu.
6. W razie błędu natychmiast ponownie wybierz stary certyfikat.
7. Kolejno przełączaj pozostałe usługi 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.

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.

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.

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 przypadku Mail Protection wybierz nowy certyfikat serwera w polu TLS certificate w Email > General settings > SMTP TLS configuration i zapisz za pomocą Apply. Do publicznej komunikacji SMTP zalecany jest certyfikat publicznego urzędu CA, aby systemy zdalne mogły sprawdzać tożsamość bez wdrażania własnego urzędu CA. 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.

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 -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. Test jest pomyślny, gdy pojawi się oczekiwany certyfikat, nazwa hosta będzie zgodna, a na końcu widoczny będzie komunikat Verification: OK.

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