经典ASP/IIS6/Win2003服务器无法与TLS服务器通信 [英] Classic ASP / IIS6 / Win2003 Server can't communicate with TLS server

问题描述

Sage Pay 今天终止了网站在与其支付/授权服务器通信时使用 SSL3 的豁免.现在需要 TLSv1.

Sage Pay today ended their exemption for sites to use SSL3 when communicating with their payment / authorisation servers. TLSv1 is now required.

我们有一个运行 IIS6 的 Windows Server 2003 机器，以及两个用 Classic ASP 编写的站点(遗憾的是).该框已被修补/更新注册表项以减轻对 POODLE 的攻击，并且各种在线检查器对此进行了支持.服务器应仅使用 TLS.

We have a Windows Server 2003 box running IIS6, and two sites written (sadly) in Classic ASP. The box has been patched / registry keys updated to mitigate against POODLE, and various online checkers back this up. The server should be using TLS ONLY.

但是，当尝试使用 WinHttp.WinHttpRequest.5.1 和 POST 授权 Sage Pay 交易时，尝试立即失败.WinHttpRequest 反馈的唯一错误是-2147483638 - WinHttp.WinHttpRequest - 完成此操作所需的数据尚不可用."

However, when trying to authorise a Sage Pay transaction using WinHttp.WinHttpRequest.5.1 and a POST, the attempt fails immediately. The only error fed back by WinHttpRequest is "-2147483638 - WinHttp.WinHttpRequest - The data necessary to complete this operation is not yet available."

同一服务器上的 Internet Explorer 也无法访问托管在相同 URL 上的 Sage Pay 管理界面.尽管 SSLv2 和 SSLv3 在 Internet 选项中已关闭，但仍然如此.同样，TLSv1 应该是盒子上任何东西都可用的唯一选项.

Internet Explorer on the same server is also unable to access the Sage Pay adminstration interfaces hosted on the same URLs. This, despite SSLv2 and SSLv3 being turned off in Internet Options. Again, TLSv1 should be the only option available to ANYTHING on the box.

我在 WinHttp 对象上设置的超时或选项无关紧要 - 它失败得如此之快，几乎就像它甚至没有尝试过一样.

It doesn't matter what timeouts or options I put on the WinHttp object - it fails so quickly it's almost like it hasn't even tried.

我已验证有问题的服务器可以使用 curl 与 Sage Pay 的服务器进行通信.curl 可以在没有指定协议的情况下工作(它使用 TLS)或通过手动指定 - 当指定 SSL2 或 3 时不会 - 如预期的那样.

I have verified that the server in question CAN communicate with Sage Pay's servers by using curl. curl works either without a protocol specified (it uses TLS) or by manually specifying - and won't when SSL2 or 3 is specified - as expected.

如果这行得通，为什么其他任何事情都行不通——当服务器配置的每一点都表明应该这样做时?

If that works, why won't anything else - when every bit of server configuration says it should?

这是返回上面引用的 WinHttpRequest 错误的一小段代码示例:

Here is a small sample of code which returns the above quoted WinHttpRequest error:

<%
VSPServer = "https://test.sagepay.com/showpost/showpost.asp"

Set objHTTP = Server.CreateObject("WinHttp.WinHttprequest.5.1")
On Error Resume Next
objHTTP.Open "POST",CStr(VSPServer),False
objHTTP.Send "Hello"

If Err.Number <> 0 Then
    Response.Write "Status: " & objHTTP.Status & "<p>"
    Response.Write Err.Number & " - " & Err.Source & " - " & Err.Description
End If

On Error Goto 0
Set objHTTP = Nothing
%>

如果在 objHTTP.Open 行中将 False 更改为 True(以运行此异步)，则脚本不会返回任何内容.这个脚本在 Sage Pay 今天下午关闭之前工作.

If False is changed to True (to run this async) in the objHTTP.Open line, the script returns nothing. This script worked prior to Sage Pay turning things off this afternoon.

推荐答案

我现在已经设法解决了这个问题.在改变我搜索问题的性质后，我发现 Win2003 使用不同的加密算法连接到服务器，甚至通过 TLS.它使用 3DES，而 SagePay 需要 AES.(来源:SagePay 协议违规错误)

I have now managed to resolve this. After changing the nature of my search for the problem I discovered that Win2003 uses a different encryption algorithm to connect to servers, even via TLS. It uses 3DES whereas SagePay expects AES. (Source: SagePay Protocol Violation Error)

这让我安装了从 Richard Day 的回答链接的修补程序 (http://hotfixv4.microsoft.com/Windows%20Server%202003/sp3/Fix192447/3790/free/351385_ENU_i386_zip.exe - 这是针对 32 位英语的修复 - 热修复页面在这里:https://support.microsoft.com/kb/948963) - 以及，重新启动后，一切都到位了.

This led me to install the hotfix linked from Richard Day's answer (http://hotfixv4.microsoft.com/Windows%20Server%202003/sp3/Fix192447/3790/free/351385_ENU_i386_zip.exe - this is the fix for 32 bit English - the hotfix page is here: https://support.microsoft.com/kb/948963) - and, after a reboot, everything fell into place.

感谢所有提出建议的人.看起来，最终，这是服务器级别的问题.如果这需要移动此帖子(因为它不再与编程相关)，那么请这样做.

Thank you to everyone who made suggestions. It looks like, in the end, it was a problem at the server level. If that requires that this post be moved (as it's no longer programming related), then please do so.

这篇关于经典ASP/IIS6/Win2003服务器无法与TLS服务器通信的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！