Kryptering och certifikatverifiering i Microsoft.Data.SqlClient

Ladda ned ADO.NET

Använd Transport Layer Security (TLS) för att kryptera trafiken mellan din applikation och SQL Server. Ha validering av servercertifikat aktiverat för att verifiera serverns identitet. Kryptering utan identitetsvalidering skyddar inte mot en motståndare i mitten som utger sig för att vara servern.

Microsoft.Data.SqlClient har som standard Encrypt=Mandatory och TrustServerCertificate=false. Encrypt=true är en synonym för Mandatory. För en fjärranslutning, begär uttryckligen dessa inställningar och tillhandahåll ett servercertifikat som klienten kan validera:

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

Byt ut platshållarna och använd en autentiseringsmetod som stöds av din server och applikationsmiljö. För Azure SQL- eller SQL-databaser i Microsoft Fabric, se Microsoft Entra-autentisering.

Välj ett krypteringsläge

Encrypt styr om klienten kräver kryptering. En server kan också kräva kryptering. Denna tabell beskriver aktuellt beteende utan certifikatpinning:

Klientinställning Serverkrav Certifikatverifiering Result
Encrypt=Optional eller false Tvingar inte kryptering. Inga, oavsett TrustServerCertificate. Endast inloggningspaket är krypterade. Efterföljande trafik är inte krypterad.
Encrypt=Optional;TrustServerCertificate=false Kräver kryptering. Förtroendekedja, giltighet och servernamn. All trafik är krypterad. Ogiltiga certifikat gör att anslutningen misslyckas.
Encrypt=Optional;TrustServerCertificate=true Kräver kryptering. Förbigången. All trafik är krypterad, men serverns identitet verifieras inte.
Encrypt=Mandatory;TrustServerCertificate=false Båda inställningarna. Förtroendekedja, giltighet och servernamn. All trafik är krypterad. Ogiltiga certifikat gör att anslutningen misslyckas.
Encrypt=Mandatory;TrustServerCertificate=true Båda inställningarna. Förbigången. All trafik är krypterad, men serverns identitet verifieras inte.
Encrypt=Strict Stöder Tabular Data Stream (TDS) 8.0. Required. TrustServerCertificate Kan inte kringgå det. TLS börjar före TDS-meddelanden. En server som inte stöds eller ett ogiltigt certifikat gör att anslutningen misslyckas.

Mandatory Använd för krypterade anslutningar till servrar som inte stödjer TDS 8.0. Använd Strict när din endpoint stödjer TDS 8.0, inklusive SQL Server 2022 (16.x) och senare versioner. TDS 8.0 stöder TLS 1.2 och TLS 1.3; det kräver inte TLS 1.3. Den förhandlade TLS-versionen beror också på klient-, server- och operativsystemkonfiguration.

Optional är inget medel för certifikatfel. Det kan lämna applikationsdata okrypterad när servern inte kräver kryptering.

Konfigurera ett verifierbart servercertifikat

För normal certifikatvalidering:

  1. Tillhandahåll ett certifikat som uppfyller SQL Server-certifikatkraven.
  2. Inkludera namnet klienterna använder för att ansluta i certifikatets ämnesalternativ (SAN).
  3. Se till att den utfärdande certifikatutfärdaren och eventuella nödvändiga intermediära certifikat är betrodda på varje klientvärd eller i varje container.
  4. Konfigurera SQL Server för att använda certifikatet, och behåll TrustServerCertificate=false i klienterna.
  5. Förnyelse av plancertifikat före utgång, inklusive eventuella ändringar av namn eller utfärdande myndigheter.

Ett certifikat från en offentlig eller företags certifikatmyndighet kan uppfylla dessa krav. Ett företagscertifikat är inte automatiskt betrodd i en Linux-container eller på en separat utvecklardator.

Koppla upp via ett alias

Om anslutningen använder ett Domain Name System (DNS)-alias som inte finns i certifikatet, överväg först att utfärda ett certifikat som inkluderar aliaset. Alternativt kan du ställa HostNameInCertificate in det förväntade namnet i certifikatet:

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

