Enable TLS 1.2 protocol for Reporting Services with custom .NET application

 

If you are using any custom application which is integrated with any payment gateway you might be thinking of using a secure protocol while doing the communication between them. You might be thinking about using TLS 1.2 as a protocol to do all the communication. Let us consider a scenario, let us say if you have custom application which has integrated reports from the Reporting Services then in that case you need to make sure that the TLS 1.2 communication is happening between your custom application and Reporting Services as well as between Reporting Services and Report Server databases. You may even need to consider about the Report Data sources communication as well if the hosted SQL instances of the Report Server database and Report databases are different. It could be easily explained with following diagram.

1

 

Reporting Services Related configuration (SERVER 2)

Before we start configuring the changes, I would like to tell you that a couple of months back this wasn’t a supported scenario but right now Reporting Services can communicate with SQL Server using TLS 1.2

1.Install the Windows Patches

Before you install the patch, you need to make sure that the SQL Server TLS 1.2 support updates are already installed.  You can find these updates in the below article.

https://support.microsoft.com/en-us/kb/3135244

After this, based on the operating system that you are on, you need to install the .NET Framework ‘s latest patch.  The download link is present in the below KB article link.

https://support.microsoft.com/en-us/kb/3154520

If you have already installed this patch, you will end-up seeing the below message when you run the installer one more time.

2

 

2.Reporting Services configuration

In your Reporting Services configuration manager, you need to explicitly disable https://:80 and need to keep only https://:443 enabled. You need to do that for both Report Server and Report Manager URLs.

If you notice the below screenshot, you would see that we have only one HTTPS URL, there is no HTTP URL.

3

 

NOTE:  

  • If you are testing this in your lab environment then you can create a self-signed certificate and use it.
  • If it’s a production environment you would have certificate already installed in your environment.
  • But in both the scenarios you need to make sure that certificates are installed in Trusted Root Authority and the certificate needs to be trusted.

 

3. Registry Changes

Once you have installed the above windows patches in the SSRS server, it is now capable of initating a communication over TLS 1.2. But by default, it would always initiate the communication in TLS 1.0 .  Doing the following registry changes will enforce it to use TLS 1.2 only.

Think about a scenario where you have a custom application that was hard-coded to connect using TLS 1.2, it can still connect to SSRS even without these below registry changes. It’s just the connection from SSRS to SQL Server that may still use TLS 1.0. So the below registry changes totally depends on what you exactly need. It is not a mandatory requirement to enable TLS 1.2. But these below registry changes would enable it definitely.

You need to go to the following registry location on the SSRS Server.

3a. Protocol Section

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]

4

and make sure that you are making following changes.

SSL 2.0

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client] "DisabledByDefault"=dword:00000001   "Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]

"DisabledByDefault"=dword:00000001   "Enabled"=dword:00000000

SSL 3.0

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client] "DisabledByDefault"=dword:00000001   "Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]

"DisabledByDefault"=dword:00000001   "Enabled"=dword:00000000

TLS 1.0

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client] "DisabledByDefault"=dword:00000001   "Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]

"DisabledByDefault"=dword:00000001   "Enabled"=dword:00000000

TLS 1.2

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000   "Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]

"DisabledByDefault"=dword:00000000   "Enabled"=dword:00000001

 

NOTE:  

  • Over here if you would notice, we have disabled all the other protocols apart from TLS 1.2 and this is mandatory.
  • You may want to export the existing registry key (backup) before start making the changes.

5

 

3b. .NET Framework Section

Also, you need to make sure that you have the following registry keys added.

For 32 bit:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]

"SystemDefaultTlsVersions"=dword:00000001

For 64 bit:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]

"SystemDefaultTlsVersions"=dword:00000001

 

4. Reboot

Once all these changes are done, you need to restart the machine.

 

 

SQL Server Changes (SERVER 3)

Probably if you think conceptually, you may realise that we don’t need to make any changes in SQL Server side (This is the server where you have hosted your ReportServer and ReportServerTempDB databases are hosted). This is because the communication always gets initiated from the client. But still you should have TLS 1.2 enabled alone apart from other protocols.

  1. To make this registry changes, you need to replicate the same changes what has already been articulated in section

          3a. Protocol Section  under Reporting Services Related configuration (SERVER 2)

  1. You also need to make sure that you are applying the right set of updates on the SQL Server database instance. You can find the reference in this article - https://support.microsoft.com/en-in/kb/3135244
  1. After making all the above changes you need to restart the physical machine.

 

Now let us test the working of the TLS 1.2 communication for the list of changes that we had done so far. Until this point, we have completed the modifications for configuring SSRS and SQL Server for TLS 1.2.  So that means you can do the test and see if the communication is going over TLS 1.2.

You can run a fiddler trace and look into the HTTPS traffic and find TLS 1.2 communication.

6

 

 

