2
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?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 83967903747
Url: https://administrator.de/contentid/83967903747
Ausgedruckt am: 21.11.2024 um 15:11 Uhr
2 Kommentare
Neuester Kommentar
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
die neuren Treiber legen eine Option nach draußen "use strong encryption", z.B. beim Nativeclient 11. Die aber keine starke Verschlüsselung einfordert, sondern eine strenge Zertifikatsprüfung. Im ODBC Driver 17 und 18 kann man z.B. die Option "accept server certificate" aktivieren, um das zu überspringen... scheinbar muß ich mal den SQL Treiber wiresharken, denn was mir selber aufgefallen ist ist daß auf aktuellen OS wie Server 2019 und Windows 10 die Versionsnummer vom "SQL SERVER" Treiber erhöht wird, wenn man den ODBC Driver 17 oder 18 installiert. In den neueren Treibern kriege ich dann einen Connect mit "accept server certificate" hin, und die neuren Versionen der Software können den Native Client sowie die ODBC Driver ab 17 für eine Authentifizierung per TCP-IP nutzen. Beim Native Client 11 wird scheinbar die leere Checkbox "use strong encryption" als "accept server certificate without certificate test" interpretiert.
ich vermute mal ganz stark, daß Microsoft außen herum in der Windows API was herumgeschraubt hat, z.B. hat der Native Client 11 in seiner RTM Version noch TLS 1.2 unterstützt, bis mal so ein toxisches Update für Windows um 2018 oder 2019 herauskam und der Patchlevel 5058 daraufhin einen Parameter der Verschlüsselung nicht mehr aushandeln konnte (vermutlich Hash Algorithmen) und das wurde erst besser als von dem eine Verion 7001 rauskam.
Laut Procmon z.B. kommt über den treiber "SQL SERVER" eine Kommunikation zustande, es werden ca. 10 oder 12 IP Pakete zwischen dem Client bzw odbcad32.exe und dem SQL Server ausgetauscht und erst dann die Kommunikation mti einem SSL security error abgebrochen. Innerhalb der Test-Domäne funktioniert das dann auf aktuellen OS auch mit dem "SQL SERVER", von domänenfremden Rechnern aus - auch mit aktuellem OS - nicht.
ich vermute mal ganz stark, daß Microsoft außen herum in der Windows API was herumgeschraubt hat, z.B. hat der Native Client 11 in seiner RTM Version noch TLS 1.2 unterstützt, bis mal so ein toxisches Update für Windows um 2018 oder 2019 herauskam und der Patchlevel 5058 daraufhin einen Parameter der Verschlüsselung nicht mehr aushandeln konnte (vermutlich Hash Algorithmen) und das wurde erst besser als von dem eine Verion 7001 rauskam.
Laut Procmon z.B. kommt über den treiber "SQL SERVER" eine Kommunikation zustande, es werden ca. 10 oder 12 IP Pakete zwischen dem Client bzw odbcad32.exe und dem SQL Server ausgetauscht und erst dann die Kommunikation mti einem SSL security error abgebrochen. Innerhalb der Test-Domäne funktioniert das dann auf aktuellen OS auch mit dem "SQL SERVER", von domänenfremden Rechnern aus - auch mit aktuellem OS - nicht.
