Correggi l'errore di crittografia di SQL Server: soluzione con un clic

Leggi l'errore: è un problema di fiducia, non di rete

La tua rete funziona bene e il server è in esecuzione. La connessione ha raggiunto SQL Server, il server ha offerto un canale crittografato per l'accesso e il tuo PC lo ha rifiutato perché il certificato che prova l'identità del server non è firmato da nessuno di cui il tuo PC si fida. L'errore completo mostrato da SSMS è:

Per impostazione predefinita, SQL Server protegge l'accesso con un certificato autofirmato creato autonomamente. Un certificato autofirmato crittografa il traffico, ma non può dimostrare che il server sia realmente il tuo server, quindi i client che richiedono la crittografia verificata lo rifiutano. Ogni soluzione onesta è una delle due cose: fare in modo che il client accetti consapevolmente questo particolare server (passaggi 2 e 3) o fornire al server un certificato di cui i client si fidano da soli (passo 4).

La correzione rapida del client in SSMS - Certificato server trust

Questo è il percorso veloce mostrato nel video. Non cambia nulla sul server; dice a questa connessione di accettare il certificato del server senza verificare chi lo ha firmato. Nella finestra Connetti al server di SSMS, fai clic su Opzioni per aprire le schede aggiuntive, vai alla scheda Proprietà di connessione, imposta la crittografia su Obbligatoria (o lasciala come offerta), seleziona Certificato server attendibile e fai clic su Connetti. Il login avviene immediatamente.

La stessa correzione all'interno di una stringa di connessione dell'app

Se un'applicazione fallisce invece di SSMS, lo stesso switch risiede nella sua stringa di connessione. Aggiungi le due impostazioni in modo esplicito: Encrypt=True attiva il canale protetto e TrustServerCertificate=True è l'ortografia della stringa di connessione della casella di controllo SSMS:

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

Utilizza il nome del server, il database e l'accesso al posto dei valori di esempio. Il compromesso è esattamente lo stesso della casella di controllo nel passaggio 2, con un pericolo in più: inserito nella configurazione dell'applicazione fornita, il controllo saltato si applica a ogni utente, in modo invisibile e permanente. Mantienilo nelle configurazioni di sviluppo e gestione temporanea e consideralo in produzione come tempo preso in prestito finché non viene attivato il certificato del server nel passaggio 4.

La soluzione corretta: fornire al server un certificato reale

La riparazione permanente avviene una volta, sul server, e successivamente ogni client si connette rigorosamente senza caselle di controllo e senza avvisi. Per prima cosa ottieni un certificato per il nome DNS completo del server (ad esempio sql01.company.local) dalla tua autorità di certificazione interna o da una CA pubblica, con l'utilizzo dell'Autenticazione server. Importalo, con la relativa chiave privata, nell'archivio certificati del computer locale sul computer SQL Server. Quindi fai clic con il pulsante destro del mouse sul certificato, scegli Tutte le attività → Gestisci chiavi private e concedi all'account del servizio SQL Server l'autorizzazione di Lettura sulla chiave privata. Apri Gestione configurazione SQL Server, espandi Configurazione di rete SQL Server, fai clic con il pulsante destro del mouse su Protocolli per MSSQLSERVER, scegli Proprietà e seleziona il certificato nella scheda Certificato. Nella scheda Flag puoi anche impostare ForceEncryption su Sì in modo che ogni client debba crittografarsi. Riavvia il servizio SQL Server: la modifica non avrà alcun effetto finché non lo farai.

Verificare la correzione in modo rigoroso

Un accesso riuscito in silenzio dimostra meno di quanto si pensi, perché alcune combinazioni di impostazioni si connettono senza una reale protezione. Dimostra entrambe le metà. Innanzitutto, riconnettiti da un client nel modo rigoroso: connettiti utilizzando il nome DNS del server, il nome all'interno del certificato, imposta la crittografia su Obbligatorio e lascia deselezionato Certificato server attendibile. L'accesso dovrebbe riuscire senza alcun avviso. Quindi, nella stessa sessione, chiedi al server se la connessione è effettivamente crittografata eseguendo questa query in SSMS:

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

encrypt_option che mostra TRUE è il voto positivo. FALSO con un accesso funzionante significa che la connessione è riuscita eliminando la protezione e il lavoro non è stato completato. Il superamento del test è il vero traguardo: qualsiasi client configurato correttamente, comprese le future versioni di SSMS, ora si connette con una convalida completa e senza impostazioni speciali.