Ret SQL Server-krypteringsfejl - Løsning med ét klik

Læs fejlen - det er et tillidsproblem, ikke et netværksproblem

Dit netværk er i orden, og serveren kører. Forbindelsen nåede SQL Server, serveren tilbød en krypteret kanal til login, og din pc afviste det, fordi certifikatet, der beviser serverens identitet, er underskrevet af ingen, din pc har tillid til. Den fulde fejl SSMS viser er:

Som standard beskytter SQL Server login med et selvsigneret certifikat, det selv opretter. Et selvsigneret certifikat krypterer trafikken, men det kan ikke bevise, at serveren virkelig er din server, så klienter, der kræver verificeret kryptering, afviser det. Enhver ærlig rettelse er en af ​​to ting: Få klienten til at acceptere denne særlige server bevidst (trin 2 og 3), eller giv serveren et certifikat, klienter stoler på på egen hånd (trin 4).

Quick Client Fix i SSMS - Trust Server Certificate

Dette er den hurtige rute vist i videoen. Det ændrer intet på serveren; den fortæller denne ene forbindelse, at den skal acceptere serverens certifikat uden at kontrollere, hvem der har underskrevet det. I vinduet SSMS Opret forbindelse til server skal du klikke på Valgmuligheder for at åbne de ekstra faner, gå til fanen Forbindelsesegenskaber, indstille kryptering til Obligatorisk (eller lade det være som tilbudt), markere Tillad servercertifikat og klikke på Forbind Login går igennem med det samme.

Samme rettelse inde i en app-forbindelsesstreng

Hvis en applikation fejler i stedet for SSMS, lever den samme switch i sin forbindelsesstreng. Tilføj de to indstillinger eksplicit - Encrypt=True slår den beskyttede kanal til, og TrustServerCertificate=True er forbindelsesstrengstavningen af SSMS-afkrydsningsfeltet:

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

Brug dit eget servernavn, database og login i stedet for eksempelværdierne. Afvejningen er nøjagtig den samme som afkrydsningsfeltet i trin 2, med en ekstra fare: Indbygget i en afsendt applikations konfiguration, gælder den oversprungne kontrol for alle brugere, usynligt og permanent. Hold det i udviklings- og iscenesættelseskonfigurationer, og behandl det i produktionen som lånt tid, indtil servercertifikatet i trin 4 er på plads.

Den korrekte rettelse - Giv serveren et rigtigt certifikat

Den permanente reparation sker én gang på serveren, og bagefter forbinder hver klient strengt uden afkrydsningsfelt og uden advarsel. Få først et certifikat for serverens fulde DNS-navn (for eksempel sql01.company.local) fra din interne certifikatmyndighed eller en offentlig CA, med Servergodkendelse brug. Importer den med dens private nøgle til certifikatlageret Local Computer på SQL Server-maskinen. Højreklik derefter på certifikatet, vælg Alle opgaver → Administrer private nøgler, og giv SQL Server-tjenestekontoen Læse-tilladelse til den private nøgle. Åbn SQL Server Configuration Manager, udvid SQL Server Network Configuration, højreklik på Protocols for MSSQLSERVER, vælg Properties, og vælg certifikatet på fanen Certifikat. På fanen Flag kan du også indstille ForceEncryption til Ja, så hver klient skal kryptere. Genstart SQL Server-tjenesten - ændringen gør intet, før du gør det.

Bekræft Fix the Strict Way

Et login, der stille og roligt lykkes, beviser mindre, end folk tror, fordi nogle indstillingskombinationer forbinder uden reel beskyttelse. Bevis begge halvdele. Først skal du oprette forbindelse igen fra en klient på den strenge måde: opret forbindelse ved hjælp af serverens DNS-navn - navnet inde i certifikatet - indstil kryptering til Obligatorisk og lad Tillad servercertifikat være umarkeret. Login skulle lykkes uden advarsel. Spørg derefter serveren i den samme session, om forbindelsen rent faktisk er krypteret ved at køre denne forespørgsel i SSMS:

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

encrypt_option, der viser TRUE, er bestået karakter. FALSK med et fungerende login betyder, at forbindelsen lykkedes ved at miste beskyttelsen, og jobbet er ikke udført. Denne beståelsestest er den rigtige målstregen: enhver korrekt konfigureret klient, inklusive fremtidige SSMS-versioner, forbindes nu med fuld validering og ingen specielle indstillinger.