cancel
Showing results for 
Search instead for 
Did you mean: 

Production Certificate Upgrades begin May 26, 2015

Authorize.Net will upgrade and replace Production certificates for API services starting May 26, 2015. Technical details are provided for solutions connecting to Authorize.Net APIs that may need updates.

 

To see the full announcement, please see this blog post.

RichardH
Administrator Administrator
Administrator
172 REPLIES 172

@Trevor Thanks for the suggestion. That seems to have worked for one customer. They were behind on their patches. Still working with the second customer.

We use the SIM method and our transactions are not going through.  Do we need to install all 4 certificates?

I mentioned to AuthNet phone support that I messaged a couple of the admins on this forum directly looking for help. I was told (by their phone support) they don't have actual employees on this forum -- rather, they pay developers to pose as moderators/admins needed...

Please let me know how to get paid by ignoring everyone!

Thank you, seeraig.

 

I imported that single cert into the JRE store using your command, restarted all the CF services (CF9, WinServer 2008 R2 Std), and it immediately started working. Ridiculously bad planning and support from Authorize.net on this. Ridiculous. 

 

Thanks again, seeraig.

Has anyone found the email notices from authorizenet that would have let us know about the SHA-2 upgrade?  I just went through my inbox, my junk mail and my deleted folder and did not find anything.  If anyone has it, please let me know the timestamp of when it was sent so I can see if we did receive it or not...thanks!

How I fixed my problems on a Centos Server.

 

First of, there IS NO SUPPORT. You are on your own.
If you get something working, be nice to your colleagues and Post it here.

 

I was sent chasing up a dozen blind alleys.

 

Authnet has made 2 changes:

  1. Security Hash Algorithm 2 (SHA-2) [using] EnTrust’s SHA-256, 2048-bit certificate
  2. Requiring root certificates from 3 different vendors

About the first problem

 

I was running on an 7-year old server with openssl 97.
When I tested the server the test showed that had SHA-2/SHA256/2048-bit configuration.

 

It still failed however.
I moved the program to a different server with openssl 1.01, and got something other than complete failure.
So there's at least a benchmark: Openssl 97 fails, openssl 101 works.

About the second problem.
Authnet advises "INSTALLING these new root certs"
After a lot of study, I realized I was too stupid to do this.

 

If you are using CURL/php, however, there IS a workaround that isn't too hard.
Download this zipfile from github.
https://github.com/AuthorizeNet/sdk-php/archive/master.zip

Unzip this file from the archive:
sdk-php-master\lib\ssl\cert.pem

This file contains all the required certs, assembled for you by Authnet. (good luck finding this out!)

Now I'm not sure about the proper form for a .pem file, so I edited it to look like the cert file used by fiefox.

Common Name: GeoTrust Global CA
-----BEGIN CERTIFICATE-----
   blah blah
----END CERTIFICATE ----

I'm not sure the editing was required, but I did it and it worked, so I'm telling you.

Upload this file to your server.
Make your CURL look like

$myCurlElement=curl_init();
  //other curl stuff
curl_setopt($myCurlElement, CURLOPT_CAINFO, "/Path/To/cert.pem");

After these changes, everything worked fine.

It only took me 20 hours of beating my head against a wall to figure this out.
These changes MIGHT have been better documented and explained. They Might.
They Might have given us some gd NOTICE, like an email with "THIS MEANS YOU" Stamped all over it.

FWIW, I use a cheap COMODO SSL cert (the $9 version from Namecheap) and it works fine after these changes. On the recommendation of Authnet's tech support I  tried switching to an expensive $150 cert from Geotrust and it failed.

nemonoman
Member

To continue my previous message:
The CURL changes were for the CURL used in AIM type code.

You can downlad the pem file as I edited it from my server here:

     http://ad2ad.com/download?filename=http://ad2adnetwork.com/test_ad2ad/cert.pem

nemonoman
Member

Yikes, not how I wanted to spend my Friday night. Just to save other Ubuntu users time, here are some notes:

 

** Note: I couldn't use the Baltimore CyberTrust Root certificate they link to in the blog post; I had to fetch the .pem version here instead: https://cacert.omniroot.com/bc2025.pem **

 

In Ubuntu, to install the new certificates for OpenSSL:

 

1. SSH into your server and `cd /usr/local/share/ca-certificates`.

2. Use a text editor to create .crt files containing the content of each certificate they link to in the blog post. (or just `scp` them in).

3. Run `sudo update-ca-certificates`. This will update your ca-certificate.

4. `cat /etc/ssl/certs/ca-certificates.crt` and doublecheck that the certificates are in there somewhere. This is a list of all the certificates concatenated together.

5. Run `openssl s_client -connect api.authorize.net:443 -CApath /etc/ssl/certs`. It should say `Verify return code: 0 (ok)` at the bottom if this worked.

 

If you're using Rails and ActiveMerchant, you'll also need to throw a monkeypatch in your initializers: http://www.bartlettpublishing.com/site/bartpub/blog/3/entry/384

 

On the upside, aren't you glad you happened to have added PayPal support as a fallback last month? I am :-)

 

 

 

 

 

gh
Member

You introduce changes to your platform
That you know IN ADVANCE
Will cause many of your customers to FAIL.

 

WHEN they fail
the failures can't be fixed by the merchant
or the webmaster
or program coder

NOT even the hosting company tech support can make the fix.

The FIXES you require
can only be made by someone with ROOT SERVER ACCESS

AND as anyone with root server access knows
even "simple" fixes can cause the whole server to break.
and ALL the server's clients to fail.

 

 

I am aghast at this disasterous, ill-conceived decision.

Putting the Announcement in an obscure link on the rarely-visited Auth.net control panel?? Bad decision number 2.
Not providing adequate technical instructions on what needed to be done. Bad Decsion number 3.

Not providing notice and training to customer support reps, so they simply make up 'possible' answers? Bad Decision 4.

 

These decsions amounted to a big **** you to everyone affected.

"Hey, YOU go figure out what's wrong, you poor merchant jerks -- then figure out a way to fix it. Not My Problem."

 

I have written code that has processed about 10Million $ through authnet. This is how you treat me?
I have recommended authorize.net to 8 clients, each processing about 1M. I regret THAT bad decision.


nemonoman
Member