Application Level Changes (SERVER 1)

Considering our initial scenario, you have right now configured Reporting Services to accept TLS 1.2 communication. Now we need to make sure that your application is also configured for TLS 1.2

 

1.Windows Level Patch

If your application is not hosted on the same server where Reporting Services has been installed. Then in that case, you need to make sure you are installing the patch https://support.microsoft.com/en-us/kb/3154520on your application server.

 

2.Registry Changes

If your application is not hosted on the same server where Reporting Services has been installed. Then in that case, you need to make the same protocol level registry changes. This has already mentioned in 3a. Protocol Section  under Reporting Services Related configuration (SERVER 2)

 

3.Application Code Changes

If you are calling the Reporting Services from your custom application. Then you need to make sure that in your application you are sending the communication over TLS 1.2

  • Applications that are using ServicePointManager-based APIs can set the protocol using as follows:
    Net.ServicePointManager.SecurityProtocol = SecurityProtocolTypeExtensions.Tls12;
  • Applications that are using the SslStream AuthenticateAsClient(String, X509CertificateCollection, SslProtocols, Boolean)  overload can set the SslProtocols value as  Tls12.

 

You need to include below .CS files in your solution.

SslProtocolsExtensions.cs

----------------------------------------------------------------------------------------------------------

using System;

using System.Collections.Generic;

using System.Linq;

using System.Web;

namespace System.Net

{

using System.Security.Authentication;

public static class SecurityProtocolTypeExtensions

{

public const SecurityProtocolType Tls12 = (SecurityProtocolType)SslProtocolsExtensions.Tls12;

public const SecurityProtocolType Tls11 = (SecurityProtocolType)SslProtocolsExtensions.Tls11;

public const SecurityProtocolType SystemDefault = (SecurityProtocolType)0;

}

}

----------------------------------------------------------------------------------------------------------

 

SecurityProtocolTypeExtensions.cs

----------------------------------------------------------------------------------------------------------

using System;

using System.Collections.Generic;

using System.Linq;

using System.Web;

namespace System.Security.Authentication

{

public static class SslProtocolsExtensions

{

public const SslProtocols Tls12 = (SslProtocols)0x00000C00;

public const SslProtocols Tls11 = (SslProtocols)0x00000300;

}

}

----------------------------------------------------------------------------------------------------------

With this code changes, your application would start initiating the communication over TLS 1.2

 

NOTE:  

  • You can also verify that the communication is over TLS 1.2 by collecting a fiddler trace
  • If your making server level changes and if your application is hosted in a different machine, then you need to reboot the server.

 

FAQ

Q -   Can SSRS still use TLS 1.0?

TLS 1.0 is not deprecated, it’s actually still safe if you patched all security fixes. Let us consider this below scenario.

7

 

If you would have considered the above scenario, the TLS 1.0 won’t work here. The connection between SERVER1 and SERVER2 fails because at the SERVER2, we have disabled all the other protocols apart from TLS 1.2 and the SERVER 1 is still sending the request over TLS 1.0.

 

Q -   Do I definitely need TLS 1.2?

It’s not mandatory, by default client and SQL server communication happens over TLS 1.0. But if you want more secure communication then you can enabled that in client and server.

 

Q – I don’t have any custom application and I want to enable TLS 1.2 protocol for Report Manager and Report Server?

The above action plan is still applicable for the Reporting Services Native mode configuration without any custom application integration. You would need to make the changes that we have specified for SERVER 2 and SERVER 3 in the above section.

 

Q -   Do I need to make “NETFramework\v2.0.50727” registry changes in SQL Server as well?

No, this registry changes is only for the client. So this changes is not required in SQL Server. But in any case if your SQL Server is acting as client and that client would also like to communicate over TLS 1.2. Then you need to install the windows patch mentioned in the above and include these registry changes (under SSRS Server section) along with the “Protocol” section changes.

 

Q-    Can I host application in another server other than SSRS server?

Yes, that’s possible. In that scenario you need to make sure that you are replicating the same changes performed at SSRS Server to have TLS 1.2 in place.

 

Q –   Do we have to change the code if web application and SSRS are hosted on the same server?

Not necessary all the time. If the app doesn’t explicitly set the protocol, and, if the host has set "SystemDefaultTlsVersions"=dword:00000001, then there’s no code change needed.

 

Further References

  1. https://technet.microsoft.com/en-us/library/dn786418(v=ws.11).aspx
  1. https://support.microsoft.com/en-us/kb/3154519
  1. https://support.microsoft.com/en-us/kb/3154520
  1. https://support.microsoft.com/en-us/kb/3135244

 

Author:         Sumit Ghosh – SQL Server BI Developer team, Microsoft

Reviewer:     Krishnakumar Rukmangathan, Support Escalation Engineer, SQL Server BI Developer team, Microsoft