Certyfikat SSL/TLS

Certyfikat SSL/TLS to plik kryptograficzny umożliwiający szyfrowanie połączenia między klientem a serwerem bazodanowym.

Certyfikat X.509 a szyfrowanie połączenia TLS

Certyfikat SSL/TLS jest dokumentem cyfrowym w formacie X.509, który pozwala powiązać klucz publiczny z określoną nazwą usługi, na przykład nazwą domenową serwera. Sam certyfikat nie szyfruje danych bezpośrednio. Dostarcza klientowi informacji potrzebnych do uwierzytelnienia serwera oraz do bezpiecznego uzgodnienia parametrów sesji TLS. W praktyce przeglądarka, program pocztowy albo klient bazy danych sprawdza, czy serwer przedstawia certyfikat wystawiony dla właściwej nazwy i podpisany przez zaufany urząd certyfikacji.

Określenie SSL jest historyczne. Protokoły SSL 2.0 i SSL 3.0 zostały wycofane ze względów bezpieczeństwa, dlatego współczesne połączenia powinny korzystać z TLS, czyli Transport Layer Security. Najczęściej spotyka się TLS 1.2 oraz TLS 1.3. Certyfikat może być używany w obu wersjach, ale sposób negocjowania algorytmów i wymiany kluczy zależy od konkretnej wersji protokołu oraz konfiguracji klienta i serwera. Certyfikat nie zastępuje więc samego TLS, lecz jest jednym z elementów całego mechanizmu bezpiecznego połączenia.

Jak klient weryfikuje nazwę i łańcuch zaufania

Podczas nawiązywania połączenia TLS serwer przesyła klientowi swój certyfikat, a często także certyfikaty pośrednich urzędów certyfikacji. Klient sprawdza podpis cyfrowy, okres ważności, przeznaczenie klucza oraz łańcuch prowadzący do głównego urzędu certyfikacji znajdującego się w lokalnym magazynie zaufania. Jeżeli któregoś certyfikatu pośredniego brakuje albo podpis nie może zostać zweryfikowany, program może zgłosić błąd zaufania, mimo że sam certyfikat serwera nie jest uszkodzony.

Ważne jest również dopasowanie nazwy. Współczesne klienty sprawdzają przede wszystkim pole Subject Alternative Name, skrótowo SAN. Musi ono zawierać nazwę hosta używaną w połączeniu, na przykład db.example.pl. Certyfikat wystawiony dla innej domeny, dla samej domeny głównej zamiast subdomeny albo dla adresu IP użytego zamiast nazwy DNS może powodować ostrzeżenie. Symbol wieloznaczny, taki jak *.example.pl, obejmuje tylko nazwy zgodne z regułami certyfikatu i nie oznacza automatycznie dowolnego poziomu zagnieżdżenia.

Klucz prywatny, handshake i ochrona sesji

Do certyfikatu przypisany jest klucz publiczny, natomiast serwer przechowuje odpowiadający mu klucz prywatny. Klucz prywatny nie powinien być udostępniany klientom ani umieszczany w zwykłych katalogach dostępnych dla nieuprawnionych użytkowników. W czasie uzgadniania TLS serwer dowodzi, że posiada właściwy klucz prywatny, a klient może dzięki temu sprawdzić autentyczność drugiej strony. Następnie obie strony uzgadniają wspólny sekret sesyjny, który służy do szyfrowania właściwych danych.

W TLS 1.2 i TLS 1.3 stosuje się współczesne mechanizmy wymiany kluczy oraz szyfrowanie symetryczne do transmisji po zakończeniu uzgadniania. Certyfikat służy przede wszystkim do uwierzytelnienia i podpisywania elementów negocjacji, a nie do szyfrowania całego strumienia danych kluczem publicznym. Dzięki takiemu podziałowi połączenie może zapewnić poufność, integralność oraz wykrywanie modyfikacji danych przesyłanych między klientem a serwerem bazodanowym. Przy konfiguracji należy także kontrolować datę i czas systemowy, ponieważ nieprawidłowy zegar może sprawić, że ważny certyfikat zostanie uznany za jeszcze nieważny albo już wygasły.

Typowe objawy błędnej konfiguracji na komputerze

Błąd certyfikatu może pojawić się jako komunikat o wygasłym certyfikacie, niezgodnej nazwie hosta, niezaufanym wystawcy albo niepełnym łańcuchu certyfikacji. Przyczyną bywa także brak aktualnych certyfikatów głównych w systemie, niepoprawnie ustawiona data, przechwytywanie ruchu TLS przez oprogramowanie zabezpieczające lub wskazanie niewłaściwego portu i trybu szyfrowania w kliencie. W przypadku aplikacji łączącej się z bazą danych trzeba dodatkowo sprawdzić, czy klient obsługuje wymagany protokół TLS i czy nazwa użyta w konfiguracji odpowiada nazwie zapisanej w SAN.

Diagnostyka powinna rozdzielać problem lokalny od problemu po stronie serwera. Można porównać wynik połączenia na innym komputerze, sprawdzić szczegóły certyfikatu w przeglądarce lub narzędziu klienta oraz zweryfikować datę ważności i pełny łańcuch. Nie należy omijać ostrzeżenia przez bezwarunkowe wyłączenie weryfikacji certyfikatu, ponieważ usuwa to kontrolę autentyczności serwera i może pozwolić na połączenie z niewłaściwym endpointem. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, dlatego może sprawdzić lokalną konfigurację systemu oraz aplikacji, gdy problem z certyfikatem uniemożliwia prawidłowe korzystanie z komputera.