Authorize.net Advanced Integration Method (AIM) TLS 1.2 ?

[phi148]

Hi 

 

I received an email today from Authorize.net that stated the following:

 

Dear Authorize.Net Partner:

As you may be aware, new PCI DSS requirements state that all payment systems must disable early TLS by 2018.

In preparation for this requirement, Authorize.Net plans to disable TLS 1.0 and TLS 1.1 on the following dates:

Sandbox: April 30, 2017
Production: September 18, 2017

We are disabling the sandbox in advance of production to allow you and your merchants time to test your solutions and ensure you are no longer using TLS 1.0 or 1.1.

Please check the code for your solutions and systems to confirm that they can default to TLS 1.2 for your API connections.

You can review our API Best Practices for details about TLS 1.2 platform support and other integration suggestions.

Thank you for your attention to this matter and for being an Authorize.Net developer.

Sincerely,

Authorize.Net

 

Does anyone know if this AIM package is TLS 1.2 compliant ??

 

Thanks!

 

[♥frankl]

@@phi148

 

Wouldn't it be your server, rather than the module, that would be TLS1.2 compliant?

[♥flying_kites]

Very good question.

 

First you need to ensure your server supports TLS2.0.  You can test it here https://www.ssllabs.com/ssltest   You are aiming for an A but specifically you want to see that TLS 1.2 is enabled.  So in your results, scroll down to the Configuration section and look for TLS 1.2 set to Yes.  If TLS 1.0 and TLS 1.1 are also enabled contact your hosting company and ask when they plan to disable.  If not disabled you might have issues passing PCI Scans.

 

Second, since authorize.net has disabled TLS 1.0 and TLS 1.1 on their sandbox ( https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/TLS-1-1-and-1-0-Disabled-in-Sandbox-on-April-30-2017-Updated/ba-p/57726)  you can test your specific module by changing to test mode and verifying it still works. If it does not work then I suggest you first update it to the latest version for your specific osCommerce version and retest.  If you still have problems then post the details here: osCommerce Version, Authorize.net AIM version, error details.

[Jack_mcs]

@@phi148 I don't suggest you make any changes at the moment. Authorize.met won't require the use of V 1.2 for another year. The reason they are doing that is because not all browsers will work with the latest version and that will give customers time to update their browsers. If you disable 1.0 and 1.1 now, there will probably be customers that cannot connect.

 

Also, if you run the test @@flying_kites mentioned, which you should, make sure the TLS versions are set to a preferred order, with 1.2 being the preferred one. That will insure the most secure connection for browsers that can use it.

[phi148]

Thanks everyone much appreciated for all the info and feedback!

[♥cannuck1964]

@@phi148 I don't suggest you make any changes at the moment. Authorize.met won't require the use of V 1.2 for another year.

Actually Jack the TLS1.2 requirement will be in 4 months (Sept 18, 2017).

[Jack_mcs]

Yes, that is corrected. I corrected my mistake in another thread about this.

[♥Dan Cole]

I received the following message from Authorized.Net today....does anyone know if the AIM module needs to be updated in anyway?  My site is on a server that has TS1.2 set as the preferred version.

Quote   Dear Authorize.Net Merchant: 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.   Note: If you are not using a current version of a web browser, please take a few moments to upgrade it now. Browsers released prior to 2014 may not support TLS 1.2. You can check your browser's TLS support by visiting https://www.howsmyssl.com/.    If you have any questions about this email or the upcoming TLS disablement, please refer to our TLS FAQs. Thank you for your attention to this matter and for being an Authorize.Net merchant.   Dan

Edited January 25, 2018 by Dan Cole
duplicated content.

[sackling]

Wondering the same thing! 

[kkruit]

This is dependent on your server configuration. Opencart uses curl. Curl uses your server's ssl library. If your OpenSSL (or other server ssl library) is up to date you should be okay. 

See the following stackoverflow:

https://stackoverflow.com/questions/27904854/verify-if-curl-is-using-tls

[Jack_mcs]

Dan - The only thing in the module that would affect that are the url's (there's two if them). On very old modules you may need to change them but not on the newer ones.

[♥Dan Cole]

Thanks Jack...I guess what I should be doing is actually testing it.   I see there are two configuration settings in the module I'm using that allow me to switch between live and test mode....the first one...Transaction Server sounds a bit scary but I'm thinking that the second setting should allow me to preform a test.   I'm not sure but I'm thinking I should give that a shot.  Would you happen to know, if I do that, whether it'll adequately test to determine if I have an issue using the new TLS version.  Will it test against the so called sandbox where the early versions of TLS have be disabled?

Edited January 27, 2018 by Dan Cole
typo

[Jack_mcs]

