- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Transactions fail since Thursday’s update
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
06-12-2023 04:25 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We need a solution asap!
It would be good if Authorize.net could rollback changes made last week.
06-12-2023 05:47 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
06-13-2023 01:45 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
TLS 1.2 upgrade did not resolve anything on its own.
06-13-2023 03:08 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
06-13-2023 05:08 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
06-13-2023 06:21 AM - edited 06-13-2023 06:24 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
06-13-2023 10:03 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
facing same issues. but not found solution yet
06-14-2023 02:18 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
06-14-2023 03:13 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
06-15-2023 02:28 AM

