none
Verbindung zum SQL-Server mit TLS? RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    wir haben eine Software, welche eine Verbindung zum SQL-Server aufbaut. Der Connectionstring ist dabei denkbar einfach, Servername, Datenbankname, User + Passwort oder integrierte Sicherheit, mehr gibt's nicht.

    Nun fangen einige unserer Kunden an, TLS einzuführen und prompt gehen die Zugriffe nicht mehr. Es kommt ein "SSL Sicherheitsfehler" zurück mit einem "ungültigen Attribut für die Verbindungszeichenfolge".

    Wer muss denn hier was machen? Müssen wir unseren Connectionstring erweitern? Oder muss die IT des Kunden hier eingreifen?

    Ich bin da leider noch etwas unbeleckt in dieser Richtung.

    Gruß, Karsten.

    Mittwoch, 19. Februar 2020 11:43
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    des Rätsels Lösung ist da. Es war alles viel einfacher als gedacht. Im Programm darf man nicht mehr "SQLClient.SQLConnection" verwenden, sondern "OleDb.OLeDbConnection" und als Provider muss man "SQLNCLI11" verwenden. Der Treiber muss freilich da sein. Damit  klappt die Verbindung zum SQL-Server, auch wenn nur noch TLS 1.2 zur Verfügung steht und 1.0 sowie 1.1 abgeschalten wurden.

    Damit ist das Thema gelöst und ich bedanke mich nochmal für die Mithilfe.

    Gruß, Karsten.

    Montag, 2. März 2020 07:52
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Karsten,

    es gibt mehrere mögliche Ursachen hierfür. Siehe dazu bspw.:

      MSSQL server connection issues after disabling TLS 1.0 (invalid connection string attribute)

      Unterstützung für Microsoft SQL Server TLS 1.2

      Support for TLS v1.2 (Microsoft SQL Server)

      ...

    Letztendlich müssen alle beteiligten Stellen mit dem Protokoll umgehen können. Also sowohl Client, Server, verwendete Software [bspw. .NET, SQL Client, ...], usw.

    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
    https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport


    Mittwoch, 19. Februar 2020 11:55
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    Hallo Stefan,

    da gibt's ja einiges zu beachten, wie mir scheint. Die Basisvoraussetzungen scheinen mir alle vorhanden zu sein, SQL-Versionen passen, .NET-Version passt.

    Ich lese mich mal noch ein wenig ein.

    Gruß, Karsten.

    Mittwoch, 19. Februar 2020 12:03
    |
  • Question
    Anmelden
    0
    Anmelden

    Also ich habe mich jetzt etwas eingelesen und bin auf einige Vermutungen gestoßen es wäre schön, wenn mir einer hier was dazu sagen könnte. Leider kann ich die Vermutungen noch nicht vor Ort testen, die Kundenkommunikation ist äußerst zähe.

    • Es scheint, als müsste ich im Connectionstring die Werte "Encrypt=True" sowie "TrustServerCertificate=True" angeben.
    • Möglicherweise ist die .NET Version 4 zu niedrig, kann das sein?
    • Wir benutzen intern die "SQLConnection". Diese bietet keinen "Provider" im Connectionstring. Bei einer "OLEDBConnection" könnte ich den Provider angeben. Dort muss dann möglicherweise "SQLNCLI11" stehen.

    Was meint ihr, bin ich auf der richtigen Spur?

    Gruß, Karsten.

    Donnerstag, 20. Februar 2020 13:36
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Carsten,

    im ersten Schritt solltest/musst Du eine SQL Server Instanz mit aktivierter Verschlüsselung bereitstellen. Mit der kannst Du problemlos alle Varianten testen.

    Je nach TLS Protokoll Version kann es sein, dass die .NET Version zu niedrig ist, Ja. Muss aber nicht sein, da das u.a. auch aufs Betriebssystem ankommt, auf dem die Anwendung läuft. Eine detaillierte Übersicht findest Du bspw. hier:

      Bewährte Methoden für Transport Layer Security (TLS) mit .NET Framework

    TrustServerCertificate=True ist eigentlich gleichzusetzen mit "Is mir egal, ob das Zertifikat gültig ist oder nicht, Hauptsache, es ist eins da". Wenn man das aktiviert, kann man es eigentlich auch gleich sein lassen.

    System.Data.SqlClient kann mit TLS schon umgehen. Frage ist halt nur, welche .NET Version setzt ihr ein, welche TLS Version der Kunde, ...

    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
    https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport

    Donnerstag, 20. Februar 2020 14:24
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    Hallo Stefan,

    danke für Deine Antwort. Ein paar Sachen kann ich gleich beantworten: Unsere Software benötigt .NET 4, d.h. dies ist im Visual Studio als Ziel-Framework eingetragen. Bei den Kunden wir in aller Regel eine höhere Version vorhanden sein. Die TLS-Version 1.2 wird vom Kunde aktiviert, die Versionen 1.0 und 1.1 werden abgeschalten.

    Wie kann ich eine Instanz mit aktivierter Verschlüsselung bereitstellen? Wird das beim Hinzufügen der Instanz konfiguriert? Bisher haben wir unsere SQL-Server mit den Standardeinstellungen installiert und höchstens mal das Data-Verzeichnis angepasst, daher meine Frage. Das würde mir bei den Tests schon helfen.

    Gruß, Karsten.

    Donnerstag, 20. Februar 2020 14:31
    |
  • Question
    Anmelden
    0
    Anmelden

    Noch ein paar Hinweis. Vom Kunde, bzw. dessen IT kam nun folgender Hinweis: 

    • Das Aufbauen der Verbindung bzw. das Anmelden am Datenbanksystem nutzt TLS (immer und ist nicht ein- oder abschaltbar), damit Passwörter nicht unverschlüsselt übertragen werden
    • Es geht nicht darum die Verbindung generell zu verschlüsseln, sondern lediglich darum, einen Treiber zu verwenden, welcher auch TLS 1.2 beherrscht.
    • Der Standardtreiber, welcher bei Windows mitgeliefert wird und der auch vom Programm genutzt wird, unterstützt nur TLS 1.0 bzw.. TLS 1.1. Das ist unsicher und nicht mehr zugelassen.
    • Die Anmeldung muss zwingend TLS 1.2 nutzen, das kann der Standardtreiber nicht, es muss deshalb ein aktueller Treiber genutzt werden
    • Um einen anderen Treiber zu nutzen muss der ConnectionString angepasst werden. In dem muss das Attribut Provider=SQLNCLI11 gesetzt sein.

    Was bedeutet das nun für uns? Der Connectionstring unterstützt zum Beispiel kein Provider-Attribut, da wir ja die SQLConnection nutzen, den Provider gibts nur bei OLEDBConnection.

    Gruß, Karsten.

    Donnerstag, 20. Februar 2020 14:50
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Karsten,

    es gibt sehr viele .NET 4 Versionen. Welche genau? 4.0? 4.5? 4.7? 4.8? ...?

    Dasselbe gilt für die SQL Server Version. Welche genau (bitte exakte Buildnummer. SELECT @@VERSION) setzt ihr ein? (Für den Grund meiner Frage siehe bspw.: TLS 1.2 support for Microsoft SQL Server)

    Bzgl. Einrichtung des SQL Servers mit TLS verweise ich mal auf:

      Securing connections to SQL Server with TLS

    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
    https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport

    Donnerstag, 20. Februar 2020 14:53
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    Hallo Stefan,

    es geht um das .NET 4.0. Im Visual Studio wird es als ".NET Framework 4" bezeichnet. Es ist nicht die Version 4.5.

    Welchen SQL-Server der Kunde einsetzt, kann ich nicht genau sagen, ich denke es wird SQL-Server 2017 sein. Die sind ziemlich stark von der Außenwelt abgeschottet. Ich bin mir aber gar nicht sicher, ob wir hier noch auf der richtigen Spur sind, wegen den aktuellen Hinweisen des Kunden, siehe 2 Etagen oben drüber... Kannst du dazu noch was sagen?

    Gruß, Karsten.

    Donnerstag, 20. Februar 2020 14:59
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    des Rätsels Lösung ist da. Es war alles viel einfacher als gedacht. Im Programm darf man nicht mehr "SQLClient.SQLConnection" verwenden, sondern "OleDb.OLeDbConnection" und als Provider muss man "SQLNCLI11" verwenden. Der Treiber muss freilich da sein. Damit  klappt die Verbindung zum SQL-Server, auch wenn nur noch TLS 1.2 zur Verfügung steht und 1.0 sowie 1.1 abgeschalten wurden.

    Damit ist das Thema gelöst und ich bedanke mich nochmal für die Mithilfe.

    Gruß, Karsten.

    Montag, 2. März 2020 07:52
    |