brak certyfikatu SSL dla serwera

Brak certyfikatu SSL dla serwera to luka bezpieczeństwa uniemożliwiająca szyfrowanie połączeń z tą infrastrukturą.

Brak certyfikatu SSL a działanie połączenia z serwerem

Brak certyfikatu SSL dla serwera oznacza, że usługa nie może prawidłowo ustanowić połączenia HTTPS opartego na protokole TLS. Nazwa SSL jest utrwalona w języku technicznym, jednak współczesne połączenia wykorzystują TLS, ponieważ SSL 2.0 i SSL 3.0 są przestarzałe i nie powinny być używane. Certyfikat X.509 przekazuje klientowi między innymi nazwę podmiotu, klucz publiczny, okres ważności oraz podpis urzędu certyfikacji. Dzięki temu klient może sprawdzić, czy serwer przedstawia właściwą tożsamość i czy klucz publiczny został zatwierdzony przez zaufany łańcuch certyfikatów.

Jeżeli serwer nie ma certyfikatu przypisanego do usługi TLS, połączenie z adresem HTTPS zwykle kończy się błędem negocjacji. Przeglądarka może wyświetlić komunikat o niemożności nawiązania bezpiecznego połączenia, a klient innego typu może zgłosić błąd weryfikacji certyfikatu albo przerwać połączenie. Sam brak certyfikatu nie oznacza jeszcze, że serwer jest wyłączony. Usługa może nadal odpowiadać przez HTTP, lecz dane przesyłane takim kanałem nie są chronione mechanizmami zapewnianymi przez TLS.

Jakie zagrożenia powstają bez uwierzytelnienia TLS

Połączenie HTTP bez TLS nie zapewnia poufności transmisji. Treść żądań i odpowiedzi może być odczytana przez urządzenie znajdujące się na drodze komunikacji, zależnie od topologii sieci i zakresu dostępu do ruchu. Dotyczy to także nagłówków HTTP, parametrów adresu URL, przesyłanych formularzy oraz identyfikatorów sesji, jeśli aplikacja umieszcza je w transmisji. Brak szyfrowania nie jest równoważny z konkretnym dowodem przechwycenia danych, ale usuwa podstawową warstwę ochrony przed takim odczytem.

Brak poprawnego certyfikatu uniemożliwia także wiarygodne powiązanie nazwy domenowej z kluczem publicznym serwera. Użytkownik może zostać skierowany do innego punktu końcowego, a klient nie ma prawidłowej podstawy do potwierdzenia tożsamości serwera. Bez integralności zapewnianej przez TLS treść odpowiedzi może zostać zmieniona podczas transmisji. W praktyce ryzyko zależy od rodzaju usługi, sposobu uwierzytelniania oraz tego, czy ruch przechodzi przez sieci, którym nie można ufać. Szczególnie istotne są logowanie, formularze, tokeny sesyjne i pliki pobierane przez użytkownika.

Weryfikacja certyfikatu i konfiguracji usługi

Sprawdzenie problemu powinno objąć adres używany przez klienta, port usługi oraz konfigurację serwera TLS. Certyfikat musi obejmować nazwę znajdującą się w żądaniu klienta, zwykle przez pole Subject Alternative Name. Należy również sprawdzić datę rozpoczęcia i zakończenia ważności, podpis urzędu certyfikacji, kompletny łańcuch certyfikatów oraz zgodność klucza prywatnego z kluczem publicznym zapisanym w certyfikacie. Certyfikat wystawiony dla innej nazwy, wygasły albo podpisany przez niezaufany urząd może powodować błąd podobny do problemu z całkowitym brakiem certyfikatu.

Do wstępnego sprawdzenia publicznie dostępnej usługi można użyć polecenia openssl s_client -connect example.com:443 -servername example.com -showcerts. Parametr -connect wskazuje host i port, a -servername wysyła nazwę SNI, dzięki czemu serwer może wybrać właściwy certyfikat spośród kilku konfiguracji na jednym adresie IP. Wynik pozwala zobaczyć przedstawiony certyfikat, daty ważności oraz informacje o weryfikacji łańcucha. Samo polecenie nie naprawia konfiguracji i nie zastępuje kontroli ustawień usługi, zapory sieciowej ani mechanizmu automatycznego odnawiania certyfikatów.

Skutki naprawy i kontrola po wdrożeniu

Usunięcie problemu polega na uzyskaniu certyfikatu odpowiedniego dla używanej nazwy, zainstalowaniu certyfikatu wraz z wymaganymi certyfikatami pośrednimi oraz przypisaniu go do właściwego endpointu TLS. Konieczne jest także zapewnienie dostępu usługi do odpowiadającego klucza prywatnego i ustawienie poprawnego zakresu nazw. Jeżeli serwer obsługuje wiele domen, każda nazwa używana przez klientów powinna być uwzględniona w certyfikacie albo obsłużona przez właściwy mechanizm wyboru certyfikatu. Po zmianie konfiguracji usługę należy przeładować zgodnie z jej dokumentacją.

Kontrola końcowa powinna obejmować połączenie z rzeczywistą nazwą domenową, sprawdzenie ostrzeżeń w przeglądarce lub aplikacji klienckiej oraz ponowne odczytanie certyfikatu z portu używanego przez usługę. Warto zweryfikować także przekierowanie z HTTP do HTTPS, odnowienie certyfikatu przed upływem jego ważności i działanie wszystkich nazw alternatywnych. W przypadku laptopa lub komputera PC problem może być widoczny jako ostrzeżenie przy otwieraniu strony albo błąd programu korzystającego z sieci. Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i podzespołów, natomiast diagnostyka samego certyfikatu wymaga dostępu do konfiguracji usługi oraz środowiska, w którym działa serwer.