none
Sql server service wont start after disabling TLS 1.0 and SSL 3.0 on windows RRS feed

  • Question

  • We have been hardening our servers for some time now and recently we disabled SSL 3.0 because of the poodle attack. When I did this on one of our test servers SQL Server failed to start up after the restart.

    I have been able to reproduce this on Windows Server 2012 and Windows 7 by disabling TLS 1.0 and SSL 3.0 through the registry. I am using SQL Server 2012 on the server machine. On my windows 7 machine sql server 2012 and sql server 2005 will not start with those disabled.

    These are the event log errors I get: 

    Application Logs: 
    (28/10/2014 8:38:54 AM) SQL Server could not spawn FRunCM thread. Check the SQL Server error log and the Windows event logs for information about possible related problems. 
    (28/10/2014 8:38:54 AM) 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. 
    (28/10/2014 8:38:54 AM) TDSSNIClient initialization failed with error 0x80090331, status code 0x1. 
    (28/10/2014 8:38:54 AM) TDSSNIClient initialization failed with error 0x80090331, status code 0x80. 

    System Logs: 
    (28/10/2014 8:38:54 AM) The SQL Server (MSSQLSERVER) service terminated with service-specific error %%-2146893007. 
    (28/10/2014 8:38:54 AM) A fatal error occurred while creating an SSL server credential. The internal error state is 10013. 

    Done anyone know have we can keep SSL 3.0 and TLS 1.0 disabled and get SQLServer server to start?

    Tuesday, October 28, 2014 10:18 PM

Answers

  • Hi Everyone.

    First of all I just wanted to say thanks for the help.

    The issue still remains if TLS 1.0 and SSL 3.0 are disabled.  At the moment I don't see any way around this and maybe Microsoft needs to look into this for the future as TLS 1.0 is likely to be phased out over time.

    The reason I had TLS 1.0 disabled was to mitigate the BEAST attack, as I found in some reading last night this was the wrong way to do this.  To properly disable the BEAST attack on a server one should elevate a specific RC4 cipher so it is the one used with TLS 1.0.  Unfortunately this raised another about the fact that the RC4 cipher is also vulnerable but that is another discussion.

    I realize that I have not found an answer to the question. But my issue has been solve by keeping TLS 1.0 enabled in the registry. 

    Thanks Nic.

    Thursday, October 30, 2014 5:22 PM
  • Hello everyone, sorry for reviving this thread, but I hope it'll be useful, at least for people having this issue in the future. I have found this article (https://technet.microsoft.com/en-us/library/cc784450(v=ws.10).aspx) that explains a little about TLS and SQL Server:

    Common TLS/SSL Scenarios

     

    Many people think of TLS and SSL as protocols that are used with Web browsers to browse the Internet more securely. However, they are also general purpose protocols that can be used whenever authentication and data protection are necessary. For example, you can use TLS/SSL for:

     

    •              SSL-secured transactions with an e-commerce Web site
    •              Authenticated client access to an SSL-secured Web site
    •              Remote access
    •              SQL access
    •              E-mail

     

    SQL access

    With Microsoft SQL Server, you can require authentication of the client when connecting to the server running SQL Server. Either the client or server can be configured to require encryption of the data that is transferred between them. Very sensitive information, such as financial or medical databases, can be protected to prevent unauthorized access and disclosure of information about the network.

    This is why TLS must remain enabled.

    Thanks,

    Sebastian


    Tuesday, July 28, 2015 7:07 PM

