topic Re: AIM 403 Error using transact after Authorize updated SSL Certificate in Integration and Testing

AIM 403 Error using transact after Authorize updated SSL Certificate

ppatel — Fri, 25 Jul 2014 13:53:42 GMT

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?

Re: AIM 403 Error using transact after Authorize updated SSL Certificate

RichardH — Fri, 25 Jul 2014 16:46:49 GMT

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

Re: AIM 403 Error using transact after Authorize updated SSL Certificate

gbrooks — Fri, 25 Jul 2014 17:10:27 GMT

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);

Re: AIM 403 Error using transact after Authorize updated SSL Certificate

RichardH — Fri, 25 Jul 2014 17:30:29 GMT

@gbrooks

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

Richard

Re: AIM 403 Error using transact after Authorize updated SSL Certificate

gbrooks — Fri, 25 Jul 2014 17:40:41 GMT

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.

Re: AIM 403 Error using transact after Authorize updated SSL Certificate

RaynorC1emen7 — Fri, 25 Jul 2014 19:31:40 GMT

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

Re: AIM 403 Error using transact after Authorize updated SSL Certificate

ppatel — Fri, 25 Jul 2014 19:34:28 GMT

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

Re: AIM 403 Error using transact after Authorize updated SSL Certificate

gbrooks — Mon, 04 Aug 2014 15:20:12 GMT

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.

Re: AIM 403 Error using transact after Authorize updated SSL Certificate

ppatel — Mon, 04 Aug 2014 21:20:42 GMT

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.

Re: AIM 403 Error using transact after Authorize updated SSL Certificate

gbrooks — Mon, 04 Aug 2014 22:41:11 GMT

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.

Re: AIM 403 Error using transact after Authorize updated SSL Certificate

inxcapable — Wed, 29 Oct 2014 18:25:03 GMT

We have been encountering the same issue - here's what we have discovered:

1) Any orders with an http POST of 1882 characters or less succeeds
2) Any orders with an http POST of 1883 characters or more returns the 403 error.

Has anyone identified a tech support person at Authorize.net that is helpful? I have an open support ticket, but we're not making much progress.

Mary

Re: AIM 403 Error using transact after Authorize updated SSL Certificate

RichardH — Wed, 29 Oct 2014 22:30:35 GMT

Hello @inxcapable

Are you able to duplicate this in the sandbox? If you can provide the support ticket number and Gateway ID, we can look into this further.

Richard

Re: AIM 403 Error using transact after Authorize updated SSL Certificate

Lilith — Thu, 30 Oct 2014 16:00:35 GMT

@inxcapable We have the Gateway ID and ticket number now, and I'll bring this up to our developers. Thanks.

Re: AIM 403 Error using transact after Authorize updated SSL Certificate

ppatel — Wed, 03 Dec 2014 03:09:09 GMT

Was there any resolution to this? I thought capitalizing the POST would have resolved it but it did not.

Re: AIM 403 Error using transact after Authorize updated SSL Certificate

Lilith — Wed, 03 Dec 2014 22:44:57 GMT

@ppatel How long is your POST string?

As @inxcapable discovered, request strings over 1882 characters are causing HTTP 403s. Our developers will be looking into fixing this, but not until after the holiday season.

We find that the larger request strings are more common among merchants using the itemization features, and that in many cases it's possible to reduce the description of each line item to fit the request string into 1882 characters or less.

Re: AIM 403 Error using transact after Authorize updated SSL Certificate

Lilith — Mon, 16 May 2016 16:27:32 GMT

I apologize for not posting a follow-up sooner.

This situation recurred for another developer recently.

Upon investigation, we confirmed that, if you are using parameterized URLs, and thus submitting the info using HTTP GET rather than HTTP POST, you will run into HTTP 403 errors when exceeding 1800+ characters. (The exact character count depends on the size of your individual HTTP request headers, which in turn depend on the platform you're using.)

We strongly encourage any developers encountering similar issues, to switch to HTTP POST immediately. The legacy API guides had been previously updated to encourage using HTTP POST for submitting all transaction requests.

Note that this limitation only applies to using HTTP GET to submit transactions. The Authorize.Net API, documented at https://developer.authorize.net/api/reference/, only allows HTTP POST by default. Any future RESTful APIs we may release, will support HTTP GET for requesting service resources, but will require HTTP POST for submitting data in an API call.

Thanks.