Napraw błąd szyfrowania SQL Server — rozwiązanie jednym kliknięciem

Przeczytaj błąd — jest to problem z zaufaniem, a nie z siecią

Twoja sieć działa prawidłowo, a serwer działa. Połączenie osiągnęło SQL Server, serwer zaoferował zaszyfrowany kanał do logowania, a Twój komputer odmówił, ponieważ certyfikat potwierdzający tożsamość serwera jest podpisany przez nikogo, komu Twój komputer nie ufa. Pełny błąd pokazywany przez SSMS to:

Domyślnie SQL Server chroni logowanie za pomocą certyfikatu z podpisem własnym, który sam tworzy. Certyfikat z podpisem własnym szyfruje ruch, ale nie może udowodnić, że serwer jest naprawdę Twoim serwerem, więc klienci żądający zweryfikowanego szyfrowania odrzucają go. Każda uczciwa poprawka to jedna z dwóch rzeczy: sprawienie, aby klient świadomie zaakceptował ten konkretny serwer (kroki 2 i 3) lub dał serwerowi certyfikat, któremu klienci ufają samodzielnie (krok 4).

Szybka poprawka klienta w SSMS - certyfikat serwera zaufania

To jest szybka trasa pokazana na filmie. Nie zmienia to niczego na serwerze; mówi temu jednemu połączeniu, aby zaakceptował certyfikat serwera bez sprawdzania, kto go podpisał. W oknie SSMS Połącz z serwerem kliknij Opcje, aby otworzyć dodatkowe zakładki, przejdź do zakładki Właściwości połączenia, ustaw szyfrowanie na Obowiązkowe (lub pozostaw je tak, jak jest oferowane), zaznacz Zaufaj certyfikatowi serwera i kliknij Połącz. Logowanie przebiega natychmiast.

Ta sama poprawka w ciągu połączenia aplikacji

Jeśli aplikacja zamiast SSMS ulegnie awarii, ten sam przełącznik znajduje się w jej parametrach połączenia. Dodaj jawnie te dwa ustawienia — Encrypt=True włącza chroniony kanał, a TrustServerCertificate=True to pisownia ciągu połączenia pola wyboru SSMS:

Server=SQL01;Database=AppDB;User Id=appuser;Password=YourPassword;Encrypt=True;TrustServerCertificate=True;

Użyj własnej nazwy serwera, bazy danych i loginu zamiast przykładowych wartości. Kompromis jest dokładnie taki sam, jak w przypadku pola wyboru w kroku 2, z jednym dodatkowym niebezpieczeństwem: wtopiony w konfigurację dostarczonej aplikacji, pominięte sprawdzenie dotyczy każdego użytkownika, niewidocznie i na stałe. Zachowaj go w konfiguracjach programistycznych i przejściowych, a w środowisku produkcyjnym traktuj go jako czas pożyczony do czasu, aż certyfikat serwera z kroku 4 będzie na swoim miejscu.

Właściwa poprawka — nadaj serwerowi prawdziwy certyfikat

Trwała naprawa odbywa się raz na serwerze, a następnie każdy klient łączy się ściśle, bez pola wyboru i bez ostrzeżenia. Najpierw uzyskaj certyfikat pełnej nazwy DNS serwera (na przykład sql01.company.local) od wewnętrznego urzędu certyfikacji lub publicznego urzędu certyfikacji, korzystając z opcji Uwierzytelnianie serwera. Zaimportuj go wraz z kluczem prywatnym do magazynu certyfikatów komputera lokalnego na komputerze z programem SQL Server. Następnie kliknij certyfikat prawym przyciskiem myszy, wybierz Wszystkie zadania → Zarządzaj kluczami prywatnymi i nadaj kontu usługi SQL Server uprawnienie Odczyt do klucza prywatnego. Otwórz Menedżer konfiguracji SQL Server, rozwiń Konfiguracja sieci SQL Server, kliknij prawym przyciskiem myszy Protokoły dla MSSQLSERVER, wybierz Właściwości i wybierz certyfikat na karcie Certyfikat. Na karcie Flagi możesz także ustawić ForceEncryption na Tak, aby każdy klient musiał szyfrować. Uruchom ponownie usługę SQL Server — zmiana nic nie da, dopóki tego nie zrobisz.

Sprawdź metodę Napraw w sposób ścisły

Logowanie, które zakończy się pomyślnie, dowodzi mniej, niż się ludziom wydaje, ponieważ niektóre kombinacje ustawień łączą się bez prawdziwej ochrony. Udowodnij obie połówki. Najpierw połącz się ponownie z klientem w ścisły sposób: połącz się, używając nazwy DNS serwera – nazwy zawartej w certyfikacie – ustaw szyfrowanie na Obowiązkowe i pozostaw opcję Zaufaj certyfikatowi serwera niezaznaczoną. Logowanie powinno zakończyć się sukcesem bez ostrzeżenia. Następnie w tej samej sesji zapytaj serwer, czy połączenie jest rzeczywiście szyfrowane, uruchamiając to zapytanie w SSMS:

SELECT session_id, encrypt_option, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID;

encrypt_option pokazujący TRUE oznacza ocenę pozytywną. FAŁSZ z działającym loginem oznacza, że ​​połączenie powiodło się po porzuceniu ochrony, a zadanie nie zostało zakończone. Ten pozytywny test jest prawdziwą metą: każdy poprawnie skonfigurowany klient, w tym przyszłe wersje SSMS, łączy się teraz z pełną walidacją i bez specjalnych ustawień.