All replies

  • Hello,

     Do you have any certificates loaded on SQL Server? Below registry location gives information if certificates are loaded or not:

    HKLM\software\Microsoft\Microsoft SQL Server\<InstanceID>\MSSQLServer\SuperSocketNetLib\Certificate.

    Regards,

    Don


    Regards, Don Rohan [MSFT]

    Wednesday, October 29, 2014 2:12 PM
  • Hi Don

    I just checked both Windows server 2012 and Windows 7 and neither of them have any certificates specified.  

    A bit more info:

    One more thing I tried was to enable TLS 1.1 and TLS 1.2 but that didn't seem to make a difference.  Also if I re-enable SSL 3.0 , SQLServer is able to start again.

    Thank Nic.

    Wednesday, October 29, 2014 3:07 PM
  • Hello Nic,

    SQL can use SSL to encrypt data that is transmitted across a network between an instance of SQL Server and a client application.

    Can you please check in SQL Server configuration manager, force encryption option is enabled?

    Also, you can use the below query to check if the incoming connections are encrypted or not:

    select

    session_id,encrypt_option  fromsys.dm_exec_connections

    Reference:

    http://support2.microsoft.com/kb/316898/en-us

    http://technet.microsoft.com/en-us/library/ms191192(v=sql.105).aspx

    http://technet.microsoft.com/en-us/library/ms189067(v=SQL.105).aspx


    Regards, Don Rohan [MSFT]

    Wednesday, October 29, 2014 3:15 PM
  • Hi Don

    I checked both Windows Server 2012 and Windows 7 and they both have Force Encryption set to No for "Network Configuration/Protocols for SQL2012"

    Thanks for the query: I ran it on both machines and they both produced a list of session id's and all of them were set to False.

    I appreciate the help with this, Nic.

    Wednesday, October 29, 2014 3:46 PM
  • Hello Nic,

    Please try this if it helps:

    From registry:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
    1.0\Server 

    Under this hive, you will notice a DWORD key which  is enabled. ("Enabled"=dword:00000001)

    As a best practice, please do  take a backup of the registry key before you make any changes to any registry
    entry.

    You can either delete this DWORD key  from the hive or disable it by changing the value to FFFFFFFF.
    This will  need a reboot of the server to take affect.

    If this doesn't fix the issue, revert the changes.


    Regards, Don Rohan [MSFT]

    Wednesday, October 29, 2014 3:56 PM
  • Hello Nic,

    Else, please try this:

    Post backing up registry, rename :

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
    to
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNELold


    Regards, Don Rohan [MSFT]

    Wednesday, October 29, 2014 4:00 PM
  • Hi Don,

    I already have TLS 1.0 Disabled to prevent the BEAST exploit. So the values I have for:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 
    1.0\Server

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 
    1.0\Client

    Both have enabled set to ("Enabled"=dword:00000000).

    If change both of these back to ("Enabled"=dword:00000001) to enable TLS 1.0, and restart then SQLServer is able to start again. But we are now vulnerable to the BEAST attack once again.

    If I keep server enabled and disable the client or vice versa and restart. Then SQLServer starts but I am unable to connect to it. When I check the Event logs I get the same errors as my original past.

    With your last post, do you mean to backup SCHANNEL and delete it so it gets recreated? If that is the case it will probably work because if I re enable SSL 3.0 or TLS 1.0 from here it fix's the issue,  but I then I won't have the exploits patched and we need this for some of our customers.

    This is my SCHANNEL Export:

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
    "DisabledByDefault"=dword:00000001

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0]

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]
    "DisabledByDefault"=dword:00000001

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
    "Enabled"=dword:00000000

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
    "Enabled"=dword:00000000

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
    "Enabled"=dword:00000000







    • Edited by nmullens Wednesday, October 29, 2014 6:16 PM
    Wednesday, October 29, 2014 6:04 PM
  • Hi nmullens,

    Based on my research, the TDSSNIClient initialization error can be caused by that incorrect protocol settings in SQL Server Configuration Manager (SSCM). As is suggested in this blog, please check the properties of the shared memory, named pipe, TCP and VIA in SSCM, and make sure that they are configured properly.

    However, if you still fail to start SQL Server service, then as a workaround to the issue, you may need to format and reinstall the operating system. For more details, please review the following feedback to Microsoft.
    https://connect.microsoft.com/SQLServer/feedback/details/695653/sql-server-fail-with-the-server-could-not-load-the-certificate-it-needs-to-initiate-an-ssl-connection


    Thanks,
    Lydia Zhang

    Thursday, October 30, 2014 6:56 AM
    Moderator
  • The issue appears to be still open. Regardless of having or not having a certificate selected, SQL server won't start if TLS 1.0 is disabled.

    It appears that it is not even trying to use anything higher.

    • Proposed as answer by jfnugent Thursday, August 16, 2018 10:04 PM
    Thursday, October 30, 2014 1:24 PM
  • Hi Everyone.

    First of all I just wanted to say thanks for the help.

    The issue still remains if TLS 1.0 and SSL 3.0 are disabled.  At the moment I don't see any way around this and maybe Microsoft needs to look into this for the future as TLS 1.0 is likely to be phased out over time.

    The reason I had TLS 1.0 disabled was to mitigate the BEAST attack, as I found in some reading last night this was the wrong way to do this.  To properly disable the BEAST attack on a server one should elevate a specific RC4 cipher so it is the one used with TLS 1.0.  Unfortunately this raised another about the fact that the RC4 cipher is also vulnerable but that is another discussion.

    I realize that I have not found an answer to the question. But my issue has been solve by keeping TLS 1.0 enabled in the registry. 

    Thanks Nic.

    Thursday, October 30, 2014 5:22 PM
  • Hello everyone, sorry for reviving this thread, but I hope it'll be useful, at least for people having this issue in the future. I have found this article (https://technet.microsoft.com/en-us/library/cc784450(v=ws.10).aspx) that explains a little about TLS and SQL Server:

    Common TLS/SSL Scenarios

     

    Many people think of TLS and SSL as protocols that are used with Web browsers to browse the Internet more securely. However, they are also general purpose protocols that can be used whenever authentication and data protection are necessary. For example, you can use TLS/SSL for:

     

    •              SSL-secured transactions with an e-commerce Web site
    •              Authenticated client access to an SSL-secured Web site
    •              Remote access
    •              SQL access
    •              E-mail

     

    SQL access

    With Microsoft SQL Server, you can require authentication of the client when connecting to the server running SQL Server. Either the client or server can be configured to require encryption of the data that is transferred between them. Very sensitive information, such as financial or medical databases, can be protected to prevent unauthorized access and disclosure of information about the network.

    This is why TLS must remain enabled.

    Thanks,

    Sebastian


    Tuesday, July 28, 2015 7:07 PM
  • Hi,

    This issue is currently fixed in SQL Server 2012 and SQL Server 2014. The fix is to enable TLS 1.2 and install the below fix. Please refer the below KB,

    https://support.microsoft.com/en-us/kb/3052404 

    For SQL Server 2008 Environments the issue is still under investigation.

    Thursday, August 13, 2015 12:33 PM
  • Hi,

    This issue is currently fixed in SQL Server 2012 and SQL Server 2014. The fix is to enable TLS 1.2 and install the below fix. Please refer the below KB,

    https://support.microsoft.com/en-us/kb/3052404 

    For SQL Server 2008 Environments the issue is still under investigation.


    Will there be any update to fix this in SQL Server 2008?
    Monday, November 2, 2015 4:04 PM
  • Hi,

    This issue is currently fixed in SQL Server 2012 and SQL Server 2014. The fix is to enable TLS 1.2 and install the below fix. Please refer the below KB,

    https://support.microsoft.com/en-us/kb/3052404 

    For SQL Server 2008 Environments the issue is still under investigation.


    Will there be any update to fix this in SQL Server 2008?

    Will there be an update to fix this in SQL Server 2008?
    Monday, January 25, 2016 4:25 PM
  • Hello,

    SQL Server 2008 and SQL Server 2008 R2 now support TLS 1.2 too.

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



    Hope this helps.



    Regards,



    Alberto Morillo
    SQLCoffee.com

    Saturday, January 30, 2016 5:03 PM
    Moderator