ODBC Treiber SQL SERVER wirft SSL Security error
Hi, eine spezielle Frage zum ODBC Trieber "SQL SERVER".
Ich hab die spannende Aufgabe erhalten, eine Altversion einer Software gegen eine aktuelle zu vergleichen.
Diese baut eine ODBC Verbindung auf, meldet sich am SQL Server an und lädt dafür den Treiber, der in der ODBC Verbindung (odbcad32 32 bit) angegeben wurden. Das ist "SQL SERVER" bzw c:\windows\system32\sqlsvr32.dll
Auf Windows 10 z.B. funktioniert das bestens, beide Versionen verbinden sich, alles gut.
Und dann... Kunde ist unzugrieden beim Umstieg auf eine neuere Hard/Softwareplatform "früher war alles besser und schneller". Früher bzw bis heute hat der Kunde Windows Server 2008R2
Und das haben wir auch installiert, aber durften den Server nicht in die Domäne einbinden.
Die kleineren Problemchen, daß MSI Dateien von heute sichd da nicht mehr installieren lassen wollten, hab ich mit einem VB Skript aus der Welt geschafft.
Wenn ich die Verbindung mit dem gleichen Treiber herstelle, dann gibt es in Windows einen "SSL Security Error"
Der aber mit dem gleichen Treiber auf Windows 10 bzw Server 2019 nicht auftritt.
Auf dem Zielsystem ist laut unserer IT TLS 1.2 aktiviert, auf dem Windows Server 2008R2 System sind die dafür nötigen optinalen Updats aktiv, die Registry-Einträge hab ich mit dem IISCrypto gleichgezogen, da sie in 2008R2 fehlen (SCHANNEL\Protocols)
Ich hab sogar die mssqlsrv.dll von Windows 10 auf den 2008R2 Server kopiert und als sqlsrv32new.dll angegeben, aber keine Chance, auch mit dem gehts nicht.
Zu anderen Treibern, die man installieren könnte ist die Applikation nicht kompatibel, andererseits muß es was mit Zertifikaten zu tun haben, da z.B. der MS ODBC Driver 18 / 17 eine Option "Serverzertifikat vertrauen" anbieten, und wenn ich die aktiviere, dann klappt der Verbindungstest in der ODBC Konfiguration, aber mit dem Hinweis, daß das Zertifikat nicht von einer "Trusted Root Certification Authority stammt." Die gibts übrigens, ich hab auch die .cer Dateien von einem System importiert, das in der Domäne eingebunden war.
Der ODBC Driver hat z.b. die Option "Strong encryption" = 1 und "Trust Server Certificate"=0 wenn man erstmalig eine Verbindung herstellt und dann kriegt man
In dem Dialog nach der Datenbankauswahl kann man das abstellen, Microsoft halt. Nur wie gesagt ist die Software in ihrer Altform dazu nicht kompatibel, aber man erhält einen Hinweis, warum es immer noch nicht geht. Nicht alle Hinweise, das wäre ja zu einfach, Microsoft halt.
Allerdings bin ich nicht so der Zertifikatsprofi, aber habe den Verdacht daß es genau daran auch beim Treiber "SQL SERVER" liegt.
Ich hab die Zertifikatsspeicher zwischen dem Server 20008R2 und Windows 10 verglichen aber keine Unterscheide gefunden, trusted root CA, intermediate CA, alles gleich.
Wie diagnostiziert man das weiter?
Ich hab die spannende Aufgabe erhalten, eine Altversion einer Software gegen eine aktuelle zu vergleichen.
Diese baut eine ODBC Verbindung auf, meldet sich am SQL Server an und lädt dafür den Treiber, der in der ODBC Verbindung (odbcad32 32 bit) angegeben wurden. Das ist "SQL SERVER" bzw c:\windows\system32\sqlsvr32.dll
Auf Windows 10 z.B. funktioniert das bestens, beide Versionen verbinden sich, alles gut.
Und dann... Kunde ist unzugrieden beim Umstieg auf eine neuere Hard/Softwareplatform "früher war alles besser und schneller". Früher bzw bis heute hat der Kunde Windows Server 2008R2
Und das haben wir auch installiert, aber durften den Server nicht in die Domäne einbinden.
Die kleineren Problemchen, daß MSI Dateien von heute sichd da nicht mehr installieren lassen wollten, hab ich mit einem VB Skript aus der Welt geschafft.
Wenn ich die Verbindung mit dem gleichen Treiber herstelle, dann gibt es in Windows einen "SSL Security Error"
Der aber mit dem gleichen Treiber auf Windows 10 bzw Server 2019 nicht auftritt.
Auf dem Zielsystem ist laut unserer IT TLS 1.2 aktiviert, auf dem Windows Server 2008R2 System sind die dafür nötigen optinalen Updats aktiv, die Registry-Einträge hab ich mit dem IISCrypto gleichgezogen, da sie in 2008R2 fehlen (SCHANNEL\Protocols)
Ich hab sogar die mssqlsrv.dll von Windows 10 auf den 2008R2 Server kopiert und als sqlsrv32new.dll angegeben, aber keine Chance, auch mit dem gehts nicht.
Zu anderen Treibern, die man installieren könnte ist die Applikation nicht kompatibel, andererseits muß es was mit Zertifikaten zu tun haben, da z.B. der MS ODBC Driver 18 / 17 eine Option "Serverzertifikat vertrauen" anbieten, und wenn ich die aktiviere, dann klappt der Verbindungstest in der ODBC Konfiguration, aber mit dem Hinweis, daß das Zertifikat nicht von einer "Trusted Root Certification Authority stammt." Die gibts übrigens, ich hab auch die .cer Dateien von einem System importiert, das in der Domäne eingebunden war.
Der ODBC Driver hat z.b. die Option "Strong encryption" = 1 und "Trust Server Certificate"=0 wenn man erstmalig eine Verbindung herstellt und dann kriegt man
In dem Dialog nach der Datenbankauswahl kann man das abstellen, Microsoft halt. Nur wie gesagt ist die Software in ihrer Altform dazu nicht kompatibel, aber man erhält einen Hinweis, warum es immer noch nicht geht. Nicht alle Hinweise, das wäre ja zu einfach, Microsoft halt.
Allerdings bin ich nicht so der Zertifikatsprofi, aber habe den Verdacht daß es genau daran auch beim Treiber "SQL SERVER" liegt.
Ich hab die Zertifikatsspeicher zwischen dem Server 20008R2 und Windows 10 verglichen aber keine Unterscheide gefunden, trusted root CA, intermediate CA, alles gleich.
Wie diagnostiziert man das weiter?
Please also mark the comments that contributed to the solution of the article
Content-ID: 83967903747
Url: https://administrator.de/contentid/83967903747
Printed on: October 4, 2024 at 01:10 o'clock
2 Comments
Latest comment
Hey,
das Thema kommt mir bekannt vor, bin im Zuge von IT-Security-Projekten auch schon öfters darüber gestolpert.
Deine Spur mit dem Treiber ist auf jeden Fall mal goldrichtig.
Grundsätzliches Problem:
Der Treiber sqlsrv32.dll stammt noch aus SQL 2000/2005 und wird eigentlich schon lange nicht mehr weiterentwickelt, aber noch von vielen Anwendungen verwendet.
Der kann daher eigentlich auch kein TLS 1.2 (egal, was im OS aktiv ist) - das dürfte dein Problem sein.
Allerdings wurde der TLS 1.2-Support für diesen Treiber mal von Microsoft nachgerüstet - aber nur für Win10/11 + Server 2019 aufwärts, nicht für ältere Betriebssysteme (u.a. zu meinem Leidwesen, da ich noch viel mit Server 2016 zu tun habe...).
Ich habe daher nach Möglichkeit alle Anwendungen auf den ODBC Driver 17 / 18 umgestellt, damit läuft das Konstrukt dann.
Zu deinen Fehlermeldungen mit dem ODBC Driver 18: Ist denn sichergestellt, dass der SQL Server auch ein "ordentliches" Zertifikat hat? Evtl. arbeitet der mit einem self-signed Zertifikat.
Es ist zudem so, dass erst der ODBC Driver 18 im Default "strengere" Zertifikatsprüfungen aktiv hat - der ODBC Driver 17 hat das noch nicht. Evtl. liefen deine Tests auf dem Win10 mit einem ODBC Driver 17 und waren daher erfolgreich?
Das ist mir jetzt mal dazu eingefallen, vielleicht hilft es...
Viele Grüße
mxrecord
das Thema kommt mir bekannt vor, bin im Zuge von IT-Security-Projekten auch schon öfters darüber gestolpert.
Deine Spur mit dem Treiber ist auf jeden Fall mal goldrichtig.
Grundsätzliches Problem:
Der Treiber sqlsrv32.dll stammt noch aus SQL 2000/2005 und wird eigentlich schon lange nicht mehr weiterentwickelt, aber noch von vielen Anwendungen verwendet.
Der kann daher eigentlich auch kein TLS 1.2 (egal, was im OS aktiv ist) - das dürfte dein Problem sein.
Allerdings wurde der TLS 1.2-Support für diesen Treiber mal von Microsoft nachgerüstet - aber nur für Win10/11 + Server 2019 aufwärts, nicht für ältere Betriebssysteme (u.a. zu meinem Leidwesen, da ich noch viel mit Server 2016 zu tun habe...).
Ich habe daher nach Möglichkeit alle Anwendungen auf den ODBC Driver 17 / 18 umgestellt, damit läuft das Konstrukt dann.
Zu deinen Fehlermeldungen mit dem ODBC Driver 18: Ist denn sichergestellt, dass der SQL Server auch ein "ordentliches" Zertifikat hat? Evtl. arbeitet der mit einem self-signed Zertifikat.
Es ist zudem so, dass erst der ODBC Driver 18 im Default "strengere" Zertifikatsprüfungen aktiv hat - der ODBC Driver 17 hat das noch nicht. Evtl. liefen deine Tests auf dem Win10 mit einem ODBC Driver 17 und waren daher erfolgreich?
Das ist mir jetzt mal dazu eingefallen, vielleicht hilft es...
Viele Grüße
mxrecord