Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Użyj Transport Layer Security (TLS), aby szyfrować ruch między aplikacją a SQL Server. Zachowaj włączoną walidację certyfikatu serwera, aby zweryfikować tożsamość serwera. Szyfrowanie bez weryfikacji tożsamości nie chroni przed przeciwnikiem, który podszywa się pod serwer.
Microsoft. Data.SqlClient domyślnie używa Encrypt=Mandatory i TrustServerCertificate=false.
Encrypt=true jest synonimem dla elementu Mandatory. Dla połączenia zdalnego należy wyraźnie zażądać tych ustawień i zapewnić certyfikat serwera, który klient może zweryfikować:
Server=tcp:<server>,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;
Zamień tymczasowe elementy i użyj metody uwierzytelniania wspieranej przez środowisko serwera i aplikacji. W przypadku usługi Azure SQL lub bazy danych SQL w usłudze Microsoft Fabric zobacz uwierzytelnianie Microsoft Entra.
Wybierz tryb szyfrowania
Encrypt decyduje, czy klient wymaga szyfrowania. Serwer może również wymagać szyfrowania. Ta tabela opisuje obecne zachowanie bez przypinania certyfikatów:
| Ustawienia klienta | Wymaganie dotyczące serwera | Walidacja certyfikatu | Wynik |
|---|---|---|---|
Encrypt=Optional lub false |
Nie wymusza szyfrowania. | Brak, niezależnie od TrustServerCertificate. |
Szyfrowane są tylko pakiety logowania. Dalszy ruch nie jest szyfrowany. |
Encrypt=Optional;TrustServerCertificate=false |
Wymusza szyfrowanie. | Łańcuch zaufania, ważność i nazwa serwera. | Cały ruch jest szyfrowany. Nieprawidłowe certyfikaty powodują awarię połączenia. |
Encrypt=Optional;TrustServerCertificate=true |
Wymusza szyfrowanie. | Ominięto. | Cały ruch jest szyfrowany, ale tożsamość serwera nie jest weryfikowana. |
Encrypt=Mandatory;TrustServerCertificate=false |
Oba ustawienia. | Łańcuch zaufania, ważność i nazwa serwera. | Cały ruch jest szyfrowany. Nieprawidłowe certyfikaty powodują awarię połączenia. |
Encrypt=Mandatory;TrustServerCertificate=true |
Oba ustawienia. | Pominięto. | Cały ruch jest szyfrowany, ale tożsamość serwera nie jest weryfikowana. |
Encrypt=Strict |
Obsługuje Tabular Data Stream (TDS) 8.0. | Required.
TrustServerCertificate Nie da się tego obejść. |
Protokół TLS rozpoczyna się przed komunikatami TDS. Nieobsługiwany serwer lub nieprawidłowy certyfikat powoduje awarię połączenia. |
Zastosowanie Mandatory do szyfrowanych połączeń z serwerami, które nie obsługują TDS 8.0. UżywajStrict, gdy Twój punkt końcowy obsługuje TDS 8.0, w tym SQL Server 2022 (16.x) i nowsze wersje. TDS 8.0 obsługuje TLS 1.2 i TLS 1.3; nie wymaga TLS 1.3. Negocjowana wersja TLS zależy również od konfiguracji klienta, serwera i systemu operacyjnego.
Optional nie jest lekarstwem na błędy certyfikatów. Może pozostawić dane aplikacji niezaszyfrowane, gdy serwer nie wymaga szyfrowania.
Konfiguruj weryfikowalny certyfikat serwera
Dla normalnej walidacji certyfikatów:
- Zapewnij certyfikat spełniający wymagania certyfikatu SQL Server.
- Uwzględnij w alternatywnej nazwie podmiotu (SAN) certyfikatu nazwę, której klienci używają do nawiązywania połączenia.
- Spraw, by organ wydający certyfikat i wszelkie wymagane certyfikaty pośrednie były zaufane na każdym hostze lub kontenerze klienckim.
- Skonfiguruj SQL Server tak, aby korzystał z certyfikatu, a
TrustServerCertificate=falsepozostaw po stronie klientów. - Zaplanuj odnowienie certyfikatu przed jego wygaśnięciem, uwzględniając wszelkie zmiany nazw lub organów wydających.
Certyfikat od publicznego lub korporacyjnego urzędu certyfikacyjnego może spełnić te wymagania. Certyfikat korporacyjny nie jest automatycznie uznawany za zaufany w kontenerze systemu Linux ani na oddzielnym komputerze deweloperskim.
Połącz się przez pseudonim
Jeśli połączenie używa aliasu DNS (Domain Name System), który nie znajduje się w certyfikacie, najpierw rozważ wydanie certyfikatu zawierającego ten alias. Alternatywnie, ustaw HostNameInCertificate na oczekiwaną nazwę w certyfikacie:
Server=tcp:sql-alias.contoso.com,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;HostNameInCertificate=sql-server.contoso.com;MultiSubnetFailover=true;
HostNameInCertificate zmienia nazwę oczekiwaną przez SqlClient podczas walidacji certyfikatów. Nie zmienia to docelowego adresu sieciowego ani nie omija sprawdzania łańcucha zaufania i daty wygaśnięcia. Zostaw to nieustawione, gdy nazwa serwera już odpowiada certyfikatowi.
Przypnij konkretny certyfikat serwera
ServerCertificate dostarcza lokalny plik certyfikatu do dokładnego porównania z certyfikatem serwera. Obsługiwane formaty to Privacy-Enhanced Mail (PEM) oraz Distinguished Encoding Rules (DER), w tym pliki certyfikatów .cer. Użyj go z Encrypt=Mandatory lub Encrypt=Strict, i zachowaj TrustServerCertificate=false.
Server=tcp:<server>,1433;Database=<database>;Integrated Security=true;Encrypt=Strict;TrustServerCertificate=false;ServerCertificate=C:\certificates\sql-server.cer;MultiSubnetFailover=true;
Rozprowadź oczekiwany certyfikat przez zaufany kanał i chroń plik przed wymianą. Dokładne dopasowanie certyfikatu jest alternatywą dla standardowej weryfikacji łańcucha i nazwy, a nie dodatkową kontrolą wykonywaną oprócz niej. Bajty certyfikatu muszą się zgadzać; sama nazwa podmiotu lub klucz publiczny to za mało. Brakujący, nieczytelny, nieprawidłowy lub niedopasowany plik PIN nie przechodzi weryfikacji.
Pinning uzależnia wdrożenie klienta od rotacji certyfikatów. Zaktualizuj pin, gdy certyfikat serwera ulegnie zmianie, także w przypadku jego odnowienia. Nie zdobywaj PIN-u, akceptując niezweryfikowany certyfikat z sieci.
SqlClient nie udostępnia publicznego callbacka do dowolnej walidacji certyfikatu serwera TLS.
AccessTokenCallback kontroluje pozyskiwanie tokenów uwierzytelniania, a nie walidację TLS.
Certyfikaty rozwojowe i rozwiązywanie problemów
Użyj zaufanego certyfikatu deweloperskiego z poprawną nazwą serwera. Jeśli tymczasowo używasz TrustServerCertificate=true z Encrypt=true w izolowanym środowisku deweloperskim, połączenie jest szyfrowane, ale klient nie uwierzytelnia certyfikatu serwera.
Ostrzeżenie
Nie wdrażaj TrustServerCertificate=true jako rozwiązania produkcyjnego problemów z certyfikatami. Wyłącza walidację tożsamości serwera za pomocą Mandatory i nie ma wpływu na Strict.
| Failure | Sprawdź |
|---|---|
| Łańcuch certyfikatów nie jest godny zaufania. | Zainstaluj odpowiedni zaufany główny certyfikat i certyfikaty pośrednie na kliencie. Sprawdź certyfikat, który faktycznie przedstawia serwer SQL Server. |
| Nazwa certyfikatu się nie zgadza. | Porównaj Server z certyfikatem SAN. Popraw nazwę, certyfikat lub zamierzone HostNameInCertificate zastąpienie. |
| Certyfikat jest nieważny. | Odnow certyfikat serwera i sprawdź zegar klienta. |
| Przypięty certyfikat nie pasuje lub nie może zostać załadowany. | Sprawdź ścieżkę pliku, uprawnienia, format i wdrożony certyfikat. Zaktualizuj PIN poprzez zaufany proces dystrybucji. |
| Ścisłe szyfrowanie nie pozwala się połączyć. | Potwierdź, że punkt końcowy obsługuje TDS 8.0 oraz że jego konfiguracja TLS jest kompatybilna z klientem. |
Informacje o konfiguracji po stronie serwera znajdziesz w artykule Omówienie certyfikatów.
Zmiany w zachowaniu szyfrowania i weryfikacji certyfikatu
Te notatki dotyczące zgodności wyjaśniają zmiany zachowania podczas aktualizacji starszych aplikacji. Nowe aplikacje powinny korzystać z obecnych ustawień opisanych w tym artykule.
| Wydanie sterownika | Zmiana |
|---|---|
| 1.0 | Wartość domyślna to Encrypt=false. Gdy klient nie żąda szyfrowania, szyfrowanie wymuszone przez serwer nie uruchamia walidacji certyfikatu. |
| 2.0 | Szyfrowanie wymuszone przez serwer uwzględnia TrustServerCertificate nawet wtedy, gdy Encrypt=false. |
| 4.0 | Szyfrowanie staje się domyślnie włączone. Aktualizacje mogą ujawnić wcześniej niezauważone błędy konfiguracji certyfikatów. |
| 5.0 | Dodaje Optional, Mandatory, Strict, oraz HostNameInCertificate. |
| 5.1 | Dodaje ServerCertificate do przypinania certyfikatów. |
| 7.0.3 | Naprawia walidację przypięcia certyfikatu w zarządzanej sieci tak, aby kończyła się niepowodzeniem w przypadku brakujących, nieprawidłowych lub niedopasowanych plików, nawet jeśli standardowa walidacja platformy zakończy się powodzeniem. |