Authorize.Net Begins Infrastructure and SHA-2 Certificate Upgrades

by Administrator Administrator on ‎03-23-2015 09:00 AM (134,590 Views)

Authorize.Net is upgrading our infrastructure to enhance system performance and security. The changes will be made to our sandbox environment first with updates to production following at a date still to be determined.

 

Our IP addresses will change to become dynamic rather than limited to a small range of static IPs. If your solution uses a firewall to filter outbound connections, we encourage you to make sure that the firewall is set to allow connections by domain rather than IP address. Direct connections via IP address are strongly discouraged and will soon be disallowed.

 

The infrastructure upgrades to the sandbox will begin on Tuesday, March 31st. The date for production is TBD, and we will post another announcement once that date is finalized.

 

To ensure your solution works with the infrastructure changes, please validate the following:

 

  • Your certificate store includes certificates for Root 2 - GeoTrust Global CA
  • Your security transport—the part that negotiates TLS—supports SHA-256
  • Your solution does not connect directly to Authorize.Net using an IP address
  • Your solution’s firewall is not set to whitelist Authorize.Net IP addresses for outbound connections

Security Certificate Upgrades

 

The security certificates used by Authorize.Net for our sandbox and production payment gateway are currently signed using Security Hash Algorithm 1 (SHA-1). Along with the above changes, we will also update our certificates so that they are signed using Security Hash Algorithm 2 (SHA-2).

 

The upgrade to SHA-2 conforms to a change among server and browser manufacturers to deprecate use of SHA-1:

 

  • Microsoft announced in late 2013 that they would no longer accept SHA-1 signed certificates which expire after January 1, 2017:
  • In September 2014 Google announced that the Chrome browser would gradually depreciate SHA-1 support, and would also reject SHA-1 signed certificates which expire after January 1, 2017. In addition, SHA-1 signed certificates which expire in 2016 would be flagged as secure but with errors.
  • Also in September 2014, Mozilla announced that they would also reject SHA-1 signed certificates that expire after January 1, 2017. Mozilla is the basis of a family of browsers, the most well-known being Mozilla Firefox.

While most modern operating systems and web servers support SHA-2, there is a concern that older software—especially software based on outdated versions of Java—may not adequately support SHA-2.  We are upgrading our sandbox environment first so developers can validate that their solutions will continue to work using SHA-2 signed certificates, prior to making the same changes to the production environment.

 

After the update is complete, any software which cannot validate an SHA-2 signed certificate will fail to connect to Authorize.Net servers.

 

Richard

Authorize.Net Developer Community Manager

 

Comments
by magalh
on ‎03-31-2015 03:43 PM

All the connections to sandbox has stopped working for me.

 

if i try to debug the response, i get:

AuthorizeNetARB_Response Object ( [xml] => [response] => )

 

Live account works.

Since i'm not getting any responses from the request, should i assume the upgrade is still going on?

by hsujj
on ‎03-31-2015 05:23 PM

My sandbox account failed too at 4pm March 31, 2015 for the website hosted in Amazon AWS EBS environment. 

Is Amazon using SHA-2 in EBS ?  Amazon cloud hosting shall have taken care of certificates and SHA-2, haven't it ?

When is the upgrade on March 31, 2015 supposed to start funciton correctly ?  

Is the failure due to my setup ?

 

 

 

by preeti2002
on ‎03-31-2015 05:54 PM

All credit card processed via my sandbox account fail as of 1pm March 31, 2015. My website is also hosted on Amazon AWS environment. 

 

I tried to open a new sandbox account and received the following error message on my machine "peer's certificate issuer is not recognized". I check my updates on my windows 7 machine and have the latest updates which include the SHA2 hash algorithm. 

 

Not sure how to proceed

by magalh
‎03-31-2015 05:56 PM - edited ‎03-31-2015 05:57 PM
AuthorizeNetAIM_Response Object ( [_response_array:AuthorizeNetAIM_Response:private] => Array ( ) [approved] => [declined] => [error] => 1 [held] => [response_code] => [response_subcode] => [response_reason_code] => [response_reason_text] => [authorization_code] => [avs_response] => [transaction_id] => [invoice_number] => [description] => [amount] => [method] => [transaction_type] => [customer_id] => [first_name] => [last_name] => [company] => [address] => [city] => [state] => [zip_code] => [country] => [phone] => [fax] => [email_address] => [ship_to_first_name] => [ship_to_last_name] => [ship_to_company] => [ship_to_address] => [ship_to_city] => [ship_to_state] => [ship_to_zip_code] => [ship_to_country] => [tax] => [duty] => [freight] => [tax_exempt] => [purchase_order_number] => [md5_hash] => [card_code_response] => [cavv_response] => [account_number] => [card_type] => [split_tender_id] => [requested_amount] => [balance_on_card] => [response] => [error_message] => Error connecting to AuthorizeNet )

 

by magalh
on ‎03-31-2015 10:55 PM

I'm getting the Error connecting to AuthorizeNet issue since this afternoon (Sandbox only). I think the problem is in the SDK - PHP as i'm able to connect with Curl. Anyone else with a similar issue?

by magalh
on ‎03-31-2015 11:22 PM

SOLVED:

the update must have conflicted with the Curl request in the php SDK (3.1.2)

I updated the file with the code below and all went back to normal.

 

anet_php_sdk -> lib -> shared -> AuthorizeNetRequest.php

 

