Authorize.net has updated their SSL certificates

[stoutman]

Today we had to update the authorize.net SSL certificates on our server to re-enable secure communications.

They have updated their SSL certs. We found 3 certs which we updated to make sure the chain was recognized by our server.

Depending on your server type, this procedure will be different.

We are using ColdFusion 9 and had to add the certs to our java cert store.

We followed these directions to resolve our issue:

http://stackoverflow.com/questions/20469194/coldfusion-https-connection-failure

Why cant autoroize.net just post that they changed the certs?

I had this same issue with another vendor and they kept telling me they made no changes.

Server admins really need to learn how to communicate with their tech support people!

Grrrrr!!!

Hope this helps...

Steve Stout

Kagan Publishing

[RaynorC1emen7]

enable compression settings it for allow your server to output compress data. nothing about ssl cert. Maybe is the reboot of your server that fixed it?

the url should be either one for soap the other is xml

https://api.authorize.net/soap/v1/Service.asmx

or

https://api.authorize.net/xml/v1/request.api

[jtesch12]

I'm going by what tech support told me...it's a SSL cert issue because after they made the update, it broke some merchantss AIM service.

What do you mean by soap?

Strange...can't browse to that address from the server

[RaynorC1emen7]

AIM is https://secure.authorize.net/gateway/transact.dll

put the in the broswer on the IIS server and see if you get any error.

should get

The following errors have occurred.

(13) The merchant login ID or password is invalid or the account is inactive.

can't browse to that address from the server

can it browse site like https://www.gmail.com/

[RichardH]

I suspect this issue isn't related to SSL.  

However, a recent change where Authorize.Net servers now support content-encoding which compresses the http traffic may be the issue.  If your "accept-encoding" header indicates support for compression , then the response back from Authorize.Net might look something like this:

�`I�%&/m�{J�J��t��`

However, If you have enabled content-encoding your server, but the application doesn't support the compression method in the response,  it won't be able to use it.  The application might indicate the transaction was declined; or that it cannot read or parse the transaction; it may simply state there is a problem.

Below are some additional resources that might help.

Windows Server users may reference the below site when troubleshooting content-encoding issues:

http://www.iis.net/learn/troubleshoot/performance-issues/troubleshooting-iis-compression-issues-in-i...

For Apache users, this reference explains how to enable gzip and how to disable the request:

https://wiki.apache.org/httpd/ReInflating

[jtesch12]

I cannot browse to https://secure.authorize.net/gateway/transact.dll

I get page cannot be displayed...

I can browse to https://gmail.com and it prompts me about a cert error but will let me pass

[jtesch12]

Thanks...I'm going to take a guess that we don't support compression on our application...it's mostly asp.net stuff...and rather dated developers...I just removed the compression setting from my IIS...i'm hoping it just starts working like it did the other day.

Still cannot get to that .dll web address though....not from the server at least

[RaynorC1emen7]

which version of windows? 2003? windows updates current? IE version? have you try clearing the cache?

which compression settings from your IIS?

[ppatel]

Has anybody resolved this for IIS 6?

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?

[jtesch12]

I'm back working on my issue too...it is indeed IIS 6. windows 2003 server, IE version 8

I took the compression settings off.

[ppatel]

We spent Thursday and  Friday working on this. No luck. I've switched to a paypal solution for now.

Our current thinking is that it's an SSL protocal issue. Authorize.NET may require TLS 1.2. Windows 2003 doesn't support this, and will never work. You can test your server at https://www.ssllabs.com/ssltest/analyze.html to see if you support TLS 1.2.

I get a support email once a day from authorize.net, so, I'll wait to see if they come up with something. Or just switch to Paypal.