Transactions fail since Thursday’s update

[Trmessin]

Ever since the Authorize.net update on Thursday night our Merchant account has not worked. Ccard fail with following msg:
Request Aborted. Could not create SSL/TLS Secure Channel

We have a DigiCert RSA certificate running on a Windows 2012 R2 webserver.

The transaction Key has been updated.

When we run the SSLlabs tool for our website we get
# TLS 1.2 (suites in server-preferred order)
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 1024 bits
As the number one entry.

Authorize.net prefers ECDHE with GCM ciphers (only prefers), but we have DHE with GCM – a GMC cipher and the reason for the change by Authorize.net.

Does anyone have ideas about what we should do next?

Tnks

[ariel1234]

I have the same issue. Please if you find an answer from Authorize.net, post it here.
We need a solution asap!
It would be good if Authorize.net could rollback changes made last week.

[jimpare]

Update your SSL/TLS protocols: Ensure that your web server is configured to support TLS 1.2 or higher, as it is the recommended secure protocol. Older versions of SSL and early versions of TLS (such as SSL 3.0, TLS 1.0, and TLS 1.1) have known vulnerabilities and should be disabled.

[Trmessin]

Tnks Jim. Updating to Tls 1.2 was the first step taken last Thursday. All prev versions removed.

TLS 1.2 upgrade did not resolve anything on its own.

[ariel1234]

Trmessin, I think we should upgrade the SO. It seems like Windows Server 2012 R2 doesn't support the ciphers enabled in Authorize.Net API. Upgrading to Windows Server 2022, should work. 

Looking at the ciphers enabled in Authorize.Net API, they have these that should be supported by Win Server 2012 R2:

TLS_RSA_WITH_AES_256_GCM_SHA384 

TLS_RSA_WITH_AES_128_GCM_SHA256 

Have you tried enabled them?

Ariel 

[alutes21]

We're experiencing this exact issue as well. 

We're running IIS Server 2012 R2 and we've confirmed multiple times that we're properly using TLS 1.2 and the 'preferred' cyphers.  We called into Authorize support yesterday morning (6/12) and they were not helpful - would not escalate a ticket or anything.  Only response support would give me was as long as we are using TLS 1.2 with either a GCM or ECDHE Cypher we would be able to connect - otherwise the issue was on us.  We ran the SSL Labs tool on the website and everything checks out to their specs as well. 

Hopefully they roll back changes otherwise we're stuck.  Has anyone had any luck getting live again?

Angela

[alutes21]

We've solved the issue on our end!!

We had to explicitly order our ciphers we wanted used in the 'SSL Cipher Suite Order'.  Once you choose the ones you want to use, you 'enable' the configuration and paste in a comma separated list of ciphers (with no spaces).  Then 'apply', 'ok' then restart the IIS server.  Once our server came back up we tested our authorize connection issue again and we were able to hit the API and get a TLS/SSL handshake and successfully check out.

Here is the microsoft article on how to configure TLS Cipher Suite Order: https://learn.microsoft.com/en-us/windows-server/security/tls/manage-tls

I hope this helps someone else!

Angela

[BamsiByrek]

facing same issues. but not found solution yet

[Trmessin]

Hi Angela,

Thank you for this info. We did arrange the ciphers based on that link last week and it did not resolve.

Are you possibly able to include a screenshot of your cipher order and commas so we can review one more time?

Ssl was upgraded from RSA to ECDHE
We are seeing better test results on sslabs however credit cards still fail.

Any additional info appreciated

-Todd

[Trmessin]

Here is our cipher list as organized in this order below:

If anybody can compare/provide feedback we would very much appreciate it.

Cipher list


TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
SSL_CK_DES_192_EDE3_CBC_WITH_MD5,
SSL_CK_RC4_128_WITH_MD5


Tnks,
Todd