An error occurred in the secure channel support - Classic ASP HTTP Request

后端 未结 8 1609
悲&欢浪女
悲&欢浪女 2020-12-29 03:02

I have a classic ASP website running on a Windows Server 2012 box. One page makes a HTTP request to another application over https using code like this:



        
8条回答
  •  半阙折子戏
    2020-12-29 03:12

    None of the answers above applies to my situation. Then I hopped on the link here:

    https://support.microsoft.com/en-za/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in

    This update provides support for Transport Layer Security (TLS) 1.1 and TLS 1.2 in Windows Server 2012, Windows 7 Service Pack 1 (SP1), and Windows Server 2008 R2 SP1.

    Applications and services that are written by using WinHTTP for Secure Sockets Layer (SSL) connections that use the WINHTTP_OPTION_SECURE_PROTOCOLS flag can't use TLS 1.1 or TLS 1.2 protocols. This is because the definition of this flag doesn't include these applications and services.

    This update adds support for DefaultSecureProtocols registry entry that allows the system administrator to specify which SSL protocols should be used when the WINHTTP_OPTION_SECURE_PROTOCOLS flag is used.

    This can allow certain applications that were built to use the WinHTTP default flag to be able to leverage the newer TLS 1.2 or TLS 1.1 protocols natively without any need for updates to the application.

    This is the case for some Microsoft Office applications when they open documents from a SharePoint library or a Web Folder, IP-HTTPS tunnels for DirectAccess connectivity, and other applications by using technologies such as WebClient by using WebDav, WinRM, and others.

    This update will not change the behavior of applications that are manually setting the secure protocols instead of pass the default flag.

    Client service on Windows 2008 R2 server outbound to server over TLS reciprocated the error in question. I thought it could be cipher suite compatibility. Wireshark trace indicated version in Client Hello request was TLS 1.0 but server requires TLS 1.2. The cipher suites sent to outbound server from client service were fine. The problem is the client service or application on Windows server default employs the system default, which is not TLS 1.2.

    The solution is to add a registry subkey named DefaultSecureProtocols with a value corresponding to which TLS version(s) should be supported. Add said registry subkey, with type DWORD, to the following locations:

    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
    • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp

    For Internet Explorer fix, you can add a similar registry subkey titled SecureProtocols, also with type DWORD, to the following locations:

    • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings

    Below you can find the table of values for both subkeys:

    DefaultSecureProtocols Value         Protocol enabled
    0x00000008                           Enable SSL 2.0 by default
    0x00000020                           Enable SSL 3.0 by default
    0x00000080                           Enable TLS 1.0 by default
    0x00000200                           Enable TLS 1.1 by default
    0x00000800                           Enable TLS 1.2 by default
    

    For example:

    The administrator wants to override the default values for WINHTTP_OPTION_SECURE_PROTOCOLS to specify TLS 1.1 and TLS 1.2.

    Take the value for TLS 1.1 (0x00000200) and the value for TLS 1.2 (0x00000800) then add them together in calculator (in programmer mode), the resulting registry value would be 0x00000A00.

    I applied 0x00000A00 as the value for both subkeys and it successfully resolved the issue.

    There is also an Easy Fix (link is here: https://aka.ms/easyfix51044) available from Microsoft, if you don't wish to manually enter registry subkeys and values.

提交回复
热议问题