topic Re: Confused about updating to the new SLL Certificates in Integration and Testing

Confused about updating to the new SLL Certificates

Talentville — Fri, 27 Sep 2024 14:08:30 GMT

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?

Re: Confused about updating to the new SLL Certificates

jmorrison — Fri, 27 Sep 2024 16:33:23 GMT

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?

Re: Confused about updating to the new SLL Certificates

Talentville — Fri, 27 Sep 2024 16:40:54 GMT

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.

Re: Confused about updating to the new SLL Certificates

jmorrison — Fri, 27 Sep 2024 16:48:58 GMT

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.

Re: Confused about updating to the new SLL Certificates

mvs3d — Fri, 27 Sep 2024 22:05:08 GMT

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?

Re: Confused about updating to the new SLL Certificates

Talentville — Sat, 28 Sep 2024 13:14:50 GMT

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.

Re: Confused about updating to the new SLL Certificates

zgoldberg — Tue, 01 Oct 2024 17:45:11 GMT

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?

Re: Confused about updating to the new SLL Certificates

kroegerr — Wed, 09 Oct 2024 19:39:47 GMT

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

Re: Confused about updating to the new SLL Certificates

Talentville — Wed, 09 Oct 2024 20:14:40 GMT

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.

Re: Confused about updating to the new SLL Certificates

zgoldberg — Thu, 10 Oct 2024 15:27:04 GMT

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.

Re: Confused about updating to the new SLL Certificates

Talentville — Thu, 10 Oct 2024 15:47:34 GMT

I am not trying to necessarily knock AuthNet (used it for a decade), but consider the following:

I will no longer need quarterly PCI tests, which are invasive and filled with false positives. That killed a week of my time every 90 days.
After cancelling my AuthNet, I called to cancel my processor, Evo Payments, and it seems I am in a contract for 2 more months, so I have to keep paying those thieves even as I do not use their service any more. Good riddance to all of them.
I can now get rid of my entire custom-coded checkout system, as well as XML formatting and calling the AuthNet API, with their fairly substandard error messages when things go wrong. I no longer handle any card info at all since that is done in the Stripe form.
I can now accept a wide variety of alternate payment types, from Amazon pay to Cash App and others. Gives more flexibility with zero coding.

Implementing Stripe was easy with a bit of chat support and their embedded form (I like that instead of switching to the Stripe site for the payment). Their form looks fine and lists the items, sends a nice receipt to the customers, etc. Smooth 3 day integration, start to finish. Products/Memberships (anything you sell) will have to be either manually added to their system or done via the API, but if you have loads of products, and you have their software installed (done via composer for the most part), a programmatic loop to create products and associated prices is a simple task.

We all have to make our own decisions on payment processors, I just finally decided an all in one setup, with a drop-in form for card info, would simplify everything. So far it feels like a move years too late.

Re: Confused about updating to the new SLL Certificates

jmorrison — Fri, 11 Oct 2024 13:40:47 GMT

Their support was not super helpful, and couldn't tell me specifically what certs to install. However, looking more closely at their article, Where can I find the latest version of Authorize.nets server-level SSL certificates?, I found an Attachments section at the very bottom of the page where you can download a zip file with certificates. It's easy to miss because there is extra whitespace between the last set of instructions and the attachments section.

Re: Confused about updating to the new SLL Certificates

warmantus — Mon, 21 Oct 2024 19:45:28 GMT

Hi everyone. I figured out what needed to be done. I accomplished it by using ChatGPT & SSH and here are the steps (hope this can help some of you):

i want to try with ssh. do i need to be logged in with special privelages?
ChatGPT said:
ChatGPT
Yes, to manually add the Root and Intermediate certificates to your server’s trusted certificate store via SSH, you will need to log in with root or superuser (sudo) privileges. This is necessary because the certificate files you’ll be modifying are located in system directories that require administrative permissions to access and modify.

Steps to Proceed with SSH:
Log in to your server via SSH:

Use a terminal (on Linux/Mac) or an SSH client (like PuTTY on Windows).
The login command should look something like this:
css
Copy code
ssh root@your-server-ip
If you're using a non-root user, but that user has sudo privileges, log in with that user and prefix commands with sudo.
Locate the Trusted Certificates Directory:

