Šifrování a ověření certifikátu v Microsoft.Data.SqlClient

Stáhnout ADO.NET

Použijte Transport Layer Security (TLS) k šifrování provozu mezi vaší aplikací a SQL Server. Nechte validaci serverových certifikátů zapnutou pro ověření identity serveru. Šifrování bez ověření identity nechrání před útočníkem typu man-in-the-middle, který se vydává za server.

Microsoft.Data.SqlClient ve výchozím nastavení používá Encrypt=Mandatory a TrustServerCertificate=false. Encrypt=true je synonymem pro Mandatory. Pro vzdálené připojení explicitně požadujte tato nastavení a nastavte serverový certifikát, který klient může ověřit:

Server=tcp:<server>,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;

Nahraďte zástupné prvky a použijte autentizační metodu podporovanou vaším serverem a aplikačním prostředím. Pro Azure SQL nebo SQL databázi v Microsoft Fabric viz Microsoft Entra authentication.

Vyberte režim šifrování

Encrypt řídí, zda klient potřebuje šifrování. Server může také vyžadovat šifrování. Tato tabulka popisuje současné chování bez připnutí certifikátů:

Klientské prostředí Požadavek na server Ověření certifikátu Result
Encrypt=Optional nebo false Nenutí to šifrování. Žádné, bez ohledu na TrustServerCertificate. Šifrují se pouze přihlašovací pakety. Následný provoz není šifrován.
Encrypt=Optional;TrustServerCertificate=false Nutí šifrování. Důvěryhodný řetězec, validita a název serveru. Veškerý provoz je šifrován. Neplatné certifikáty selžou spojení.
Encrypt=Optional;TrustServerCertificate=true Nutí šifrování. Přeskočeno. Veškerý provoz je šifrován, ale identita serveru není ověřena.
Encrypt=Mandatory;TrustServerCertificate=false Kterékoli nastavení. Důvěryhodný řetězec, validita a název serveru. Veškerý provoz je šifrován. Neplatné certifikáty selžou spojení.
Encrypt=Mandatory;TrustServerCertificate=true Kterékoli nastavení. Přeskočeno. Veškerý provoz je šifrován, ale identita serveru není ověřena.
Encrypt=Strict Podporuje tabulkový datový tok (TDS) 8.0. Required. TrustServerCertificate Nedá se to obejít. TLS začíná před zprávami TDS. Nepodporovaný server nebo neplatný certifikát způsobí selhání připojení.

Použití Mandatory pro šifrovaná spojení na servery, které nepodporují TDS 8.0. Použijte Strict, když váš koncový bod podporuje TDS 8.0, včetně SQL Serveru 2022 (16.x) a novějších verzí. TDS 8.0 podporuje TLS 1.2 a TLS 1.3; nevyžaduje TLS 1.3. Vyjednávaná verze TLS také závisí na konfiguraci klienta, serveru a operačního systému.

Optional není řešením chyb certifikátů. Může nechat data aplikací nešifrovaná, pokud server šifrování nevyžaduje.

Konfigurace ověřitelného serverového certifikátu

Pro běžnou validaci certifikátů:

  1. Zřiďte certifikát, který splňuje požadavky na certifikát SQL Server.
  2. Do pole Subject Alternative Name (SAN) certifikátu zahrňte název, který klienti používají k připojení.
  3. Zajistěte, aby vystavující certifikační autorita a všechny požadované mezilehlé certifikáty byly důvěryhodné na každém klientském hostiteli nebo v kontejneru.
  4. Nakonfigurujte SQL Server tak, aby používal certifikát, a ponechte TrustServerCertificate=false na klientech.
  5. Naplánujte obnovení certifikátu před vypršením jeho platnosti, včetně případných změn názvů nebo vydávajících autorit.

Certifikát od veřejné nebo podnikové certifikační autority může tyto požadavky splnit. Podnikový certifikát není automaticky důvěryhodný uvnitř linuxového kontejneru ani na samostatném vývojářském počítači.

Spojit se přes alias

Pokud spojení používá alias Domain Name System (DNS), který není v certifikátu, nejprve zvažte vydání certifikátu, který alias obsahuje. Případně nastavte HostNameInCertificate na očekávaný název uvedený v certifikátu:

Server=tcp:sql-alias.contoso.com,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;HostNameInCertificate=sql-server.contoso.com;MultiSubnetFailover=true;

