Please update code to reflect the Entrust to DigiCert SSL migration
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)
Thanks @defconomicron !
Here is a link to the two KB articles:
- https://support.authorize.net/knowledgebase/Knowledgearticle/?code=000003009
- https://support.authorize.net/knowledgebase/Knowledgearticle/?code=KA-05545
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?
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.
I had the same question where inside the repo or my code do we set the SSL certificate?
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:
- 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)
- 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.
I am guessing we should be good... Our site didn't experience anything catastrophic yesterday or today.