1

I'm provisioning a new server as part of which we have disabled TLS 1.0 and installed SQL Server Express 2016. I've then attempted to install a 3rd party application that is going to install a website and supporting DB etc. The first thing it does is test the connection to SQL and it returns the following error:

Connection Problem: [DBNETLIB][ConnectionOpen (SECDoClientHandshake()).]SSL Security error

To attempt to work out the issue I created a UDL file on my desktop and reproduced this error when using the Provider Microsoft OLE DB Provider for SQL Server. The test worked fine for provider SQL Server Native Client 11.0 and I can also connect with SSMS.

Is there anyway I can force the 3rd party installer to use a different provider? Is there anyway I can log what type of connection it is attempting?

Improve this question
0

1 Answer 1

Reset to default
3

See Does Microsoft OLE DB Provider for SQL Server support TLS 1.2 and the authoritative answer from Dan Guzman. He references a newer version of OLEDB that supports TLS 1.2, which can be downloaded at Microsoft® OLE DB Driver 18 for SQL Server®

And to specifically answer your questions, there is no way for us to know if the installer can be forced to use a different provider. It's certainly possible if it uses a connection string template that can be modified, but based on my experience I would say it's highly unlikely you'll be able to modify the installer to use a different provider.

As for logging what type of connection--see if the SQL Server error log contains any information when the failure occurs. You can also set up an extended event in SQL Server to capture information about logins (there is "Connection Tracking" template). The client_app_name field collected by "Connection Tracking" template will include the information that the client passes about the provider. This can sometimes be blank, though, as it depends on the client to set that information. Typically a provider will have that information included automatically unless the developer does something to override it.

Improve this answer
4
  • That update uses a new provider name (MSOLEDBSQL) so I wouldn't have thought old connection strings would pick it up.
    – Paul
    Commented Jan 24, 2019 at 14:29
  • In the UDL test it shows as a separate provider. (Microsoft OLD DB Driver for SQL Server vs Microsoft OLD DB Provider for SQL Server). This would be a suitable answer for someone working on their own project, but doesn't help when working with someone elses software.
    – Paul
    Commented Jan 24, 2019 at 15:27
  • @Paul Yes, I see that now--looks like you're running into Old Software vs. Today's Security Requirements. If the website will install even though the DB connection fails, you might be able to modify the connection string after the install is complete. Otherwise your client is going to have to get the latest version of the web app (assuming it uses newer SQL drivers), enable TLS 1.0 on the server, or use a different SQL Server. Or, if the connection string can be modified after install, enable TLS 1.0 for the install, change the connection string, then disable TLS 1.0...
    – Tony Hinkle
    Commented Jan 24, 2019 at 15:40
  • Aye, I'm entirely aware this may be one without a "good" outcome :)
    – Paul
    Commented Jan 24, 2019 at 15:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.