Notre client a récemment mis à niveau de TLS 1.0 vers TLS 1.2 et après cela, notre logiciel ne peut pas se connecter au serveur SQL. Il utilise OLE fournisseur de base de données pour se connecter au serveur SQL. Ci-dessous est l'erreur qui est renvoyée par le serveur SQL-
[DBNETLIB] [ConnectionOpen SECDoClientHandshake ()] Erreur de sécurité SSL État SQL: 08001 Numéro d'erreur SQL: 18
Impossible de trouver des informations utiles concernant le fait que Microsoft OLE DB Provider for SQL Server supporte TLS 1.2 ou non.
L'un des liens que j'ai trouvés semble suggérer qu'il n'est pas pris en charge. https://forums.iis.net/t/1233674.aspx?connecing+SQL+server+DB+issue+after+installingTLS1+2+in+SQL+srver+with+classic+asp+application+
Par conséquent, je voulais vérifier le stackoverflow au cas où quelqu'un aurait des informations à ce sujet.
Le fournisseur SQLOLEDB et le pilote SQL Server ODBC fourni avec Windows sont des composants hérités fournis uniquement à des fins de compatibilité descendante. Ils sont obsolètes depuis SQL 2005.
Selon ce billet de blog de l'équipe MSSQL Tiger :
SQLOLEDB ne recevra pas de support pour TLS 1.2. Vous devrez basculer votre pilote sur l'un des pilotes pris en charge répertoriés dans https://support.Microsoft.com/en-us/kb/3135244
Vous devez pouvoir installer SQL Server Native Client 2012 et utiliser ce fournisseur de base de données OLE avec uniquement une modification de chaîne de connexion (changez Provider=SQLOLEDB
à Provider=SQLNCLI11
). Bien sûr, une fois devrait tester pour éviter les surprises. Par exemple, je me souviens d'une personne connaissant des différences de comportement avec le fournisseur SQL Server Native Client et ADO classique lorsque les curseurs API du serveur étaient utilisés, bien que les curseurs firehose couramment utilisés soient corrects.
[~ # ~] modifier [~ # ~]
Le nouveau pilote OLE DB, MSOLEDBSQL , a été publié. Ce nouveau pilote inclut la prise en charge des dernières normes TLS 1.2 et est rétrocompatible avec SQL Server Native Client 11 (SQLNCLI11). Voir l'annonce du blog de l'équipe Microsoft SQLNCLi .
Ce n'est peut-être pas une solution pour vous, car c'est un futur correctif que votre client ne pourra peut-être pas attendre, mais apparemment Microsoft est undeprecating le pilote OLEDB, avec une nouvelle version prenant en charge TLS 1.2 out T1 2018: https://blogs.msdn.Microsoft.com/sqlnativeclient/2017/10/06/announcing-the-new-release-of-ole-db-driver-for-sql-server/
Le nouveau Microsoft OLE DB Driver for SQL Server, ou msoledbsql, introduira également des capacités de basculement multi-sous-réseau dans cette première version à venir, et se tiendra au courant des dernières Normes TLS 1.2 .
En outre, cette première version à venir sera un package d'installation autonome qui est hors bande avec le cycle de vie de SQL Server. Cela signifie également que le pilote ne sera pas empaqueté dans la bibliothèque SNAC, ni couplé à aucun autre pilote.
Les modifications suivantes ont résolu le problème après la mise à niveau de TLS1.2 sur le cloud Azure -
Provider=SQLOLEDB
à Provider=SQLNCLI11
Cela peut ne pas répondre directement à la question, mais il est toujours lié à la connexion au serveur SQL avec une erreur TLS 1.2.
Je gère un ancien site Web ASP Classic qui a rompu avec l'erreur suivante.
Microsoft OLE DB Provider for SQL Server error '80004005'
[DBNETLIB][ConnectionOpen (SECDoClientHandshake()).]SSL Security error.
Changement de Provider
de SQLOLEDB
à SQL Server Native Client 11.0
ou toute version supérieure disponible a corrigé l'erreur.
Ainsi, changer la chaîne de connexion de
constr = "Provider=SQLOLEDB;Data Source=..."
à
constr = "Provider=SQL Server Native Client 11.0;Data Source=...."
pourrait aussi fonctionner