Obsługa certyfikatów SSL/TLS

Obsługa certyfikatów SSL/TLS to konfiguracja szyfrowania połączeń klientów z instancją SQL Server.

Obsługa certyfikatów SSL/TLS w połączeniach z SQL Server

Obsługa certyfikatów SSL/TLS obejmuje przygotowanie, wdrożenie, kontrolę i odnowienie certyfikatu używanego do ochrony połączeń z instancją SQL Server. Certyfikat potwierdza tożsamość punktu, z którym łączy się klient, a jednocześnie umożliwia szyfrowanie danych przesyłanych pomiędzy aplikacją, narzędziem administracyjnym lub usługą a bazą danych. Dzięki temu informacje uwierzytelniające, zapytania, wyniki zapytań i inne dane nie są przekazywane w postaci łatwej do odczytania przez osoby obserwujące ruch sieciowy.

W praktyce nie wystarcza samo wygenerowanie pliku certyfikatu. Należy ustalić nazwę używaną przez klientów, sprawdzić zaufanie do wystawcy, dobrać właściwy magazyn certyfikatów, przypisać certyfikat do konkretnej instancji oraz zweryfikować sposób, w jaki poszczególne aplikacje nawiązują połączenie. Znaczenie ma także poprawna konfiguracja nazwy serwera w certyfikacie. Jeżeli klient odwołuje się do innej nazwy niż ta, która znajduje się w polu przeznaczonym dla nazwy podmiotu lub w rozszerzeniu SAN, może pojawić się ostrzeżenie albo odmowa połączenia.

SSL i TLS są często używane jako określenia całego mechanizmu szyfrowania, choć współczesne wdrożenia powinny opierać się na aktualnych wersjach protokołu TLS. Starsze rozwiązania mogą pozostawać w konfiguracji systemu z powodów zgodności, jednak ich obecność wymaga oceny ryzyka. Przydatne jest rozdzielenie dwóch kwestii: szyfrowania kanału komunikacji oraz weryfikacji tożsamości serwera. Samo szyfrowanie bez sprawdzania certyfikatu może ograniczać ochronę przed podsunięciem fałszywego punktu końcowego.

Obsługa certyfikatów SSL/TLS a zaufanie klienta

Po stronie SQL Server certyfikat musi być dostępny w odpowiednim magazynie systemowym i spełniać wymagania dotyczące klucza prywatnego, przeznaczenia oraz uprawnień konta uruchamiającego usługę. W środowisku z wieloma instancjami trzeba sprawdzić, do której instancji odnosi się konfiguracja i czy zmiana certyfikatu nie wpłynie na inne usługi. Po stronie klienta istotny jest łańcuch zaufania, czyli certyfikat serwera oraz certyfikaty pośrednie prowadzące do zaufanego urzędu certyfikacji.

Możliwe jest wykorzystanie certyfikatu wystawionego przez publiczny urząd certyfikacji, wewnętrzny urząd działający w organizacji albo certyfikatu testowego. Każde rozwiązanie ma inne zastosowanie. Certyfikat publiczny bywa wygodny przy połączeniach z urządzeń, które nie należą do jednej kontrolowanej domeny. Certyfikat wewnętrzny pozwala centralnie zarządzać zaufaniem, ale wymaga prawidłowej dystrybucji certyfikatu głównego i pośrednich. Certyfikat testowy może służyć do sprawdzenia konfiguracji, lecz przed zastosowaniem produkcyjnym należy ocenić jego ważność, zakres i sposób zaufania.

Ważnym elementem jest ustawienie właściwego poziomu wymuszania szyfrowania. Gdy szyfrowanie jest wymagane, niezgodność certyfikatu, brak zaufanego wystawcy albo błędna nazwa może zatrzymać połączenie. Gdy szyfrowanie jest tylko opcjonalne, część klientów może działać w sposób odmienny od zakładanego. Dlatego testy powinny obejmować każdy używany sterownik, bibliotekę i typ aplikacji, a nie wyłącznie jedno narzędzie administracyjne.

Typowe problemy przy obsłudze certyfikatów SSL/TLS

Jednym z częstych problemów jest wygaśnięcie certyfikatu. Objawy mogą pojawić się nagle, szczególnie gdy certyfikat był odnawiany bez wcześniejszego sprawdzenia, czy nowy klucz prywatny jest dostępny dla usługi. Inną przyczyną jest brak certyfikatu pośredniego na komputerze klienckim. W takim przypadku certyfikat serwera może wyglądać poprawnie, ale ścieżka zaufania nie zostanie zbudowana.

