We're seeing this on a GetCustomerProfile call through the .NET SDK as of this morning.
"exceptionMessage": "Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.",
"exceptionType": "System.IO.IOException",
"stackTrace": " at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)\r\n at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count)\r\n at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)\r\n at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)\r\n at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)\r\n at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)\r\n at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)\r\n at System.Net.TlsStream.CallProcessAuthentication(Object state)\r\n at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)\r\n at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)\r\n at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)\r\n at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)\r\n at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)\r\n at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)\r\n at System.Net.ConnectStream.WriteHeaders(Boolean async)",
I just also updated my sdk version, to make sure it was not that.
This was working previous to today without any flaws or issues.
Thanks,
Jarrod Henry
Solved! Go to Solution.
05-01-2017 02:13 PM
We disabled TLS 1.0 and 1.1 in Sandbox, per https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/TLS-1-1-and-1-0-Disabl... -- but the changes didn't finish propagating until this morning.
Could you please confirm that you are set up to handle TLS 1.2 connections, using the ciphers listed on the SSL Labs report for apitest.authorize.net:
https://www.ssllabs.com/ssltest/analyze.html?d=apitest.authorize.net
05-01-2017 02:27 PM
We disabled TLS 1.0 and 1.1 in Sandbox, per https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/TLS-1-1-and-1-0-Disabl... -- but the changes didn't finish propagating until this morning.
Could you please confirm that you are set up to handle TLS 1.2 connections, using the ciphers listed on the SSL Labs report for apitest.authorize.net:
https://www.ssllabs.com/ssltest/analyze.html?d=apitest.authorize.net
05-01-2017 02:27 PM
I'm digging deeper to make certain, but we are using the .NET SDK that authorize.net released earlier, wireshark is showing TLS1.2 connections, and our .NET service is written in .NET 4.5.2, which supports TLS. The azure service we're on is a windows server image, which supports that cipher, as well as windows 10 supporting that cipher.
05-01-2017 02:48 PM
There we go, that was it.
Thanks!
Jarrod
05-01-2017 02:57 PM
Hello, Jarrod -
Would you mind explaining what it was, exactly, that fixed your issue? We're seeing the same thing and I'm curious what resolved your issue.
Thank you -
Gary
05-01-2017 03:57 PM
This is what appears to resolve my connectivity problem, in my code.
Updated the underlying .NET Framework to 4.6.1 (works with 4.5.2, as well) and prior to interacting with the AuthorizeNet service, I tell the ServicePointManager explicitly to use TLS 1.2:
// in code
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;
I gathered from what I read that Framework 4.6.1 would use 1.2 by default, but my solution would not work until I explicitly called out TLS 1.2 prior to attempting connection. In 4.5.2, 1.2 is supported but you must config ServicePointManager to use this version over others.
05-02-2017 03:58 AM
This solved my issue, thank you kindly!
05-02-2017 11:40 AM
Perfect!!! We are in the middle of testing a new application and it failed yesterday when I submitted a transaction. Thankfully, I was able to track it back to a communication error when I got the error "Authentication failed because the remote party has closed the transport stream." I then added the line of code noted above (my Application is .NET 4.5) and it set the default to TLS 1.2.
My next transaction went through without a hitch.
Thanks for the Solution!!
05-03-2017 12:15 PM
07-31-2017 10:44 AM
yeh,
It saved my time too. I was tring to figuring out whats the hell is going on with my code. It took days, then I saw this solutions.
Thank you All............
08-15-2017 11:46 AM