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

查看:1719
本文介绍了传统的ASP / IIS6 / Win2003的服务器无法与TLS服务器通信的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

贤者收费今天结束了他们的豁免网站与支付/授权服务器通信时使用SSL3。使用TLSv1现在是必需的。

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

我们有一个Windows Server 2003机器上运行IIS6,并在传统的ASP写的(可惜)两个站点。箱子已经修​​补/更新以减轻对狮子狗注册表项和各种在线跳棋支持这一行动。服务器应该使用TLS ONLY。

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.WinHtt prequest.5.1和后一个圣人支付交易时,尝试将立即失败。通过WinHtt prequest反馈的唯一错误-2147483638 - WinHttp.WinHtt prequest - 要完成此操作的数据尚未公布

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贤者收费adminstration接口。这一点,尽管和的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.

我已经验证有问题的服务器可以与贤者收费的服务器,通过使用卷曲沟通。卷曲的作品要么不指定的协议(它使用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?

下面是code的小样本返回上面引述WinHtt prequest错误:

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线,该脚本返回任何内容。这个脚本之前贤者支付工作转向东西了今天下午。

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)

这导致我安装理查德日的回答链接的修补程序(<一个href=\"http://hotfixv4.microsoft.com/Windows%20Server%202003/sp3/Fix192447/3790/free/351385_ENU_i386_zip.exe\" rel=\"nofollow\">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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