Confused about updating to the new SLL Certificates

[Talentville]

I recently got an email about SSL certificate changes for anyone using the authorize.net API to process transactions. I use a cURL in PHP to call the following endpoint for all my payment processing:

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

I am confused by the whole certificate thing, I just call the endpoint with my merchant credentials in the XML, as far as I know. Do I need to do anything or install something on my server to keep it working? Or am I fine continuing to do what I have been doing?

Excerpt from the email I got: You must integrate and use the newly-issued Root and Intermediate (CA) SSL certificates from DigiCert by October 24 to avoid any disruptions.

I love the vague words "integrate and use". How do I integrate and then how do I use, in PHP and on my server?

[jmorrison]

I too am confused by this.  I've opened a support ticket with Authorize.NET, but they only keep referring me to the same links that were in that email.

In their article, Entrust to DigiCert SSL Certificate Migration, it states, "You can download the latest version of the Root and Intermediate (CA) certificates from the zip file in the Attachments section below."  However, there is no attachments section or links to a zip file.  They also referred me to the article Where can I find the latest version of Authorize.nets server-level SSL certificates?  However, the instructions in here also appear useless.  Navigating to the endpoints to download the certificates only gets the current certificates -- not the new ones they will transition to.  They also have links to DigiCert to download root certificates, but DigiCert lists dozens of certificates on that page and I don't know which one to download.

Does anyone know which certificates we actually need and where to get them?

[Talentville]

My bigger confusion is that right now I don't rely on anything at all other than calling the API endpoint with my merchant credentials in the XML. I just call it and it works, no certificate or anything else.  If I am just calling a URL via cURL, how would this certificate even get used and where would it get 'installed'?  Am I supposed to install it somehow on my own server and then set some callback in the authnet portal?  

What I am getting at is a wonder of what the flow of execution is when I just call the API endpoint with XML passed in, as well as where this certificate would be put and how it would be triggered in my use of the API endpoints.

Perhaps I just have to wait it out and see if it all keeps working, without real guidance from those in the know.

[jmorrison]

When you call the API endpoint, the Auth.Net server sends back a TLS certificate.  This certificate was issued by a trusted third party (DigiCert in this case), and the Auth.Net certificate references back to an intermediate and root certificate from DigiTrust.  Your server must know and trust those other certificates in order to trust the Auth.Net certificate.  If your server doesn't trust the TLS certificate, the connection will likely fail.

Therefore, it sounds like we need to verify that these intermediate and root certificates are installed on our servers so that the new Auth.Net certificate will be trusted.  However, I don't know what intermediate and root certificates to check for or install if they are missing.

[mvs3d]

Hey all,

Are you using the SDK or not? I'm using the PHP SDK, and there is a certificate file called "cert.pem". This file was updated 6 years ago, and I think it should be updated with this change. This file is used in the HttpClient class (look at line 80):

curl_setopt($curl_request, CURLOPT_CAINFO, dirname(dirname(__FILE__)) . '/../../ssl/cert.pem');

I'm using the very old version of this SDK actually, but there is the same code also.

One thing I don't understand at the moment is where we can get a new version of "cert.pem" if it's not updated within GitHub. Maybe you have an idea?

[Talentville]

I actually do not use the official PHP SDK,I use a third party PHP class (which I see in the comments was created 15 years ago!) that uses simple cURL calls with attached XML to call the CIM module (which I use to store my customer info).  There is no reference to any certificate of any sort, purely a basic call that includes my merchant login ID and secret key.  So, even the idea of upgrading a certificate means little to me.

Since I doubt AuthNet will let tons of merchants to suddenly stop being able to take money, I think I am going to have to take my chances, although I may investigate new libraries to be as ready as I can be if suddenly my site cannot accept payments.

These sorts of things make me wonder why I use authorize.net, there are probably other processors who are more modern and who can actually provide developer and merchant support that means something.  It was just so simple previously integrating payments by just building the transaction in XML and calling an endpoint when I first started taking payments at my site.

[zgoldberg]

Commenting just to follow and echo the original poster. I'm pretty confused (and concerned) about what this means on my end. I'm *not* a developer but rather a lowly IT guy who inherited some Authorize.net integrations to both Drupal and Salesforce. We do have a website developer looking into that end, but I'm confused as to what I'm supposed to do in Salesforce. This integration is just custom Apex code that fires callouts to Authorize endpoints and returns transaction lists. Will I need to make any changes to this? 

[kroegerr]

Hi jmorrison,

Would you please tell us if you were able to get an answer on which certs to install on our servers in order to call Auth-Net APIs?  

Like you, I am unsure and do not just want to start installing certicates randomly.  

Randy

[Talentville]

To be honest folks, the whole certificate thing bothered me, so I ripped out AuthNet from my website and migrated to Stripe.  It took 3 days, between understanding it and implementing and a few support chats, which is pretty quick for a custom-coded website, and using their embedded checkout form I am able to avoid AuthNet's monthly charges and the certificate issue and the need to use an XML-based cURL API system.  I don't even need to run a PCI test quarterly any more with Stripe or handle ANY credit card numbers for customers.

Best move I ever made for my website.

I used AuthNet for 12 years, so glad to be getting out from under their thumb.

[zgoldberg]

We're also now considering this exact switch. It just seems like there are other processors that will be smoother. Just trying to figure out how to migrate subscriptions, but I think we will be moving to Stripe as well.