Åtgärda SQL Server Encryption Error - One Click Solution

Läs felet - det är ett förtroendeproblem, inte ett nätverksproblem

Ditt nätverk är bra och servern är igång. Anslutningen nådde SQL Server, servern erbjöd en krypterad kanal för inloggningen och din PC vägrade det eftersom certifikatet som bevisar serverns identitet är signerat av ingen som din PC litar på. Det fullständiga felet SSMS visar är:

Som standard skyddar SQL Server inloggningen med ett självsignerat certifikat som den skapar själv. Ett självsignerat certifikat krypterar trafiken, men det kan inte bevisa att servern verkligen är din server, så klienter som kräver verifierad kryptering avvisar det. Varje ärlig fix är en av två saker: få klienten att acceptera just den här servern medvetet (steg 2 och 3), eller ge servern ett certifikat som klienterna litar på på egen hand (steg 4).

Quick Client Fix i SSMS - Trust Server Certificate

Detta är den snabba rutten som visas i videon. Det ändrar ingenting på servern; den säger åt denna anslutning att acceptera serverns certifikat utan att kontrollera vem som har signerat det. I fönstret SSMS Anslut till server klickar du på Alternativ för att öppna de extra flikarna, gå till fliken Anslutningsegenskaper, ställ in kryptering till Obligatorisk (eller lämna det som det erbjuds), markera Lita på servercertifikat och klicka på Anslut Inloggningen går igenom direkt.

Samma fix inuti en appanslutningssträng

Om en applikation misslyckas istället för SSMS, lever samma switch i sin anslutningssträng. Lägg till de två inställningarna explicit - Encrypt=True aktiverar den skyddade kanalen och TrustServerCertificate=True är anslutningssträngstavningen för SSMS-kryssrutan:

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

Använd ditt eget servernamn, databas och inloggning istället för exempelvärdena. Avvägningen är exakt densamma som kryssrutan i steg 2, med en extra fara: inbakad i en skickad applikations konfiguration gäller den överhoppade kontrollen för varje användare, osynligt och permanent. Behåll den i utvecklings- och iscensättningskonfigurationer och i produktion behandla den som lånad tid tills servercertifikatet i steg 4 är på plats.

Den korrekta åtgärden - Ge servern ett riktigt certifikat

Den permanenta reparationen sker en gång, på servern, och efteråt ansluter varje klient strikt utan kryssruta och ingen varning. Skaffa först ett certifikat för serverns fullständiga DNS-namn (till exempel sql01.company.local) från din interna certifikatutfärdare eller en offentlig CA, med Serverautentisering. Importera den, med dess privata nyckel, till Local Computer-certifikatarkivet på SQL Server-datorn. Högerklicka sedan på certifikatet, välj Alla uppgifter → Hantera privata nycklar och ge SQL Server-tjänstkontot Läs-behörighet för den privata nyckeln. Öppna SQL Server Configuration Manager, expandera SQL Server Network Configuration, högerklicka på Protocols for MSSQLSERVER, välj Egenskaper och välj certifikatet på fliken Certifikat. På fliken Flaggor kan du också ställa in ForceEncryption till Ja så att varje klient måste kryptera. Starta om SQL Server-tjänsten - ändringen gör ingenting förrän du gör det.

Verifiera Fix the Strict Way

En inloggning som lyckas i tysthet bevisar mindre än vad folk tror, eftersom vissa inställningskombinationer ansluter utan riktigt skydd. Bevisa båda halvorna. Först, återanslut från en klient på det strikta sättet: anslut med serverns DNS-namn - namnet inuti certifikatet - ställ in kryptering till Obligatoriskt och lämna Lita på servercertifikat omarkerat. Inloggningen ska lyckas utan förvarning. Fråga sedan servern i samma session om anslutningen verkligen är krypterad genom att köra den här frågan i SSMS:

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

encrypt_option som visar TRUE är godkänt betyg. FALSK med en fungerande inloggning betyder att anslutningen lyckades genom att skyddet släpptes och att jobbet inte är gjort. Det godkända testet är den riktiga mållinjen: alla korrekt konfigurerade klienter, inklusive framtida SSMS-versioner, ansluts nu med fullständig validering och inga speciella inställningar.