Disabling TLS 1.0 breaks DPM Integration - works fine w/ TLS 1 enabled

[choffm12]

Ever since taking measures to increase PCI security (namely, disabling TLS v 1.0), Authorize.net seems to be unable to post data back to my website. 

The message the customer recives, on AuthNet's gateway/transact.dll page, is

"An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.

      This transaction has been approved.

It is advisable for you to contact the merchant to verify that you will receive the product or service."

The message I receive via email is 

"Authorize.Net Merchant,

Your script timed out while we were trying to post transaction results to it."

The timeout happens very quickly. 

My x_relay_url is https://domain.com/wc-api/WC_Gateway_Authorize_DPM/. Could the issue be that Authorize.net is unable to post to https://, and therefore I should somehow force http:// on the x_relay_url? Then why would it work with TLS 1 enabled, and not when disabled? 

This is a very frustrating issue since the only solutions I have seen online (and on this board) was for the merchant to find another payment gateway altogether. Thanks in advance for any insight. 

[RaynorC1emen7]

http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Authorize-Net-begins-TL...

does your server support TLS 1.1 or 1.2?

[choffm12]

Yes, it supports both of them. Thanks for the response though!

[jgoebel]

Do you know for sure which version of TLS authorize.net is trying to connect to your server with? I no longer use authorize.net and DPM partly because of this issue so I can't test it, but last time I checked authorize.net connected to my server using TLS 1.0.

Authorize.net is currently using TLS 1.0 for silent posts, so I wouldn't be surprised if they are still using TLS 1.0 for DPM.

If you use apache:

CustomLog  /ssl_request_log_path/ssl_request_log.txt  "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%{SSL_VERSION_LIBRARY}x\" \"%{SSL_TLS_SNI}x\" \"%r\" %b \"%{User-agent}i\""

If LogLevel is warn or more verbose ssl_request_log.txt will show the TLS version authorize.net is actually using.

[ptmclellan]

Same thing here!  PCI Compliance dictated that we disable TLS 1.0 -- we did this last night and were getting all of the same errors from AuthNet.

Any fix on this?

[RichardH]

Hello @ptmclellan

What operating system and web server are you using?

Richard

[ptmclellan]

Windows server 2008, ColdFusion 10 -- it is for www.elightbulbs.com

[ptmclellan]

Specifically, ColdFusion 10,292620

Java 1.7.0_51  

[ptmclellan]

Also, we do have TLS 1.2 enabled and working seamlessly for all of our online credit card transactions.  So, it appears that DPM is ONLY using TLS 1.0, so disabling it crashes everything -- is this true?

[briandancer]

I noticed this post regarding the TLS 1.0 PCI issue: 

Authorize.Net begins TLS 1.0 Remediation for PCI DSS compliance

IIn that article, you point out that Authorize.Net will be disabling TLS 1.0 encryption before the June 30, 2016 deadline.   What is a good place to see the progress of this project?  I am now caught in a non-compliant state, and would love to be aware of this getting fixed.

I didn't see any further information on that thread, so I assume simply following a thread about the topic won't be enough to find the status?  

Thanks for any help you can provide!