Production Certificate Upgrades begin May 26, 2015

[RichardH]

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.

[ibhgentry]

Has anyone succeeded in getting this working with ColdFuion MX7?

[certparty]

Windows Server 2008 | ColdFusion 9 -- seeraig's fix regarding the Java keystore import worked Friday afternoon but our client's payments started failing again yesterday (getting different errors on all of their forms trying to submit payments-- at least one says declined implying communication exists to the payment gateway). I just got off the phone with AuthNet's support after drilling through to their call center supervisor and he plainly told me no support is available over the phone. Another 3 hours wasted and more to come while our client loses money. 

Right  now, we're trying to track down the error codes from the payment failures in the logs. The guy basically just told me to search their knowledge base once we get them and good luck. 

[certparty]

For anyone wondering, the developers needed to regenerate the Transaction Keys for all events and everything seems to be working. Not sure why that was necessary, but the issue appears to be resolved. Our client was getting different error messages from the previous error message last week:

An error occurred while processing your credit card: Connection Failed. Please try again later!

Yesterday and today, before the keys were regenerated, their 3 sites/webforms were throwing these errors at the failed payment screen:

Site 1:  An error occurred while processing your credit card: (TESTMODE) This transaction cannot be accepted.

Site 2: An error occurred while processing your credit card: This transaction cannot be accepted.

Site 3: Sorry, your credit card was declined because: This transaction has been declined.

[gplough]

I was able to get my server working Win2003 R2 / IIS6

- Made sure all security updates were applied

- Imported all certs noted in this blog (I imported them to both Trusted Root and Third Party Root - basically because I wasn't sure how it worked)

- Applied 2 Hotfixes:

KB Article Number(s): 938397

KB Article Number(s): 968730

- Restarted IIS & the server 3-4 times...

I think that was pretty much it, hopefully this helps someone since auth.net won't help anyone..  this is an absolute joke, along with goolgling solutions to this trust me I googled "authorize.net alternatives"

Customer services had the audacity to tell me that "authorize.net isn't really a technology company" and couldn't help me...  Really?     I might as well call my 12 year old when I have a problem...

[DesignQuote]

This was driving me insane because I only updated the first couple certs - then I read this and went back and added all 5 certs from entrust using the java keystore (finally found the right CF keystore file) and rebooted CF and I can now once again connect to Authnet with CFHTTP - thanks for specifying that you imported multiple certs.

Thanks Alpinesteve

Auth Net Tech Support: An email to all the Auth net customers would have been nice - as opposed to me finding out from my customers that they can't make credit card purchases!

oh in case anyone is wondering: CF 8.0.1 on Redhat Enterprise Linux

[martyacks]

We got our second customer running Windows 2003 running by install all 9 CAs not just the 5 required ones. 

[wmvernon]

Having same issue.  Were you able to get the certs installed and your CC system back up and running again?

[martyacks]

@wmvernon If your message is to me.. yes we are up and running. In our case it seems it was related to WIndows 2003 and getting curent on updates. I think there was an update in 2013 that enabled SHA-2 for WIndows 2013 that was needed. We also applied all 9 CAs (5 required and 4 optional) which seemed to make a difference. At first, we only installed the 5 CAs that were listed as required, but that is all. I think we also added some Entrust certs that were not listed. Good luck.  

[kabutotx]

For those on Coldfusion with Java 1.4, I got mine to work (CF6.1).  To install the Entrust key you can install a new java and use the keytool.exe from it to get past the error message from 1.4 keytool.exe.  I just kept installing the keys listed plus the Entrust G2 and it finally started working.

[johnsmith]

Running with the older PHP SDK here (before the Composer garbage was added).  I updated just the PEM file from GitHub as suggested.  No dice.

Then I disabled peer verification for AIM because no one actually needs it (as per http://cubicspot.blogspot.com/2015/05/ssl-verification-does-not-prevent-mitm.html) and stupid stuff like this fiasco can happen.  Guess what?  It just happened, thus proving the author's point that we don't need nor want MITM defenses on server infrastructure.  Authorize.Net's MITM defense code cost businesses around the world to lose millions of dollars in transactions over the past few days.  There's a class action lawsuit waiting to happen over just one line of code.

$auth = new AuthorizeNetAIM;
$auth->VERIFY_PEER = false;

After disabling verification (after being notified yesterday of the issue), I finally get a connection to the Authorize.Net server but responses for test cards are emitting:

"DECLINED. The configuration with processor is invalid. Call Merchant Service Provider."

Sigh.  I don't know/remember if that's the normal response for the test cards on the live system and I don't have a sandbox mode I can just turn on since card processing is buried in my app and I don't have access to the account.  At this point I just maintain the code to process the cards and log transaction results.  At least now I can once again connect to the host.

A couple of side notes:  The grammar of that DECLINED error message is appalling.  I'm personally fortunate in that this issue is happening during a rare moment of downtime where, if it breaks, it isn't fantastic but isn't horrible either.  A month either side of this timeframe and I'd have people breathing fire down my back (here be dragons and such).  I would wager that the Authorize.Net development team isn't allowed to talk about this issue on the forums because this is the sort of thing that class action lawsuits are made of and anything said here can and will be used in a court of law.  You can announce breakages to your heart's content but if anyone loses money, there will be hell to pay - these forum posts demonstrate at least $15 million in estimated lost revenue...and those are the people coming out of the woodwork.  Assume ten times that much for an extremely conservative estimate of lost revenue.  So, yeah, hell to pay in the form of a class action that might bury Authorize.Net into filing for bankruptcy.  One small line of code is the difference here.