On many Linux-based systems, the CA certificate directory is typically:
/etc/ssl/certs/ (for trusted certificates)
Or /usr/share/ca-certificates/ (for adding new certificate authorities)
Copy the CRT files to the Trusted Directory:

You can use the scp command to copy the certificates from your local machine to the server, or you can use an editor like nano to manually create the certificate files in the trusted directory.
Example (if using scp):

perl
Copy code
scp /path/to/your/Intermediate.crt root@your-server-ip:/etc/ssl/certs/
scp /path/to/your/Root.crt root@your-server-ip:/etc/ssl/certs/
Update the CA Certificates:

If you're using a Debian-based system (like Ubuntu), you can run:
sql
Copy code
sudo update-ca-certificates
For Red Hat/CentOS-based systems, use:
sql
Copy code
sudo update-ca-trust
This will refresh the system's trusted certificate store, adding the new Root and Intermediate certificates you just copied.

Verify:

After updating the certificate store, you can verify that your server trusts the new certificates by testing the API connection to Authorize.net in the Sandbox environment.
Important Notes:
Make sure you are logged in with root or a user with sudo privileges.
Be careful when working with system files to avoid accidentally removing or misconfiguring important system components.
Let me know if you need any more detailed instructions!

You said:
I am using Terminal from WHM and the first thing I see is: [root@ded6177 ~]#
ChatGPT said:
ChatGPT
Since you're already logged in as root in your WHM terminal ([root@ded6177 ~]#), you have the necessary privileges to proceed with the certificate installation. Here’s how to manually add the Root and Intermediate certificates to your trusted certificate store:

Steps to Manually Add the Certificates
Create the Certificate Files:

You'll need to create two files in the appropriate directory to store the Root and Intermediate certificates. We’ll place them in /etc/ssl/certs/ for this example.
You can use a text editor like nano to create these files.

To create the Intermediate certificate file:

bash
Copy code
nano /etc/ssl/certs/Intermediate-DigiCert.crt
Paste the entire content of the Intermediate DigiCert Certificate (CRT) into the file.
Save the file by pressing CTRL + X, then press Y and Enter.
To create the Root certificate file:

bash
Copy code
nano /etc/ssl/certs/Root-DigiCert.crt
Paste the entire content of the Root DigiCert Certificate (CRT) into this file.
Save the file in the same way.
Update the CA Certificates:

Now that you’ve added the Root and Intermediate certificates to the directory, you need to update the CA store to recognize them.
Run the following command depending on your Linux distribution:

For Debian/Ubuntu based systems:

bash
Copy code
update-ca-certificates
For Red Hat/CentOS based systems:

bash
Copy code
update-ca-trust
Verify the Installation:

After running the command, the system should now trust the newly added certificates. You can test the connection to Authorize.net's sandbox environment or the production environment after the update.
Summary:
You’re already logged in as root, so you have the required permissions.
Create and paste the contents of the Root and Intermediate certificates in /etc/ssl/certs/.
Run update-ca-certificates (or update-ca-trust for CentOS/Red Hat).
Let me know how it goes or if you run into any issues!

You said:
Authorize.net's sandbox environment isn't ready for a couple of days but in the meantime is there a way to verify that the certificates I added are in my server?
ChatGPT said:
ChatGPT
Yes, you can verify that the certificates were successfully added to your server by checking the contents of the directory where you placed them or by using specific commands to list the trusted certificates. Here’s how you can do both:

1. Check the Certificate Files Directly
You can check if the Root and Intermediate certificate files are present in the /etc/ssl/certs/ directory:

bash
Copy code
ls -l /etc/ssl/certs/
Look for the files you created (Intermediate-DigiCert.crt and Root-DigiCert.crt). If they appear in the list, then they were successfully created.

2. Display the Contents of the Certificate Files
You can also view the contents of the certificate files to ensure that they contain the correct data:

