AIM 403 Error using transact after Authorize updated SSL Certificate

[ppatel]

We have an older shopping cart that's been working for years on IIS 6 and classic ASP. Yesterday, credit card transactions failed. The only error I get is a server status 403. Called support twice and they said their SSL had been updated and I needed to enable compression on my server. I did that. Same issue.

I've run a URL test order through on the server to https://secure.authorize.net/gateway/transact.dll and it works. Our conclusion at this point is that the header is incorrect. We are using a ServerXMLHTTP header. I've tried several additions with no success. My latest attempt is below:

Set objhttp = Server.CreateObject("Msxml2.ServerXMLHTTP")

objhttp.open "post", "https://secure.authorize.net/gateway/transact.dll", false
objhttp.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"

objhttp.setRequestHeader "Accept-Encoding", "gzip, deflate, sdch"
objhttp.setRequestHeader "Content-Length", len(strrequest)

objhttp.send strrequest

Original code:

Set objhttp = Server.CreateObject("Msxml2.ServerXMLHTTP")

objhttp.open "post", "https://secure.authorize.net/gateway/transact.dll", false

objhttp.send strrequest

The only thing I get back is a 403. No response text. Any suggestions?

[RichardH]

Hello ppatel,

Do you have any details from the SSL negotiation that would help further troubleshoot?

You might check to ensure your SSL configuration is correct using https://www.ssllabs.com

Richard

[gbrooks]

I am in exactly the same situation with one of my client's sites. Classic ASP/IIS 6/Windows Server 2003. The payment gateway has been operational for years. Starting Thursday 7/24/2014, transactions fail with status 403 (Forbidden). What has changed on the auth.net end and what do I have to do to make this work again?

This is a big deal - unhappy client, unhappy customers of the client, and unhappy developer (me) throwing away multiple hours that could have been billed on other jobs.

My jscript code:

var url="https://secure.authorize.net/gateway/transact.dll";
xmlHttp.onreadystatechange=checkcardstatus;
xmlHttp.open("Post", url, false);
xmlHttp.send(PostData);

[RichardH]

@gbrooks 

Are you able to duplicate this in the sandbox?  Do you have any logs from the SSL negotiation to further troubleshoot?

Richard

[gbrooks]

Hi RIchard,

Sorry to sound like a knucklehead, but this is stuff that I inherited that someone else originally deployed. So I don't really know anything about sandbox or SSL negotiation logs. If by the sandbox you mean using https://test.authorize.net/gateway/transact.dll as the target for the request, then I get exactly the same response.  I'm willing to dive into SSL negotiation logs, but I need to be pointed in the right direction. I'm not sure where to look for these on the server or what I would have to enable to have them generated if they are not currently beign generated.

Thanks,

Greg.

[RaynorC1emen7]

Can you capture http traffic on the success test that you ran on the server compare to the asp code?

[ppatel]

Richard:

I did security updates on the server, and restarted. I'm now getting a Grade B (from F). The primary thing I see is protocal support.

The server supports only older protocols, but not the current best TLS 1.2. Grade capped to B.

The server does not support Forward Secrecy with the reference browsers. 

I don't think IIS 6/Windows 2003 supports TLS 1.2

Philip

[gbrooks · Accepted solution]

Hi Philip,

I may have unearthed the problem that we were both experiencing. Please try capitalizing your "post" verb to "POST" in the http request open() call. This solved the problem for me with no further changes necessary.

FWIW, after spending upwards of 20 hours messing around with request headers, compression, SSL negotiation, blah, blah, blah with no luck (per auth.net support), I started implementing a proxy on a completely different server. While doing so I was getting 405 verb not supported errors from the server I was hosting the proxy on. Changing my verb from "Post" to "POST" solved that problem, so I decided to give it a try with the direct request to transact.dll and voila.

No idea why the verb started causing 403 errors a week and a half ago, but hopefully this might help someone else out as well.

Greg.

[ppatel]

Changing it to all CAPS did make a connection to Authorize.NET. Still getting errors, but this gets me much further. I'm getting a Response Code=3 now.

Well done Greg.

[gbrooks]

FWIW - per RFC 5.1.1 the Method token (verb) is case sensitive and should always be capitalized - http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html. No idea why our developer (or yours of course :-) chose not to completely capitalize it, but obviously it worked until about 11 days ago. Sigh.