I was working with a colleague of mine, and ran into a Reporting Services exception when accessing Report Manager. We were trying to get a wildcard SSL certificate set up on the machine, and ran through all the basic checks in my previous articles, but still threw this error:

ERROR: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. —> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. —> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
— End of inner exception stack trace —
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count)
at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
at System.Threading.ExecutionContext.runTryCode(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.ConnectStream.WriteHeaders(Boolean async)
— End of inner exception stack trace —
at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request)
at Microsoft.ReportingServices.UI.Global.RSWebServiceWrapper.GetWebResponse(WebRequest request)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at Microsoft.SqlServer.ReportingServices2010.ReportingService2010.ListItemTypes()
at Microsoft.SqlServer.ReportingServices2010.RSConnection2010.b__10f()
at Microsoft.SqlServer.ReportingServices2010.RSConnection2010.SoapMethodWrapper`1.ExecuteMethod(Boolean setConnectionProtocol)
at Microsoft.SqlServer.ReportingServices2010.RSConnection2010.SoapMethodWrapper`1.ExecuteMethod()
at Microsoft.SqlServer.ReportingServices2010.RSConnection2010.ListItemTypes()
at Microsoft.ReportingServices.UI.Global.SecureAllAPI()
at Microsoft.ReportingServices.UI.GlobalLinks.Control_Init(Object sender, EventArgs args)
ui!21bc!03/29/2017-16:46:49:: e ERROR: HTTP status code –> 500

The Reporting Services Web Service URL was working, but the Report Manager URL threw up the highlighted error fairly quick after trying to browse to it’s page. We could hit the Reporting Services endpoints without issues (/ReportServer/ReportingServices2010.asmx), so what was the issue?


The issue did not manifest itself as a TLS 1.2 error, but this was exactly what it was. If you take a network trace remotely, you would see that the client is trying to use TLS 1.0, but the server is refusing the connection. I skipped this check and went right into the registry to verify that they had indeed disabled SSL 3.0 and TLS 1.0. After removing the entry to disable SSL 3.0 and TLS 1.0, and rebooting, their Report Manager page came up without issues.

To fully resolve the issue with disabling SSL 3.0 and TLS 1.0, and having Reporting Services work with TLS 1.2, we needed to make sure all of the fixes were applied to the customer’s machine, including the Additional Fixes:


Once that is done, also add the following registry keys for SSRS 2014 and below:



For 2016, refer to my previous post on SSRS 2016 and TLS 1.2.

Reboot the machine and voila, you should have a working Report Server.