Crittografia e convalida dei certificati in Microsoft.Data.SqlClient

Scarica ADO.NET

Usa la Transport Layer Security (TLS) per criptare il traffico tra la tua applicazione e SQL Server. Mantieni attivata la validazione del certificato server per verificare l'identità del server. La crittografia senza validazione dell'identità non protegge contro un avversario nel mezzo che si spaccia per il server.

Microsoft.Data.SqlClient è impostato per impostazione predefinita su Encrypt=Mandatory e TrustServerCertificate=false. Encrypt=true è un sinonimo di Mandatory. Per una connessione remota, richiedi esplicitamente queste impostazioni e prevedi un certificato server che il client possa validare:

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

Sostituisci i segnaposto e utilizza un metodo di autenticazione supportato dal tuo server e dall'ambiente applicativo. Per informazioni su Azure SQL o Database SQL in Microsoft Fabric, vedere Microsoft Entra authentication.

Scegli una modalità di crittografia

Encrypt Controlla se il client necessita di crittografia. Un server può anche richiedere la crittografia. Questa tabella descrive il comportamento attuale senza il certificate pinning:

Usa Mandatory per connessioni criptate a server che non supportano TDS 8.0. Usalo Strict quando il tuo endpoint supporta TDS 8.0, inclusi SQL Server 2022 (16.x) e versioni successive. TDS 8.0 supporta TLS 1.2 e TLS 1.3; non richiede TLS 1.3. La versione negoziata TLS dipende anche dalla configurazione del client, del server e del sistema operativo.

Optional Non è una soluzione per gli errori dei certificati. Può lasciare i dati dell'applicazione non criptati quando il server non richiede crittografia.

Configura un certificato server verificabile

Per la normale validazione dei certificati:

1. Fornire un certificato che soddisfi i requisiti del certificato SQL Server.
2. Includi il nome che i clienti usano per connettersi nel nome alternativo (SAN) del certificato.
3. Assicurati che l'autorità di certificazione emittente e tutti i certificati intermedi necessari siano considerati attendibili su ogni host o container client.
4. Configura SQL Server in modo che utilizzi il certificato e mantieni TrustServerCertificate=false nei client.
5. Rinnovo del certificato di piano prima della scadenza, inclusi eventuali cambiamenti ai nomi o alle autorità emittenti.

Un certificato di un'autorità di certificazione pubblica o aziendale può soddisfare questi requisiti. Un certificato enterprise non è automaticamente affidabile all'interno di un container Linux o su un computer sviluppatore separato.

Connettiti tramite un alias

Se la connessione utilizza un alias Domain Name System (DNS) che non è presente nel certificato, considera prima di emettere un certificato che includa l'alias. In alternativa, imposta HostNameInCertificate il nome atteso nel certificato:

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

HostNameInCertificate cambia il nome che SqlClient si aspetta durante la validazione del certificato. Non cambia la destinazione della rete né bypassa i controlli di trust chain e di scadenza. Lascialo non impostato quando il nome del server corrisponde già al certificato.

Blocca un certificato del server specifico

ServerCertificate fornisce un file di certificato locale per un confronto esatto con il certificato del server. I formati supportati sono Privacy-Enhanced Mail (PEM) e Distinguished Encoding Rules (DER), inclusi .cer i file di certificati. Usalo con Encrypt=Mandatory o Encrypt=Strict, e tieni TrustServerCertificate=false.

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

Distribuire il certificato atteso attraverso un canale affidabile e proteggere il file dalla sostituzione. Una corrispondenza esatta di un certificato è un'alternativa alla normale convalida della catena e del nome, non un controllo aggiuntivo in aggiunta a essa. I byte del certificato devono corrispondere; lo stesso nome di soggetto o chiave pubblica da solo non basta. Un file PIN mancante, illeggibile, invalido o non corrispondente non viene validato.

Il pinning vincola la distribuzione dei client alla rotazione dei certificati. Aggiorna il PIN quando il certificato del server cambia, incluso il rinnovo. Non ottenere un PIN accettando un certificato non verificato dalla rete.

SqlClient non espone un callback pubblico per una validazione arbitraria del certificato server TLS. AccessTokenCallback controlla l'acquisizione del token di autenticazione, non la validazione TLS.

Certificati di sviluppo e risoluzione dei problemi

Usa un certificato di sviluppo affidabile con il nome del server corretto. Se usi TrustServerCertificate=true temporaneamente con Encrypt=true in un ambiente di sviluppo isolato, la connessione viene crittografata ma il client non autentica il certificato server.

Per la configurazione lato server, vedi Panoramica del certificato.

Modifiche al comportamento della crittografia e della convalida dei certificati

Queste note di compatibilità spiegano i cambiamenti comportamentali durante l'aggiornamento di applicazioni più vecchie. Le nuove applicazioni dovrebbero utilizzare le impostazioni attuali descritte in questo articolo.

Contenuti correlati

• Stringhe di connessione in ADO.NET
• Sintassi della stringa di connessione
• Procedure consigliate per la sicurezza