An error occurred in the secure channel support -

Question

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:

Sub ShopXML4http(url, inStr, outStr, method, xmlerror)
  Dim objhttp
  Set objhttp = Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0")
  objHttp.open method, url, false
  If Method="POST" Then
    objHttp.Send instr
  Else
    objHttp.Send
  End if   
  outstr=objHttp.responseText
  Set objhttp=nothing
End Sub

This code works fine almost all of the time (thousands of requests per day), but sporadically it will fail with a message like this:

Number: -2147012739

Description: An error occurred in the secure channel support

Source: msxml6.dll

The application was recently moved from an old Windows 2003 Server to the 2012 Server, and this issue never seemed to be a problem on the old server. In addition, while this error is happening on the website, I could run the exact same code in a VBScript and it works fine. Resetting the application pool seems to cause the site to be able to do the secure HTTP requests again (although it often fixes itself before I can get to the server).

Answer 1

I have had the exact same problem after migrating from 2003 to 2008 R2 and found the solution. Change:

Set objhttp = Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0")

to:

Set objhttp = Server.CreateObject ("MSXML2.XMLHTTP.6.0")

and your problem will go away.

I tried to find the pros and cons about both objects, but haven't yet found a reason to not use XMLHTTP.

Answer 2

I encountered this error a few months ago myself. Most often, this issue is caused by an invalid SSL cert. Considering that at the time of the post you had just migrated to a new server, you probably just need to reinstall the SSL certificate.

I realize this question is old, but hopefully someone else can benefit from my answer.

Answer 3

In a Windows Server 2016 Classic ASP script, fetching an HTTPS URL from Windows Server 2012 R2, I recently had to remove SSL 2.0 from SecureProtocols in order to stop this secure channel error -2147012739.

' Use the latest client
Set httpClient = Server.CreateObject("WinHttp.WinHttpRequest.5.1")

' allow only TLS 1.2 or TLS 1.1
Const WHR_SecureProtocols = 9
httpClient.Option(WHR_SecureProtocols) = &h0800 + &h0200 
' Other values: TLS 1.0 &h0080, SSL 3.0 &h0020, SSL 2.0 &h0008 
' NB Including SSL 2.0 stops https to Windows Server 2012 R2 working

' Other options you may want to set, from https://docs.microsoft.com/en-us/windows/desktop/winhttp/winhttprequestoption 

' Ignore certificate errors
Const WHR_SslErrorIgnoreFlags = 4
httpClient.Option(WHR_SslErrorIgnoreFlags) = &h3300 

' Don't bother checking cert, or risking failure if we can't check
Const WHR_EnableCertificateRevocationCheck = 18
httpClient.Option(WHR_EnableCertificateRevocationCheck) = False 

Answer 4

Troubleshooting error codes:

1. -2147012739 is a HRESULT.
2. In hexadecimal that's 0x80072F7D.
3. Look at the LOWORD: 0x2F7D.
4. Convert that back to decimal: 12157.
5. Lookup 12157 error codes.
6. Find that it matches: ERROR_WINHTTP_SECURE_CHANNEL_ERROR

A bit of Google-fu finds http://msdn.microsoft.com/en-us/library/windows/desktop/aa383770(v=vs.85).aspx which states:

ERROR_WINHTTP_SECURE_CHANNEL_ERROR

12157

Indicates that an error occurred having to do with a secure channel (equivalent to error codes that begin with "SEC_E_" and "SEC_I_" listed in the "winerror.h" header file).

However, you already discovered this as the message you got was "Description: An error occurred in the secure channel support". So this leads us right back where we started.

The other observation I make is that your code is a non-asynchronous WinHTTP request (I know it has to be to function inside ASP), but, the concern is, due to the high frequency, your machine could be processing more than one WinHTTP request concurrently. I've seen some Windows deliberately throttle the total number of active concurrent WinHTTP request by blocking the late requests. For example, on a Windows 7 machine a process cannot make more than 2 concurrent requests to the same remote server. i.e. The 3rd, 4th... requests will be blocked until the first two complete.

One solution is to load balance incoming request over more than one application pool or over more servers.

Answer 5

It's all valid however the 'critical' missing bit for TLS1.2 support on Windows 7 with IIS7.5 and classic asp is setting this in the registry:-

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000800

I hope that saves you a day of faffing, rebooting and head scratching! :)

This code snippet is useful for testing. https://www.howsmyssl.com/

<%
Set winhttp = Server.CreateObject("WinHTTP.WinHTTPRequest.5.1")
winhttp.open "GET", "https://howsmyssl.com/a/check", False
winhttp.Send
Response.Write winhttp.responseText 
%>

Answer 6

I've had the same issue and tried lots of solutions offered under a variety of posts but ultimately had no success, until now. I'll detail the solution that worked for me with reference to the problem as in my case it was PayPal. I've not opened a new post as this might not be just a paypal issue in future.

The solution is a combination of a number of stackoverflow posted solutions to similar problems but this seemed the best one to add to.

The problem

Trying to test PayPal IPN on Windows Server 2008 using classic ASP using the PayPal Sandbox returns the error "An error occurred in the secure channel support".

Why it is a problem

PayPal is requiring all communications with their systems to be as secure as possible. You will need a connection that is TLS 1.2. Windows Server 2008 is not TLS 1.2 by default.

PayPal threw some confusion into the mix by saying you need a Verisign G5 certificate, which you do for the server root but not the domain you are running your code on. I also didn't install any PayPal certificates as I don't use the API. I don't believe you need your comms from an HTTPS site either - although my domain is secured using a standard GoDaddy EV cert although I did a test on a non HTTPS site after and that worked too.

My solution

1. First check which kind of security your server is using via SSL Labs. It should be TLS1.2 or higher and no other TLS's or SSL's. It must also have a SHA256 encryption. You may need to patch the server: https://support.microsoft.com/en-us/kb/3106991.

2. Use IISCrypto to set the correct TLS and ciphers. I used the registry changes offered up elsewhere on stackoverflow but this did not work and actually totally screwed up my server for everything using HTTPS posts, not just my development site! IISCrypto also handles the ciphers.

3. Make sure your application pool is v4.5, which in itself is unclear because IIS might only offer v4.0 as an option. However this is probably actually v4.5. You can verify this via https://msdn.microsoft.com/en-us/library/hh925568(v=vs.110).aspx.

4. Within your code you need to use Server.CreateObject ("MSXML2.XMLHTTP.6.0"), not Server.CreateObject ("MSXML2.ServerXMLHTTP.6.0") as mentioned above.

Now I've no idea why the non-server XMLHTTP works as that seems contrary to the documentation behind it. Right now, after 10 days of stress, panic and frustration I don't care! I hope this is useful for others.

Finding the solution was a nightmare so I'll add some phrases below to help others if searching:

PayPal IPN failing with server error

PayPal SSL Windows 2008 errors

An error occurred in the secure channel support

classic ASP PayPal Sandbox SSL errors

I'd like to publicly thank Rackspace and GoDaddy for their help with this. I'd like to publicly state that I found paypal have the worst technical support ever and just do not care, constantly pointing to their own docs, if they ever respond. They say they've been sending emails out about this since September 2014 but I never received one. These new requirements are active on the PayPal Sandbox but go live in September 2016. I only came across it as developing a new solution so needed the sandbox - if you're running live you won't know about the problem until it hits and then you're dead in the water. Test your entire payment system on the PayPal sandbox asap is my advice!!