I'm updating a legacy application to use a new payment REST service and I'm having trouble with a POST request. The code runs fine on a Windows 10 development machine but fails on Windows Server 2008 SP2:
Set HttpReq = Server.CreateObject("MSXML2.ServerXMLHTTP")
HttpReq.open "POST", uri, False
HttpReq.setRequestHeader "Content-Type", "application/json"
HttpReq.setRequestHeader "Authorization", authHeader
HttpReq.send json '<-- Error here
The Error I receive is:
msxml3.dll error '80072f8f'
A security error occurred
The webservice I'm calling only supports TLS 1.2, but as far as I can tell the machine running this code also supports TLS 1.2.
There is another question on StackOverflow with similar symptoms to this question that occurs on a Windows Server 2003 machine. The solution to that question suggests a HotFix be applied, but the link to the hotfix has been replaced with a cryptography programming guide which, whilst probably relevant, does not point to an obvious solution.
Update: It looks like I can send the same request via CURL on the same machine, so the machine itself can handle the connection to the url
Update 2: I've check the cipher suites available on the server against those reported for the target site, and there is some overlap. Also the target site is accessible via CURL, so I assume the two machines are able to communicate over https at some level
Update 3: I've adjusted the CreateObject line to use "MSXML2.ServerXMLHTTP.3.0" and "MSXML2.ServerXMLHTTP.6.0", but the error is just the same
Update 4: I've added the setOption line as suggested in other solutions on SO here and here, but the error code is the same. E.g. objHTTP.SetOption 2, objHTTP.GetOption(2)
Update 5: I ended up working around the problem by writing the necessary logic in a .NET Framework assembly, and accessing the functionality via COM. I don't particularly like the solution as it spreads the code across many codebases and complicates the deployment somewhat, but it was a pragmatic choice. I've also advised the business owners that the application and server are overdue for modernisation
I add the same issue a couple of years ago.
Then, can you try this piece of code and confirm that you see TLS v1.2 at the end of the response?
If TLS VERSION returned is not TLS 1.2, then it means your Windows 2008 server still needs a bit of configuration. Please proceed like described here and it should work.