Because of security reasons, we disabled TLS 1.0 and older protocols on our windows, and enabled just TLS 1.1 and TLS 1.2 under the following registry path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols After that, the SQL service won’t start with the following error:

2015-02-13 17:35:10.12 spid13s     The server could not load the certificate it needs to initiate an SSL connection. It returned the following error: 0x80090331. Check certificates to make sure they are valid.
2015-02-13 17:35:10.12 spid13s     Error: 26014, Severity: 16, State: 1.
2015-02-13 17:35:10.12 spid13s     Unable to load user-specified certificate [Cert Hash(sha1) "9B49E2FB65EE880F7C8818A90187F572566C9213"]. The server will not accept a connection. You should verify that the certificate is correctly installed. See "Configuring Certificate for Use by SSL" in Books Online.
2015-02-13 17:35:10.12 spid13s     Error: 17182, Severity: 16, State: 1.
2015-02-13 17:35:10.12 spid13s     TDSSNIClient initialization failed with error 0x80092004, status code 0x80. Reason: Unable to initialize SSL support. Cannot find object or property. 
2015-02-13 17:35:10.12 spid13s     Error: 17182, Severity: 16, State: 1.
2015-02-13 17:35:10.12 spid13s     TDSSNIClient initialization failed with error 0x80092004, status code 0x1. Reason: Initialization failed with an infrastructure error. Check for previous errors. Cannot find object or property. 
2015-02-13 17:35:10.12 spid13s     Error: 17826, Severity: 18, State: 3.
2015-02-13 17:35:10.12 spid13s     Could not start the network library because of an internal error in the network library. To determine the cause, review the errors immediately preceding this one in the error log.
2015-02-13 17:35:10.12 spid13s     Error: 17120, Severity: 16, State: 1.
2015-02-13 17:35:10.12 spid13s     SQL Server could not spawn FRunCommunicationsManager thread. Check the SQL Server error log and the Windows event logs for information about possible related problems.

In the Event Manager, we can see following flow (with Schannel logging increased):

Info – Schannel – Creating an SSL client credential.
Info – Schannel – Creating an SSL server credential.
Error - Schannel - A fatal error occurred while creating an SSL client credential. The internal error state is 10013.

The Schannel error detailed:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <Provider Name="Schannel" Guid="{1F678132-5938-4686-9FDC-C8FF68F15C85}" /> 
    <TimeCreated SystemTime="2015-02-16T15:22:16.166776400Z" /> 
    <Correlation /> 
    <Execution ProcessID="712" ThreadID="772" /> 
    <Security UserID="S-1-5-18" /> 
    <Data Name="Type">server</Data> 
    <Data Name="ErrorState">10013</Data> 

Using WireShark, we can’t see any Client or Server Hello messages. It seems like the error occurs before the TLS negotiation - probably during parsing the server certificate.

Using ProccessMonitor, we see the sqlserver.exe service reads the certificate from registry, then reads CRLs (none), CTLs (none), and then follows the first error log message. Here are the few last logs from the ProcMon before the first log error:

12:22:09.8165314 PM sqlservr.exe    23256   RegCloseKey HKLM\SOFTWARE\Microsoft\SystemCertificates\MY\Certificates  SUCCESS 
12:22:09.8165667 PM sqlservr.exe    23256   RegQueryKey HKLM\SOFTWARE\Microsoft\SystemCertificates\MY\CRLs  SUCCESS Query: Cached, SubKeys: 0, Values: 0
12:22:09.8166280 PM sqlservr.exe    23256   RegQueryKey HKLM\SOFTWARE\Microsoft\SystemCertificates\MY\CTLs  SUCCESS Query: Cached, SubKeys: 0, Values: 0
12:31:01.0048783 PM sqlservr.exe    9928    RegCloseKey HKLM\SOFTWARE\Microsoft\SystemCertificates\MY   SUCCESS 
12:22:09.8177144 PM sqlservr.exe    23256   WriteFile   C:\Program Files\Microsoft SQL Server\MSSQL11.SQLSERVER2014\MSSQL\Log\ERRORLOG  SUCCESS Offset: 7,530, Length: 422

We have also tried setting the SQL server with certificate from Verisign (30 days trial). We have set all settings as described here

And also we followed the answer as shown here (got there via reference from here).

Unfortunately, no luck. Still the same error.

We have also tried to disable the “Force Encryption” in the SQL configuration manager and we removed the certificate from it, but still, the SQL server tries to create self-signed certificate and fails with the same error code 0x80090331.

I know that a similar question is posted here, but it is self-accepted without disabling the TLS 1.0:

One more note, with the same settings and the same certificate, when TLS 1.0 is ENABLED, then everything works fine. When the TLS 1.0 is DISABLED, then it fails. So it seems like the TLS 1.1+ does not like something in our certificate, or, that the SQL Server does not like the TLS 1.1+.

We can’t allow enabling TLS 1.0. Any help would be much appreciated.


4 Answers 4


As in the other answer: you need a recent CU for TLS1.2. See https://support.microsoft.com/en-us/kb/3052404:

  • Cumulative Update 8 for SQL Server 2014
  • Cumulative Update 1 for SQL Server 2014 SP1
  • Cumulative Update 6 for SQL Server 2012 SP2
  • Cumulative Update 7 for SQL Server 2014

After enabling only TLS 1.2 you will possibly encounter two errors:

  1. SQL Server 2014 Agent will not start. Solution: install SQL Server 2012 SNAC from one of the 2012 CUs...
  2. SQL Server Management Studio can't connect. Solution: install .net Framework v4.6.

Furthermore you have to update the SNAC/OBDC driver on all clients connecting to the SQL Server.


SQL Server supports SSL 3.0 and TLS 1.0 only, you must have at least one of them enabled or SQL Server will not be able to start. SQL Server does not support TLS 1.1, 1.2 etc, it specifically uses TLS 1.0.

Your options here are to enable SSL 3.0 and/or TLS 1.0, no other way around it I'm afraid.

Cheers Mat

  • This directly contradicts Amit Banerjee's answer - which is correct?
    – Ronnie
    Commented Nov 29, 2016 at 11:56
  • 1
    @Ronnie This answer was correct when it was written, but later builds of SQL Server did add support for TLS 1.2, so Amit's and Jens' answers are correct now.
    – Joe White
    Commented Feb 17, 2017 at 20:43

As of January 29th, Microsoft SQL Server supports TLS 1.2 for SQL Server 2008, SQL Server 2008 R2, SQL Server 2012 and SQL Server 2014 and major client drivers like Server Native Client, Microsoft ODBC Driver for SQL Server, Microsoft JDBC Driver for SQL Server and ADO.NET (SqlClient).

Blog post about the release: http://blogs.msdn.com/b/sqlreleaseservices/archive/2016/01/29/tls-1-2-support-for-sql-server-2008-2008-r2-2012-and-2014.aspx

List of builds that support TLS 1.2 along with the client and server component download locations (KB3135244): http://support.microsoft.com/kb/3135244


While it's true the SQL needs one of these enabled, there's a workaround.

  • Open gpedit.msc. In the Local Group Policy Editor, double-click Windows Settings under the Computer Configuration node, and then double-click Security Settings.
  • Under the Security Settings node, double-click Local Policies, and then click Security Options.
  • In the details pane, double-click System cryptography: Use FIPS-compliant algorithms for encryption, hashing, and signing.
  • In the System cryptography: Use FIPS-compliant algorithms for encryption, hashing, and signing dialog box, click Enabled, and then click OK to close the dialog box. Close the Local Group Policy Editor.

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