The module had two url's in it. In some modules they are different and in some they are the same. The Transaction Server setting switches between the two. The Transaction Mode setting controls how the request is handled. In Live mode a charge is attempted. In Test mode, the connection to their server is made and then returns, so it is basically just checking the connection. They have their test server setup to allow only TLS 1.2 connections so if you set the server to Test and the Mode to Test, you should be able to verify it will work. I've never tried the mode Live on the Test server but I assume it goes through the process of charging a card but not actually doing that, though I don't know for sure.

[♥Dan Cole]

@Jack_mcs Thanks Jack and good morning....just a little update.   I put my big boy pants on and gave this a try.   The first thing I did was to set both the Transaction Server and Transaction Mode to 'test' and then placed an order.   That blew up with the following message...

Quote

There has been an error processing your credit card: The API Login ID or Transaction Key is invalid or the account is inactive. Please review your module configuration settings and try again.

I assume from this that you need a separate API Login ID and or Transaction Key to use the Transaction Server in 'test' mode.  The next thing I did was to set the Transaction Server to 'live' and leave the Transaction Mode 'test'.   Placing an order with those settings succeeded but as you mentioned I'm not sure what exactly that does ie.  does it just test the connection or does it actually use their sandbox?  The AIM module I'm using accesses the following URL when in test mode but I don't know whether that lines up with their sandbox url.

Quote

 $api_url = 'https://test.authorize.net/gateway/transact.dll';

I saw that @John W was messing around with this too, having received the same notice, so I'll bark at him to see if he has anything to add.  John...woof, woof.

Dan

[Jack_mcs]

That's the correct test url. See here. This page talks about the sandbox. As far as I know, the credentials for the test server are the same as for the live server.

[♥John W]

I have different credentials for the test server.  I use it on my test site.

@Dan Cole  Bark Bark Bark, Woof Woof Woof.  Now for the rest of the humans.  As long as the module doesn't specify a particular SSL version like some of the older versions of A.net, you should be fine.  The php curl info recomends not setting a specific SSL, which will allow the version A.net chooses.  However, you can put a line in to force TLS 1.2  I know you have TLS 1.2 because you've tested it with Paypal, correct?  I'm still going to run a test transaction and void it during the first time period they specify just to be sure.  Chance favors the prepared.

The people I think will have a problem are on older OS versions of say Redhat or Centos.  I I'm not sure if version 6 supports TLS 1.2 for Redhat or Centos.  I'm running Centos 7.4 64bit.  Softlayer basically forced an upgrade to 64bit in December 2016.

[♥John W]

You can do a test transaction on the live server though, I think there's a setting for it.

[♥Dan Cole]

Thanks @Jack_mcs and @John W.  I feel a little better after reading this post found in one of the links Jack provided.

Quote

The test.authorize.net endpoint currently only supports TLS 1.2, so if you can process successfully with that endpoint, you should be fine once secure2.authorize.net switches to TLS 1.2

Dan

[♥Dan Cole]

1 hour ago, John W said:

I'm still going to run a test transaction and void it during the first time period they specify just to be sure.  Chance favors the prepared.

@John W That is a good idea John.  It's a pretty small window but I think I'll try to do the same, just to play it safe.

Dan

[♥John W]

I was pretty sure I would be fine, but I did my test today and it worked.  Pretty sure I wouldn't have any issues as I support TLS1.2, but better safe.

[♥Dan Cole]

@John WJohn are you using an Akamai-enabled API?   I assumed I was an other API?

Dan

[♥John W]

Yes, I changed the links in my module a couple years ago when the Akamai first started. A.net works really well for me.  Are you using Chase Paymentech for your processor?

[♥John W]

@Dan Cole  Something else I did that you might like, is i changed the error output to come straight from A.net.  Instead of the basic errors in the stock module, I have it use the BS "alert danger" alert box and put the exact error that A.net sends. 

[♥Dan Cole]

@John W  Woof Woof! I guess I'll have to wait until the 8th to test my API but like you I don't expect it to be an issue.

On 1/30/2018 at 3:10 PM, John W said:

Something else I did that you might like, is i changed the error output to come straight from A.net.  Instead of the basic errors in the stock module, I have it use the BS "alert danger" alert box and put the exact error that A.net sends. 

That is interesting John....are you outputting on the page the customer sees? ie a card declined message.  What sort of additional detail does the customer see.  BTW, you posted about re-charging a customers card years ago...at the time I didn't know you could do that and it has turned out to be a real neat feature that we now use a lot.  I've been meaning to thank you for posting that.   Kudos to you. 

On 1/30/2018 at 2:53 PM, John W said:

Are you using Chase Paymentech for your processor?

Yes I've been using them for years.   They are one of the few processors up here that work with Authorize.net and allow me to charge in CAD. 

Dan

Edited February 1, 2018 by Dan Cole
typo

[♥John W]

@Dan Cole The customer sees the same output for the error line you get in the "Authorize.net AIM Debug E-Mail".  So, the third line is " [x_response_reason_text] => The credit card number is invalid.", and I'm just pulling the text.  It's handy sometimes because it gives a better error IMHO.

You're most welcome about the recharge tip, and it is a great feature.