ssl - Issue creating a connection to SQL server 2014 with ODBC data source and TLS activated -

i trying create / modify system data source application needs connect our microsoft sql express 2014 database through odbc data source. connection used work before enabled ssl encryption flow but, have encrypted link, connection not work anymore.

here details:

• we run microsoft sql server express 2014 sp1 latest cumulative update (cu #3) (which necessary deactivate ssl 3.0 , tls 1.0 , run tls 1.1 , tls 1.2)
• the database instance named instance, configured run tcp/ip connection , fixed port.
• we enabled "force encryption" option , configured certificate through "sql server configuration manager"
• we can establish connection database either using management studio or sql command line utility
• we disabled usage of ssl/tls prior version tls 1.1 done through microsoft schannel. required update sql express 2014 sp1 latest cumulative update (cu #3)
• the odbc data source try configure (through odbc data source administrator) "system dsn" , uses "sql server" driver , target exact same server name 1 working in management studio (and server name corresponds machine fqdn reflected in certificate cn value)
• the version indicated sql server odbc driver "microsoft sql server odbc driver version 06.03.9600"
• i testing connection directly through odbc data source administrator tool.
• the first test runs run on exact same machine 1 hosting database server.

we 2 consecutive error message in microsoft sql server login:

connection failed: sqlstate : '01000' sql server error: 771 [microsoft][odbc sql server driver][tcp/ip  sockets]connectionopen(secdoclienthandshake()). connection failed: sqlstate : '08001' sql server error: 18 [microsoft][odbc sql server driver][tcp/ip sockets]ssl security error. 

i went through literature find cannot find solution.

edit 27/01/2016 16:30

following erg suggestion, tried use last ms sql server native client version (11.00.2100 on system), still not resolve issue. experience issue though (whether or not force strong encryption on client side results in same error):

running connectivity tests...  attempting connection [microsoft][sql server native client 11.0]tcp provider: existing connection forcibly closed remote host.  [microsoft][sql server native client 11.0]client unable establish connection  tests failed! 

so, got working after struggling little bit more.

first of all, appears there cu available (cu4) sql server express 2014 sp1.

i did download , install it, did not resolve problem: deactivated tls 1.0 , below version odbc did not work.

strangely, though cu3 , installation of .net 4.6 allowed me log in in management studio, when tried execute xp_readerrorlog query, failed.

what did solve issue follow malthus's answer on related stack overflow question https://dba.stackexchange.com/questions/93127/sql-server-service-won-t-start-after-disabling-tls-1-0-and-ssl-3-0 (3rd answer top).

i therefore activated local security policy on computer , managed links sql db working.

now, got iis working along own service , client working.

btw, if needs more user friendly way of activating ssl/tls version(s) , cryptographic algorithms on windows, stumbled uppon nice gui application not required use regedit it:

https://www.nartac.com/products/iiscrypto. it's free , not a nartac software employee, manager or shareholder.

i hope help!

edit feb 25, 2016

it looks latest cumulative update (cu5 available @ https://support.microsoft.com/en-us/kb/3130926) removes need activate fips option system cryptography.

i discovered since had deactivate fips enable required functionnality while still relying on tls 1.2 connection. indeed, appears activating fips option system cryptography prevents .net framework successfuly make use of system algorithms (such sha256managed).

in addition, according discussions seen around web (i.e. http://blogs.technet.com/b/secguide/archive/2014/04/07/why-we-re-not-recommending-fips-mode-anymore.aspx) not recommended activate fips (except strictly comply governmental recommendations) since breaks applications relying on non-fips validated implementations of cryptographic algorithms, which, provided in microsoft system libraries.