Cert.pem expired. Why. Why Why.

[vaykgear1]

Suddenly started getting "Error connecting to AuthorizeNet" response. We use the older SDK (that does not require composer).

After a couple hours of searching, I tried various cert.pem files until I found one that worked.

How do we get notice that the cert.pem needs to change?

I tried the cert.pem from the NEW SDK and it did not work, why not?

[developermaui]

I found the cert.pem file in this path 

authorize.net/lib/ssl/cert.pem

This is an old PHP install - several years old. I put the new file there and renamed it.

[developermaui]

I do just want to share the horrible response I got from suppoert a day after asking for just "a bit more direction" than the previous response they sent. I'll add this to the reasons I push clients toward Stripe whenever it is an option. 

Thank you for contacting Authorize.Net for assistance with the steps to validate against our current certificate. I can certainly advise further about this inquiry.

 

I apologize, but the steps to validate against our certificate is a process that would need to be completed by your web developer.

 

I apologize for any inconvenience this situation has caused, but hope this will advise of the best steps to take to complete this process. Please feel free to contact Authorize.Net by email at support@authorize.net or at our 24x7 Merchant Support line at 877-447-3938 for assistance with any questions or concerns you may have.

 

Thank you for contacting Customer Support.

Regards,

Jordan
Authorize.Net Customer Support

[andrescastillod]

https://github.com/activemerchant/active_merchant/blob/master/lib/certs/cacert.pem

[andrescastillod]

on your library you should have a folder "lib/ssl/cert.pem" just replace the info with the info here https://github.com/activemerchant/active_merchant/blob/master/lib/certs/cacert.pem 

[jwcarlton]

Had the same problem, and after incorrect information from the Support Chat (Jakob) this finally led me to the right way to fix it.

I remember having the same problem last year, with the certificate expiring.

I'm using a PHP script that I wrote in 2012. How was I supposed to know that the certificate need to be updated ahead of time? I get emails from Authorize.net on occasion, but I can't find where anything about this was mentioned.

Better yet, is there a "correct" way to automatically update the certificate, other than just having failed transactions and spending half my day scrambling and trying to remember how to fix it?

[stockyardsrodeo]

I just had this same problem too and after spending all day looking for the answer, I just changed my connection string to the api gateway

from

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

to

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

now everything works great. 

Weird how randomly Authorize.net just changes things.  I wonder if this has to do with the TLS 1 conversion thingy that I get emailed or how long this api2 is going to work till it bugs out on me.

[jkoerber23]

So I had the same issue this morning for our 150+ clients and their 30,000 customers.  As of 12:00am May 1st all transactions started failing on our servers (local hosted hardware and AWS remote servers).  Calling ANET support was useless and there is literally no access to level 2 support for critical issues where tens of thousands of customers are stranded and unable to make payments.  How can they not have support for critical issues like this?

We are using the old SDK (not sure the version) that supports our old PHP installs of 5.3.29 (yes we are trying to upgrade those but have a lot of system changes before that's possible).

After about 3 hours and hundreds of support calls from our clients, everything started magically working again.  From about 9:45am Pacific (May 1st 2018) until about 10pm Pacific time when all transactions started failing again.  So far we have not made any changes to our servers, so I have no idea why ANET's services are on and off again throughout the day.

Thank goodness I found this thread.  Someone kind enough to post their solution when the ANET support folks can't simply tell us the same solution.  I took the advice from rubiety and develepormaui and pulled up the suggested cert file at: https://github.com/activemerchant/active_merchant/blob/master/lib/certs/cacert.pem

Here's how I got this to work on our Apache servers running php 5.3.29.  I pulled up the file via the URL, then clicked the "RAW" button just above it to display the raw text of the file, and then copied and pasted it into my text editor for coding (I use BBEdit on a Mac).  I then saved the file as "cert.pem" in the /sdk-php-master/lib/ssl/ directory (renaming the old cert to cert.pem.BAK).  This new cert.pem file is HUGE compared to the original, but it contains tons of extra certificates.  But who cares, it worked!

This immediately fixed the issue on our system.  Thanks to everyone who contributed to this solution.

So the big question is: WHY THE HECK DIDNT ANET ANNOUNCE THIS CHANGE, JUST LIKE THE TLS 1.2 MIGRATION.  THIS IS A COMPLETE FIASCO THAT CAUSED OUR COMPANY A LOT OF PAIN AND ANGRY CUSTOMERS.  LET THEM KNOW THIS IS UNNACEPTABLE.

[jtodtenb]

I just installed this cert.pem in two places on our server it is currently working for us:

https://raw.githubusercontent.com/activemerchant/active_merchant/master/lib/certs/cacert.pem

Installed to:

/home/supplementrelief/public_html/store/includes/sdk-php-master/lib/ssl/
and
/home/supplementrelief/public_html/store/includes/anet_php_sdk/lib/ssl/

This problem just started yesterday at 5/1 and after fratnic forum diving we found a post and installed a different cert.pem that worked until sometime after midnight last night when the problem occured again. This morning we found and tried the cert.pem referenced above which is working for now...

I called Auth.net support at 877-447-3938 yesterday, and like many others on this thread, got no help and was told to "have my web developer" figure this out.  I share others frustration that Auth.net did not proactively contact thier accounts and let them know they were changing something that would potentially break e-commerce functionality. I also think they should provide specific technical support instructions to assist their accounts and not assume we have a "web developer" on staff or have the ability to contract one at short notice. For small business owners it is devasting when your customers cannot order from you and then leave your site to go to competitors because your site is down or because they no longer think they can trust your site with their credit card because of "order failure probelms". I encourage each of you to share your feedback with Auth.net in hopes they will provide better support for their accounts in the future.

[rinogo]

Just here to add our "me too" to this issue. No heads-up from Authorize.net, no developer.authorize.net blog entry, no helpful emergency "top of page banner" on developer.authorize.net. Even just finding the Authorize.net platform status page took some digging.

I finally found a single sentence (without links for explanation or help) on https://status.authorize.net/ (which humorously shows all green and "No incidents reported today"). The message is: "Note: SSL certificates for secure.authorize.net and api.authorize.net have been updated."

It would have been great to know this was going to happen *before* the change was made. It would also have been great to know what steps we need to take to adapt to this change.

Also, before someone mentions the "Subscribe to Updates" option on https://status.authorize.net:

1. We shouldn't need to subscribe to this to be forewarned/notified that a breaking change will be/has been made.

2. Subscribing to updates literally won't do anything if Authorize.net doesn't actually open an official incident. As of this moment, there is no incident on https://status.authorize.net.

I wouldn't have known there were others out there dealing with this same issue if it weren't for this forum. Thanks to all those who posted.

Authorize.net, we're generally pleased with our service, but this is unacceptable. I'm a generally patient and understanding person, but truly, sincerely, I mean that this is unacceptable. Hundreds, thousands, perhaps even tens of thousands of businesses lost (or are still losing) real money because of this oversight. Please help us understand what happened and how this will be handled better in the future.

[msykes]

It would also be worth pointing out that for some updating the pem file might not be enough.

The old URLs are also not working anymore.

Changing the pem certificate seems to fix the problem on a sandbox, but not on a live/production account if you're using the old URL:

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

Changing to that to the new url as indicated in the akami FAQ will set things right. In my case, we can't just update the SDK due to minimum PHP versions, so the old URL lingered.

However, according to the official FAQ on the new Akami urls this wasn't a required change, which is why we didn't. Looks like now it is... without warning!?