Behebung des SQL Server-Verschlüsselungsfehlers – One-Click-Lösung

Lesen Sie den Fehler – es handelt sich um ein Vertrauensproblem, nicht um ein Netzwerkproblem

Ihr Netzwerk ist in Ordnung und der Server läuft. Die Verbindung erreichte SQL Server, der Server bot einen verschlüsselten Kanal für die Anmeldung an und Ihr PC lehnte dies ab, da das Zertifikat, das die Identität des Servers nachweist, von niemandem signiert wurde, dem Ihr PC vertraut. Der vollständige Fehler, den SSMS anzeigt, ist:

Standardmäßig schützt SQL Server die Anmeldung mit einem selbstsignierten Zertifikat, das er selbst erstellt. Ein selbstsigniertes Zertifikat verschlüsselt zwar den Datenverkehr, kann jedoch nicht beweisen, dass es sich tatsächlich um Ihren Server handelt. Daher lehnen Clients, die eine verifizierte Verschlüsselung verlangen, dies ab. Jede ehrliche Lösung besteht aus zwei Dingen: den Client dazu zu bringen, diesen bestimmten Server wissentlich zu akzeptieren (Schritte 2 und 3), oder dem Server ein Zertifikat zu geben, dem der Client selbst vertraut (Schritt 4).

Der Quick Client Fix in SSMS – Trust Server Certificate

Dies ist die im Video gezeigte Schnellroute. Es ändert nichts am Server; Es weist diese eine Verbindung an, das Zertifikat des Servers zu akzeptieren, ohne zu prüfen, wer es signiert hat. Klicken Sie im SSMS-Fenster Mit Server verbinden auf Optionen, um die zusätzlichen Registerkarten zu öffnen, gehen Sie zur Registerkarte Verbindungseigenschaften, stellen Sie die Verschlüsselung auf Obligatorisch ein (oder belassen Sie sie wie angeboten), aktivieren Sie Serverzertifikat vertrauen und klicken Sie auf Verbinden. Der Login erfolgt sofort.

Der gleiche Fix in einer App-Verbindungszeichenfolge

Wenn eine Anwendung anstelle von SSMS ausfällt, bleibt derselbe Schalter in seiner Verbindungszeichenfolge bestehen. Fügen Sie die beiden Einstellungen explizit hinzu – Encrypt=True aktiviert den geschützten Kanal und TrustServerCertificate=True ist die Schreibweise der Verbindungszeichenfolge des SSMS-Kontrollkästchens:

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

Verwenden Sie anstelle der Beispielwerte Ihren eigenen Servernamen, Ihre eigene Datenbank und Ihr eigenes Login. Der Kompromiss ist genau derselbe wie beim Kontrollkästchen in Schritt 2, mit einer zusätzlichen Gefahr: Die übersprungene Prüfung ist in die Konfiguration einer ausgelieferten Anwendung integriert und gilt für jeden Benutzer, unsichtbar und dauerhaft. Behalten Sie es in Entwicklungs- und Staging-Konfigurationen bei und behandeln Sie es in der Produktion als geliehene Zeit, bis das Serverzertifikat in Schritt 4 vorhanden ist.

Die richtige Lösung: Geben Sie dem Server ein echtes Zertifikat

Die dauerhafte Reparatur erfolgt einmalig auf dem Server, und anschließend stellt jeder Client eine Verbindung her, ohne Kontrollkästchen und ohne Warnung. Besorgen Sie sich zunächst ein Zertifikat für den vollständigen DNS-Namen des Servers (z. B. sql01.company.local) von Ihrer internen Zertifizierungsstelle oder einer öffentlichen Zertifizierungsstelle mit Verwendung der Serverauthentifizierung. Importieren Sie es mit seinem privaten Schlüssel in den Zertifikatspeicher Lokaler Computer auf dem SQL Server-Computer. Klicken Sie dann mit der rechten Maustaste auf das Zertifikat, wählen Sie Alle Aufgaben → Private Schlüssel verwalten und erteilen Sie dem SQL Server-Dienstkonto die Berechtigung Lesen für den privaten Schlüssel. Öffnen Sie SQL Server-Konfigurationsmanager, erweitern Sie SQL Server-Netzwerkkonfiguration, klicken Sie mit der rechten Maustaste auf Protokolle für MSSQLSERVER, wählen Sie Eigenschaften und wählen Sie das Zertifikat auf der Registerkarte Zertifikat aus. Auf der Registerkarte Flags können Sie auch ForceEncryption auf Ja setzen, sodass jeder Client eine Verschlüsselung durchführen muss. Starten Sie den SQL Server-Dienst neu – die Änderung bewirkt erst, wenn Sie dies tun.

Überprüfen Sie den „Fix the Strict Way“.

Eine stillschweigend erfolgreiche Anmeldung beweist weniger, als man denkt, da einige Einstellungskombinationen ohne wirklichen Schutz verbunden sind. Beweisen Sie beide Hälften. Stellen Sie zunächst die strikte Verbindung von einem Client erneut her: Stellen Sie die Verbindung mit dem DNS-Namen des Servers her – dem Namen im Zertifikat – stellen Sie die Verschlüsselung auf „Obligatorisch“ ein und lassen Sie Serverzertifikat vertrauen deaktiviert. Die Anmeldung sollte ohne Warnung erfolgreich sein. Fragen Sie dann in derselben Sitzung den Server, ob die Verbindung tatsächlich verschlüsselt ist, indem Sie diese Abfrage in SSMS ausführen:

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

encrypt_option mit TRUE ist die bestandene Note. FALSE bei einer funktionierenden Anmeldung bedeutet, dass die Verbindung durch Aufheben des Schutzes erfolgreich hergestellt werden konnte und die Aufgabe nicht abgeschlossen ist. Dieser bestandene Test ist das eigentliche Ziel: Jeder korrekt konfigurierte Client, einschließlich zukünftiger SSMS-Versionen, stellt jetzt eine Verbindung mit vollständiger Validierung und ohne besondere Einstellungen her.