HostNameInCertificate ändrar namnet som SqlClient förväntar sig under certifikatvalideringen. Det ändrar inte nätverksdestinationen eller kringgår förtroendekedja och utgångskontroller. Låt den vara oaktiverad när servernamnet redan matchar certifikatet.

Pinna ett specifikt servercertifikat

ServerCertificate tillhandahåller en lokal certifikatfil för exakt jämförelse med serverns certifikat. Stödda format är Privacy-Enhanced Mail (PEM) och Distinguished Encoding Rules (DER), inklusive .cer certifikatfiler. Använd den med Encrypt=Mandatory eller Encrypt=Strict, och behåll TrustServerCertificate=false.

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

Distribuera det förväntade certifikatet via en betrodd kanal och skydda filen från ersättning. En exakt certifikatmatchning är ett alternativ till vanlig kedje- och namnvalidering, inte en extra kontroll ovanpå den. Certifikatbytena måste matcha; samma ämnesnamn eller publika nyckel räcker inte ensamt. En saknad, oläslig, ogiltig eller felmatchad pin-fil misslyckas med validering.

Certifikatbindning kopplar distributionen av klienten till certifikatrotation. Uppdatera PIN-koden när servercertifikatet ändras, inklusive förnyelse. Hämta inte en pin genom att acceptera ett icke-verifierat certifikat via nätverket.

SqlClient tillhandahåller inte någon offentlig återanropsfunktion för godtycklig validering av TLS-servercertifikat. AccessTokenCallback styr insamling av autentiseringstoken, inte TLS-validering.

Utvecklingscertifikat och felsökning

Använd ett betrodd utvecklingscertifikat med rätt servernamn. Om du tillfälligt använder TrustServerCertificate=true med Encrypt=true i en isolerad utvecklingsmiljö är anslutningen krypterad men klienten autentiserar inte servercertifikatet.

Försiktighet

Distribuera TrustServerCertificate=true inte som en produktionsfix för certifikatfel. Den inaktiverar validering av serveridentitet med Mandatory och har ingen effekt med Strict.

Failure Kontrollera
Certifikatkedjan är inte betrodd. Installera lämplig betrodd root och intermediater på klienten. Verifiera vilket certifikat SQL Server faktiskt presenterar.
Certifikatets namn stämmer inte överens. Jämför Server med certifikatet SAN. Rätta namnet, certifikatet eller den avsiktliga HostNameInCertificate åsidosättningen.
Intyget har gått ut. Förnya servercertifikatet och kontrollera klientklockan.
Fastnålat certifikat matchar inte eller kan inte laddas. Kontrollera filvägen, behörigheter, format och distribuerat certifikat. Uppdatera PIN-koden via din betrodda distributionsprocess.
Strikt kryptering kan inte ansluta. Bekräfta att slutpunkten stödjer TDS 8.0 och att dess TLS-konfiguration är kompatibel med klienten.

För konfiguration på serversidan, se en översikt över certifikat.

Ändringar i krypterings- och certifikatverifieringsbeteende

Dessa kompatibilitetsanteckningar förklarar beteendeförändringar vid uppgradering av äldre applikationer. Nya applikationer bör använda de nuvarande inställningarna som beskrivs i denna artikel.

Driver-släpp Förändring
1.0 Encrypt=false används som standard. När klienten inte begär kryptering utlöser servertvingad kryptering inte certifikatvalidering.
2.0 Kryptering som framtvingas av servern respekterar TrustServerCertificate även när Encrypt=false.
4.0 Kryptering aktiveras som standard. Uppgraderingar kan avslöja tidigare oupptäckta certifikatkonfigurationsfel.
5.0 Lägger till Optional, Mandatory, Strict, och HostNameInCertificate.
5.1 Lägger till ServerCertificate för certifikatspärrning.
7.0.3 Fixar validering av certifikatpinnar för hanterade nätverk så att de inte stängs för saknade, ogiltiga eller oöverensstämmande filer, även när normal plattformsvalidering lyckas.

Relaterat innehåll

  • Uppdaterades senast