Problemy mogą wynikać również z niezgodności nazwy. Połączenie przez alias, nazwę krótką, nazwę w pełni kwalifikowaną albo adres zapisany w konfiguracji aplikacji może skutkować inną oceną certyfikatu. Należy także uwzględnić certyfikaty wielonazwowe, ponieważ jedna usługa może być dostępna pod kilkoma nazwami. Sam fakt, że certyfikat znajduje się w magazynie systemowym, nie potwierdza jeszcze, że jest odpowiedni dla konkretnego zastosowania.

Na diagnostykę wpływają także ustawienia sterownika. Niektóre biblioteki wymagają jawnego włączenia szyfrowania, inne reagują na nieufny certyfikat komunikatem o błędzie, a jeszcze inne mogą oferować tryb pomijania weryfikacji. Ostatnia możliwość bywa przydatna wyłącznie w kontrolowanym teście, ponieważ wyłącza ważną część ochrony. Przy analizie błędu należy zebrać informację o wersji sterownika, nazwie użytej w połączeniu, czasie wystąpienia problemu oraz zmianach wykonanych przy certyfikacie.

Do typowych nieprawidłowości należą także brak uprawnienia do klucza prywatnego, wybór certyfikatu bez odpowiedniego przeznaczenia, niezgodność algorytmu z wymaganiami systemu oraz pozostawienie starego certyfikatu po zakończeniu migracji. Każdy z tych przypadków może powodować odrzucenie połączenia albo nieprzewidywalne zachowanie po ponownym uruchomieniu usługi.

Praktyczne wskazówki dla obsługi certyfikatów SSL/TLS

Prace warto rozpocząć od spisu wszystkich klientów łączących się z daną instancją. Należy uwzględnić aplikacje użytkowe, zadania automatyczne, narzędzia raportowe, połączenia administracyjne i skrypty uruchamiane bez udziału użytkownika. Dla każdego przypadku powinno się odnotować nazwę używaną w konfiguracji, sterownik, wymaganie szyfrowania oraz sposób weryfikacji certyfikatu.

Przed wdrożeniem przydatne jest przygotowanie planu odnowienia. Powinno się określić osobę lub zespół odpowiedzialny za pilnowanie terminu ważności, sposób uzyskania nowego certyfikatu, kolejność instalacji oraz procedurę wycofania starego certyfikatu. Testy należy wykonać poza głównym oknem obciążenia, a następnie sprawdzić połączenia z kilku typów klientów. Samo uruchomienie usługi bez błędu nie potwierdza poprawności, ponieważ część problemów ujawnia się dopiero przy połączeniu z innego komputera.

Dokumentacja powinna zawierać nazwę certyfikatu, jego odcisk, datę ważności, właściciela klucza prywatnego, lokalizację magazynu oraz listę aplikacji korzystających z połączenia. Odcisk należy porównywać w sposób bezpośredni, bez przepisywania go z niezweryfikowanego źródła. Po zmianie certyfikatu warto przejrzeć dzienniki systemowe i aplikacyjne, a także wykonać kontrolne połączenie z wymuszonym szyfrowaniem.

W przypadku środowisk testowych i produkcyjnych powinno się unikać kopiowania kluczy prywatnych pomiędzy komputerami. Bezpieczniejszym rozwiązaniem jest przygotowanie certyfikatu zgodnie z przeznaczeniem dla konkretnej usługi i ograniczenie dostępu do klucza do niezbędnego konta. Regularny przegląd konfiguracji pozwala wykryć certyfikaty nieużywane, przestarzałe lub przypisane do nieaktualnych nazw.

Kiedy zgłosić obsługę certyfikatów SSL/TLS do serwisu

Wsparcie serwisowe może być potrzebne, gdy po zmianie certyfikatu aplikacja przestaje łączyć się z bazą, pojawia się komunikat o braku zaufania, usługa nie uruchamia się po przypisaniu certyfikatu albo nie jest jasne, który element odpowiada za błąd. Zgłoszenie jest uzasadnione także wtedy, gdy zbliża się termin odnowienia i potrzebne jest uporządkowanie magazynów, nazw oraz uprawnień.

W ramach przygotowania do diagnostyki przydatne jest przekazanie opisu objawów, nazwy używanej przez aplikację, informacji o ostatniej zmianie oraz treści komunikatu błędu. Nie należy przesyłać klucza prywatnego ani haseł. Warszawskie Pogotowie Komputerowe 24/7 realizuje naprawy z reguły do 3 dni roboczych, dlatego można zlecić sprawdzenie konfiguracji, analizę ścieżki zaufania i test połączeń po wdrożeniu zmian.

Po zakończeniu prac powinno się potwierdzić, że połączenie jest szyfrowane, certyfikat odpowiada właściwej nazwie, klient ufa wystawcy, a klucz prywatny pozostaje dostępny wyłącznie dla wymaganej usługi. Takie sprawdzenie zamyka proces obsługi certyfikatów SSL/TLS i ogranicza ryzyko powrotu problemu przy kolejnym odnowieniu.