HostNameInCertificate mění jméno, které SqlClient očekává během validace certifikátu. Nemění síťový cíl ani neobchází kontroly řetězce důvěry a platnosti. Nechte to nenastavené, když už název serveru odpovídá certifikátu.

Připněte konkrétní serverový certifikát

ServerCertificate poskytuje lokální certifikátový soubor pro přesné srovnání s certifikátem serveru. Podporované formáty jsou Privacy-Enhanced Mail (PEM) a Distinguished Encoding Rules (DER), včetně .cer certifikátových souborů. Použijte ji s Encrypt=Mandatory nebo Encrypt=Strict, a ponechejte TrustServerCertificate=false.

Server=tcp:<server>,1433;Database=<database>;Integrated Security=true;Encrypt=Strict;TrustServerCertificate=false;ServerCertificate=C:\certificates\sql-server.cer;MultiSubnetFailover=true;

Distribuujte očekávaný certifikát důvěryhodným kanálem a chraňte soubor před nahrazením. Přesná shoda certifikátů je alternativou k běžnému ověřování řetězce a jmen, nikoli další kontrolou nad tím. Bajty certifikátu musí odpovídat; stejné jméno subjektu nebo veřejný klíč samotný nestačí. Chybějící, nečitelný, neplatný nebo nesouladný PIN soubor neprojde ověřením.

Pinning váže nasazení klienta na rotaci certifikátů. Aktualizujte PIN při změně certifikátu serveru, včetně obnovy. Nezískávejte PIN tím, že přijmete neověřený certifikát ze sítě.

SqlClient neposkytuje veřejný mechanismus zpětného volání pro vlastní ověřování certifikátu serveru TLS. AccessTokenCallback řídí získávání autentizačního tokenu, nikoli validaci TLS.

Vývojové certifikáty a řešení problémů

Použijte důvěryhodný vývojový certifikát se správným názvem serveru. Pokud dočasně použijete TrustServerCertificate=true s With Encrypt=true v izolovaném vývojovém prostředí, připojení je šifrované, ale klient neautentizuje certifikát serveru.

Upozornění

Nenasazujte TrustServerCertificate=true jako opravu chyb certifikátů v produkčním prostředí. Tím se deaktivuje ověřování identity serveru u Mandatory a nemá to žádný vliv u Strict.

Failure Zkontrolujte
Řetězci certifikátů se nevěří. Nainstalujte do klienta příslušný důvěryhodný kořenový certifikát a zprostředkující certifikáty. Ověřte si certifikát, který SQL Server skutečně předkládá.
Název certifikátu nesedí. Porovnejte Server s certifikátem SAN. Opravte název, certifikát nebo záměrné přepsání HostNameInCertificate.
Certifikát je propadlý. Obnovte certifikát serveru a zkontrolujte klientský takt.
Připnutý certifikát nesedí nebo ho nelze načíst. Zkontrolujte cestu k souboru, oprávnění, formát a nasazený certifikát. Aktualizujte PIN prostřednictvím vašeho důvěryhodného distribučního procesu.
S přísným šifrováním se nelze připojit. Potvrďte, že koncový bod podporuje TDS 8.0 a že jeho konfigurace TLS je kompatibilní s klientem.

Pro konfiguraci na straně serveru viz přehled Certifikát.

Změny chování šifrování a ověřování certifikátů

Tyto poznámky k kompatibilitě vysvětlují změny chování při aktualizaci starších aplikací. Nové aplikace by měly používat současná nastavení popsaná v tomto článku.

Uvolnění ovladačů Změnit
1.0 Encrypt=false je výchozí hodnota. Když klient nepožaduje šifrování, serverem vynucené šifrování nespustí ověření certifikátu.
2.0 Šifrování vynucené serverem respektuje TrustServerCertificate i když Encrypt=false.
4.0 Šifrování se automaticky zapne. Upgrady mohou odhalit dříve nepovšimnuté chyby v konfiguraci certifikátu.
5.0 Přidává Optional, Mandatory, Strict, a HostNameInCertificate.
5.1 Přidává ServerCertificate pro připínání certifikátů.
7.0.3 Opravuje ověřování certifikátu v řízených sítích, aby selhalo a zavřelo se kvůli chybějícím, neplatným nebo neshodným souborům, i když běžná validace platformy uspěje.

Související obsah

  • Poslední aktualizace v