Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please update code to reflect the Entrust to DigiCert SSL migration #194

Open
defconomicron opened this issue Sep 30, 2024 · 5 comments
Open

Comments

@defconomicron
Copy link

defconomicron commented Sep 30, 2024

Authorize.net is updating the SSL/TLS certificates used for secure communication with our systems. This change affects both browser-based and server-to-server interactions.

Who is being affected: Merchants who utilize Authorize.net APIs and endpoint URLs in their websites or applications will need to make updates. They will need to integrate and use the newly-issued Root and Intermediate (CA) SSL certificates from DigiCert. This should be done before the scheduled revocation dates to avoid disruptions.

What you need to do: You must integrate and use the newly-issued Root and Intermediate (CA) SSL certificates from DigiCert by October 24 to avoid any disruptions. To help you fight fraud, AFDS is automatically enabled on your account, which gives you access to many powerful fraud filters, including:

For detailed instructions, please refer to the support articles below:

• Entrust to DigiCert SSL Certificate Migration (KA-05545)

• Latest Version of Authorize.net Server-Level SSL Certificates (000003009)

@defconomicron defconomicron changed the title Please update code to Please update code to reflect the Entrust to DigiCert SSL migration Sep 30, 2024
@pandaiolo
Copy link

Thanks @defconomicron !

Here is a link to the two KB articles:

It is unclear what needs to be done.

For client-side operations, I suspect (hope) nothing, given the connection is direct from customer browsers to authorize.net API (accept.authorize.net IIC)

For server-side API access, which from this repo seems to occur on api2.authorize.net, not sure what shall be updated? Anybody understand the practical steps / code updates? I've never heard of having to specify SSL certs for an API client?

@pandaiolo
Copy link

pandaiolo commented Oct 1, 2024

Some notes/questions about the KB article contents:

If testing is needed, it is recommended to be done in the Sandbox environment as soon as Authorize.net releases the new DigiCert SSL certificates on October 23rd and 24th. Testing in the Production environment won't be possible before the Production release date on October 23rd, 2024.

Does it mean "You will not be able to test this before it happens in production"? 😅

About the scope:

Scenarios Requiring Action:

  • Users whose applications or websites pin the leaf certificate will need to update their settings.
  • Users whose applications or websites use custom trust stores will need to import the DigiCert CAs.
  • Users whose applications or websites pin to the CAs will need to update their pins.

This seems a pretty unusual use case. I feel like any user connecting to Authorize API in a standard way, with a normal HTTP client, will not need to do anything.

@gbs4ever
Copy link

gbs4ever commented Oct 1, 2024

I had the same question where inside the repo or my code do we set the SSL certificate?

@pandaiolo
Copy link

If I get it right, this mainly affects customers who manage their own SSL certs or do Root CA pinning. That's folks who only allow certain pre-approved certificates.

I'm not super familiar with it, but I think this could happen in two ways:

  1. In the project code - like where it connects to the API and checks the server cert against a whitelist (seems unlikely for who uses this repo)
  2. At the org level - if they need to pre-approve certs for all outbound HTTPS connections

Users with this setup need to update their stores/whitelists with the new certs/CA (if/when they are provided).

Those without this setup probably don't need to do anything, but an official confirmation would be nice.

@defconomicron
Copy link
Author

I am guessing we should be good... Our site didn't experience anything catastrophic yesterday or today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants