Fix SQL Server-coderingsfout - oplossing met één klik

Lees de fout: het is een vertrouwensprobleem, geen netwerkprobleem

Uw netwerk is in orde en de server draait. De verbinding bereikte SQL Server, de server bood een gecodeerd kanaal aan voor inloggen, en uw pc weigerde dit omdat het certificaat dat de identiteit van de server bewijst, is ondertekend door niemand die uw pc vertrouwt. De volledige fout die SSMS laat zien is:

Standaard beschermt SQL Server de login met een zelfondertekend certificaat dat het zelf aanmaakt. Een zelfondertekend certificaat versleutelt het verkeer wel, maar kan niet bewijzen dat de server werkelijk uw server is. Daarom wijzen clients die geverifieerde versleuteling eisen dit af. Elke eerlijke oplossing bestaat uit twee dingen: ervoor zorgen dat de client deze specifieke server bewust accepteert (stap 2 en 3), of de server een certificaat geven dat de klant zelf vertrouwt (stap 4).

De snelle clientoplossing in SSMS - Trust Server-certificaat

Dit is de snelle route die in de video wordt weergegeven. Het verandert niets op de server; het vertelt deze ene verbinding het certificaat van de server te accepteren zonder te controleren wie het heeft ondertekend. Klik in het SSMS-venster Verbinden met server op Opties om de extra tabbladen te openen, ga naar het tabblad Verbindingseigenschappen, stel de codering in op Verplicht (of laat het zoals aangeboden), vink Vertrouwensservercertificaat aan en klik op Verbinden. De login verloopt meteen.

Dezelfde oplossing in een app-verbindingsreeks

Als een toepassing mislukt in plaats van SSMS, bevindt dezelfde switch zich in de verbindingsreeks. Voeg de twee instellingen expliciet toe: Encrypt=True schakelt het beveiligde kanaal in, en TrustServerCertificate=True is de spelling van de verbindingsreeks van het SSMS-selectievakje:

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

Gebruik uw eigen servernaam, database en login in plaats van de voorbeeldwaarden. De afweging is precies hetzelfde als bij het selectievakje in stap 2, met één extra gevaar: ingebed in de configuratie van een verzonden applicatie, is de overgeslagen controle voor elke gebruiker van toepassing, onzichtbaar en permanent. Bewaar het in ontwikkelings- en faseringsconfiguraties, en behandel het in productie als geleende tijd totdat het servercertificaat in stap 4 aanwezig is.

De juiste oplossing: geef de server een echt certificaat

De permanente reparatie gebeurt één keer, op de server, en daarna maakt elke client strikt verbinding zonder selectievakjes en zonder waarschuwing. Vraag eerst een certificaat voor de volledige DNS-naam van de server (bijvoorbeeld sql01.company.local) aan bij uw interne certificeringsinstantie of een openbare CA, met gebruik van serverauthenticatie. Importeer het, met zijn persoonlijke sleutel, in het certificaatarchief Lokale computer op de SQL Server-machine. Klik vervolgens met de rechtermuisknop op het certificaat, kies Alle taken → Privésleutels beheren en geef het SQL Server-serviceaccount de toestemming Lezen voor de privésleutel. Open SQL Server Configuration Manager, vouw SQL Server Network Configuration uit, klik met de rechtermuisknop op Protocollen voor MSSQLSERVER, kies Eigenschappen en selecteer het certificaat op het tabblad Certificaat. Op het tabblad Vlaggen kunt u ForceEncryption ook instellen op Ja, zodat elke client moet coderen. Start de SQL Server-service opnieuw. De wijziging doet niets totdat u dat doet.

Controleer de oplossing op de strikte manier

Een login die stilletjes lukt, bewijst minder dan mensen denken, omdat sommige instellingscombinaties verbinding maken zonder echte bescherming. Bewijs beide helften. Maak eerst opnieuw verbinding vanaf een client op de strikte manier: maak verbinding met de DNS-naam van de server - de naam in het certificaat - stel de codering in op Verplicht en laat Vertrouw servercertificaat uitgeschakeld. Het inloggen zou zonder waarschuwing moeten slagen. Vraag vervolgens in dezelfde sessie aan de server of de verbinding daadwerkelijk is gecodeerd door deze query uit te voeren in SSMS:

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

encrypt_option waarbij TRUE wordt weergegeven, is het voldoende cijfer. FALSE met een werkende login betekent dat de verbinding is gelukt door de beveiliging te laten vallen, en dat de klus nog niet is geklaard. Dat slagen voor de test is de echte eindstreep: elke correct geconfigureerde client, inclusief toekomstige SSMS-versies, maakt nu verbinding met volledige validatie en zonder speciale instellingen.