bash
Copy code
cat /etc/ssl/certs/Intermediate-DigiCert.crt
bash
Copy code
cat /etc/ssl/certs/Root-DigiCert.crt
This will display the contents of each file in the terminal. Ensure that the text matches the CRT files you received from Authorize.net.

3. Use the openssl Command
You can use the openssl command to verify that your server recognizes the certificates. Here's how to check if the certificates are part of the trusted store:

To check the Intermediate certificate:
bash
Copy code
openssl x509 -in /etc/ssl/certs/Intermediate-DigiCert.crt -text -noout
To check the Root certificate:
bash
Copy code
openssl x509 -in /etc/ssl/certs/Root-DigiCert.crt -text -noout
These commands will display detailed information about the certificates, including their validity and issuer details. If the commands execute without errors, your server recognizes these certificates.

Summary
Use ls -l to list the files in /etc/ssl/certs/.
Use cat to view the contents of the certificates.
Use openssl to inspect the certificates further.
Let me know if you need help with any of these steps or if you have further questions!

Re: Confused about updating to the new SLL Certificates

warmantus — Mon, 21 Oct 2024 19:48:30 GMT

I finally figured this out with the help of ChatGPT. I am pasting my conversation here. Hope this helps someone out:

Steps to Proceed with SSH:
Log in to your server via SSH:

perl
Copy code
scp /path/to/your/Intermediate.crt root@your-server-ip:/etc/ssl/certs/
scp /path/to/your/Root.crt root@your-server-ip:/etc/ssl/certs/
Update the CA Certificates:

Verify:

Steps to Manually Add the Certificates
Create the Certificate Files:

To create the Intermediate certificate file:

bash
Copy code
nano /etc/ssl/certs/Root-DigiCert.crt
Paste the entire content of the Root DigiCert Certificate (CRT) into this file.
Save the file in the same way.
Update the CA Certificates:

Now that you’ve added the Root and Intermediate certificates to the directory, you need to update the CA store to recognize them.
Run the following command depending on your Linux distribution:

For Debian/Ubuntu based systems:

bash
Copy code
update-ca-certificates
For Red Hat/CentOS based systems:

bash
Copy code
update-ca-trust
Verify the Installation:

1. Check the Certificate Files Directly
You can check if the Root and Intermediate certificate files are present in the /etc/ssl/certs/ directory:

bash
Copy code
ls -l /etc/ssl/certs/
Look for the files you created (Intermediate-DigiCert.crt and Root-DigiCert.crt). If they appear in the list, then they were successfully created.

2. Display the Contents of the Certificate Files
You can also view the contents of the certificate files to ensure that they contain the correct data:

3. Use the openssl Command
You can use the openssl command to verify that your server recognizes the certificates. Here's how to check if the certificates are part of the trusted store:

Re: Confused about updating to the new SLL Certificates

layla — Fri, 03 Oct 2025 06:44:32 GMT

The email is just telling you that Authorize.net will start using DigiCert’s new root and intermediate certificates for their SSL. You don’t need to change your PHP code or the way you call the API. What matters is that your server trusts those new certificates. Usually, this just means making sure your server’s “CA certificates” package is up to date. On Linux, you’d update your system (like apt-get update && apt-get upgrade ca-certificates). And on Windows, you may need to install the new DigiCert root and intermediate files if they aren’t already there. Once your server has the updated certificates, cURL will automatically handle everything, and your payments will keep working without interruption. A root certificate is an X.509 digital certificate at the top of the trust chain. It is regarded as the core of Public Key Infrastructure. An intermediate certificate is a digital certificate that can be issued by a root certificate. It serves as an intermediary between the root certificate and the certificate used by the end user.

Re: Confused about updating to the new SLL Certificates

rosalia — Tue, 28 Oct 2025 12:02:30 GMT

You don’t need to change your PHP or API integration the update is about SSL trust, not your code. Authorize.net is switching to new DigiCert root and intermediate certificates, and your server just needs to trust them. To stay safe, update your system’s CA certificates (for example, run apt-get update && apt-get upgrade ca-certificates on Linux). On Windows, make sure the latest DigiCert roots are installed. Once that’s done, cURL will automatically use the correct certificates, and your payments will continue working smoothly. Hope it helps!