curl_setopt($curl_request, CURLOPT_POSTFIELDS, $this->_post_string);
curl_setopt($curl_request, CURLOPT_HEADER, 0);
curl_setopt($curl_request, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($curl_request, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($request, CURLOPT_SSL_VERIFYPEER, FALSE);

 

I'm posting this so other people wouldn't waste half their day as i did.

Good luck

by jjz03931
on ‎04-01-2015 08:14 AM

I didn't want to disable CURLOPT_SSL_VERIFYPEER since I imagine it has some security implications. I decided to dig more and found an alternative solution (http://stackoverflow.com/questions/18971983/curl-requires-curlopt-ssl-verifypeer-false) . I replaced the default cert.pem that is shipped with the SDK (not sure if it's been updated on the newest SDK or not). I downloaded my SDK a long time ago as i'm sure everyone else did too.

 

Go to http://curl.haxx.se/ca/cacert.pem, save the cURL cert to auth_net_directory/lib/ssl/cert.pem (replacing the existing one). That should fix the issue without having to disable CURLOPT_SSL_VERIFYPEER

 

You can see where it's pulling in that default item in the auth_net_directory/lib/shared/AuthorizeNetRequest.php

if ($this->VERIFY_PEER) {
  curl_setopt($curl_request, CURLOPT_CAINFO, dirname(dirname(__FILE__)) . '/ssl/cert.pem'); //HERE IT PULLS THE DEFAULT SHIPPED BY THE SDK
} else {
  if ($this->_log_file) {
    file_put_contents($this->_log_file, "----Request----\nInvalid SSL option\n", FILE_APPEND);
  }
  return false;
}

 

by rich722
on ‎04-01-2015 01:47 PM

I think I am having the same problem as noted above, but I don't know where the auth_net_directory is.

 

I too was using the sandbox (AIM module, test mode, with test cc numbers, using osCommerce) successfully on March 30, and it stopped working on March 31.   I was advised to check with my host (InMotion) to see if it was a configuration issue on their end, and I supplied them with the link to the details.   They looked into it, and responded that everything was okay on their end, and to check with the supplier of the relevant osCommerce module.  I haven't gotten that yet, but thought maybe the above comments might be applicable to my case.  If so, I need a little more help on changing the cURL cert.

 

Thanks

by mwickham
on ‎04-01-2015 04:28 PM

@jjz03931 your solution and link to the SO article appears to have solved the issues I was having in our live environment.  Thank you very much for the post.

by Moderator Moderator
on ‎04-01-2015 04:50 PM

For those of you who are depending on the included pem file isntead of the default curl certificate bundle, we have updated this file in our github repostitory here. As jjz said, this goes in the SSL folder of our PHP SDK.

 

In regards to the osCommerce module, it's possible that it is doing something similar, but it's impossible for us to know which file needs to be updated. The module developer should be able to provide update instructions if necessary.

by sharplogician
on ‎04-02-2015 02:17 PM

Thanks Trevor. Downloading and replacing the certificate file in my sdk worked for me.

 

For anyone who needs this file, go to the github php sdk, and download that. Then inside the lib/ssl folder, copy the cert.pem file and replace your existing pem file. That should take care of the error.

by KiranK
on ‎04-03-2015 02:48 AM

Thanks jjz03931 , your solution worked for me. You saved my time.

by towtimes
on ‎04-03-2015 08:19 AM

OK have the same problem my sandbox testing just stopped yesterday. I am using a godaddy host and ssl. No clue how to change anything. I checked sslwizard.co and my SSL matches what Authorize.net needs to work. I'm willing to change files I just need to know where they are and what to change them to.  Pem? curl? sorry but I have clue what that is. Please help

Thank you

by Moderator Moderator
on ‎04-03-2015 11:31 AM

Hi towtimes,

 

We have not made any changes since 03/31. So if you are seeing that it stopped working yesterday I dont' have anywhere to point you. If you are getting any kind of error message, you can start a new thread in our integration and testing board to see if we can help you.

by akenney
on ‎04-03-2015 11:33 AM

Do you all have any update on if this maintenance is complete and if this solves the SSL CA issue on Ubuntu?

by Developer Developer
on ‎04-03-2015 01:59 PM

Upgrade is complete on our sandbox environment.

by travisph
‎04-07-2015 03:01 PM - edited ‎04-07-2015 03:06 PM

Thank you for posting a fix magalh. I'm not totally happy with this solution however, as we're basically telling curl "just ignore the cert". Has anyone figured out what's wrong with the php curl library yet? Still, much better than broken websites. Thanks  Edit: Nevermind, noticed jjz03931 post above.  That's got it.

by starweb
on ‎04-08-2015 06:45 PM

 Hello.  My testing has quit as well.  After an entire day of making sure my app server has all the certs, etc I finally found the source of the problem.

 

I'm trying to connect to the API endpoint of https://apitest.authorize.net/xml/v1/request.api

However, the SSL cert for that site is set for test.authorize.net and my application server returns the following once I wrote a test file to track this down.

 

I/O Exception: Name in certificate `test.authorize.net' does not match host name `apitest.authorize.net'

 

Can you guys help us out and put a certificate that is for apitest.authorize.net or provide an endpoint under test.authorize.net?

 

 

by Administrator Administrator
on ‎04-09-2015 10:04 AM

If you have further issues connecting to the sandbox, please add them to the integration forum.  http://community.developer.authorize.net/t5/Integration-and-Testing/bd-p/Integration01