We received the following email from Authorize.Net and we're not sure what to do about it. Any ideas?
Dear Authorize.Net Merchant:
During a system scan, we noticed that your website or payment solution is using the HTTP GET method when submitting your transaction requests to https://secure.authorize.net/gateway/transact.dll.
Because HTTP GET methods do not adhere to current TLS protection requirements, Authorize.Net will not allow HTTP GET methods for transaction requests as of June 30, 2016. We recommend that you immediately update your code to use the HTTP POST method instead.
Any transaction request submitted using HTTP GET after June 30th will be rejected.
Thanks,
Roger
prefered method is post...this seems like a bug...
report to bugtracker
http://forum.cs-cart.com/tracker/project-1-cs-cart/
I have checked the code of the AuthorizeNet payment method integration. POST method is used there. So you should not worry about that
If 1 of my stores is still running on CS-CART: version 2.0.15, will the store still able to charge with authorize.net after June 30, 2016 ? If not, what's the lowest version required to meet authorize.net? Please advice. Thanks.
If 1 of my stores is still running on CS-CART: version 2.0.15, will the store still able to charge with authorize.net after June 30, 2016 ? If not, what's the lowest version required to meet authorize.net? Please advice. Thanks.
As far as I can see from the code, there is POST requests used everywhere on Authorize.net payment integration. So, it should work after security changes.
If 1 of my stores are still running CS-CART 2.0.15, will the store still be able to charge using Authorize.net when TLS 1.0, 1.1 disabled?
https://support.authorize.net/authkb/index?page=content&id=A1623
If not, what's the lowest version required to meet authorize.net? Please advice. Thanks.
This is mostly related to the certificate "bundle" (CA bundle) on the server. I.e. SSL/TLS ciphers are not part of cs-cart but are part of your server environment.
Many older cart versions don't run on current versions of PHP and hence the environment sometimes ends up frozen (Apache, PHP, LINUX version, etc.)
Suggest you contact your hosting and have them ensure that they have the current "CA Bundle" installed on your server for CURL and then disable the SSL and TLS 1.0/1.1 ciphers. Cut/paste this message and they will know what it means.
Thank you for your reply, tbirnseth. If the SSL certificate from Starfield Technology (GoDaddy) was recently installed by myself within 1 year, would it mean it will work? Or, only hosting company knows.
A "certificate" is only a key used in the process. The underlying CA Bundle (certificate authority bundle) is what determines where that certificate is used and what cipher to use to handle the encryption. It is the CA Bundle that is part of your server infrastructure that probably needs to be updated. There are probably 2. 1 for the system and one for CURL. Installing the latest version of CURL will probably take care of that side which is what's used from cs-cart. But your https will use the server's CA Bundle.
And yes, it is all intentionally confusing! :-)
A "certificate" is only a key used in the process. The underlying CA Bundle (certificate authority bundle) is what determines where that certificate is used and what cipher to use to handle the encryption. It is the CA Bundle that is part of your server infrastructure that probably needs to be updated. There are probably 2. 1 for the system and one for CURL. Installing the latest version of CURL will probably take care of that side which is what's used from cs-cart. But your https will use the server's CA Bundle.
And yes, it is all intentionally confusing! :-)
When I install the SSL, I also installed the provided CA Bundle SSL certificate. So, I assumed it is update to date?!
Not necessarily. As stated above, CURL has it's own CA Bundle that is separate from what you may have added to the system.
Ensure that you are running a version of CURL that has been released in the last year or so and you will probably be fine.
As you may be aware, new PCI DSS requirements state that all payment systems must disable earlier versions of TLS protocols. These older protocols, TLS 1.0 and TLS 1.1, are highly vulnerable to security breaches and will be disabled by Authorize.Net on February 28, 2018.
To help you identify if you’re using one of the older TLS protocols, Authorize.Net will temporarily disable those connections for a few hours on January 30, 2018 and then again on February 8, 2018.
Please refer to our TLS FAQs for important details.
Based on the API connection you are using, on either one of these two days you will not be able to process transactions for a short period of time. If you don’t know which API you’re using, your solution provider or development partner might be a good resource to help identify it. This disablement will occur on one of the following dates and time:
· Akamai-enabled API connections will occur on January 30, 2018 between 9:00 AM and 1:00 PM Pacific time.
· All other API connections will occur on February 8, 2018 between 11:00 AM and 1:00 PM Pacific time.
Merchants using TLS 1.2 by these dates will not be affected by the temporary disablement. We strongly recommend that connections still using TLS 1.0 or TLS 1.1 be updated as soon as possible to the stronger TLS 1.2 protocol. If your current Virtual Point of Sale (VPOS) is an Authorize.Net product, please call Authorize.Net Customer Support at 1.877.447.3938 for assistance in updating to TLS 1.2.
My store is still running CS-CART 2.2.5, how do I know what API connection was using?
I checked https://www.ssllabs.com/and the domain supported TLS 1.2.
How would I know if my store can take payment when TLS 1.0 and 1.1 were disabled?
Please advise. Thank you in advance.
Have you hosting update you curl package on your server. This is a server issue, not an application issue.
For example, use the following service to check if 1.2 version is supported by your server
http://ssl-checker.online-domain-tools.com/
Have you hosting update you curl package on your server. This is a server issue, not an application issue.
The hosting said I do not need to worry about it. I just do not understand why Authorize.net sent me a warning email.
Because they are dropping support for the older cyphers and want to make sure they have no liability if your site suddenly stops being able to process credit cards.