Showing results for 
Search instead for 
Did you mean: has updated their SSL certificates

Today we had to update the 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:


Why cant 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!




Hope this helps...


Steve Stout

Kagan Publishing


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



I'm going by what tech support told'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

AIM is

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

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:




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:


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

I cannot browse to


I get page cannot be displayed...


I can browse to and it prompts me about a cert error but will let me pass

Thanks...I'm going to take a guess that we don't support compression on our's mostly 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

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


which compression settings from your IIS?

Has anybody resolved this for IIS 6?


I've run a URL test order through on the server to 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") "post", "", 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") "post", "", false

objhttp.send strrequest


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

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


I took the compression settings off.

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 to see if you support TLS 1.2.


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