In SQL Server Reporting Services (SSRS) native mode, you can use the Transport Layer Security (TLS) protocol to establish encrypted connections to a report server. TLS was previously known as Secure Sockets Layer (SSL). If you have a certificate (.cer) file installed in a local certificate store on the report server, you can bind the certificate to an SSRS URL reservation to support report server connections through an encrypted channel.
For more information about SSRS SharePoint mode, see Reporting Services Report Server (SharePoint mode).
Because Internet Information Services (IIS) also uses TLS, there are significant interoperability issues that you must account for if you run IIS and SSRS on the same computer. For guidance on how to address these issues, review the Interoperability issues with IIS section, later in this article.
You must install a server certificate on your report server in the local store. Client certificates aren't supported.
SSRS doesn't provide functionality for requesting, generating, downloading, or installing a certificate. It's up to you to choose the properties that you specify for the certificate and the certificate authority that you obtain it from. You also decide on the tools and utilities that you use to request and install the certificate.
A few possibilities exist for obtaining a certificate:
# Create a self-signed certificate in the local store. $newCertificate = New-SelfSignedCertificate -CertStoreLocation cert:\LocalMachine\My -DnsName -FriendlyName "" # Convert the report server password to a secure string. $secureStringPassword = ConvertTo-SecureString "" -AsPlainText -Force # Set up a temporary folder if one doesn't exist. $folderPath = "C:\Temp" if (-not (Test-Path -Path $folderPath)) < New-Item -Path $folderPath -ItemType Directory ># Set up a variable for the path of a certificate file. $certificateFilePath = $folderPath, "\certificate-export.pfx" -join "" # Set up a variable for the path of the certificate's store location. $certificateStoreLocation = "cert:\LocalMachine\My\", $newCertificate.Thumbprint -join "" # Export the certificate to the file. Export-PFXCertificate -Cert $certificateStoreLocation -File $certificateFilePath -Password $secureStringPassword # Import the certificate from the file to the trusted root to avoid problems with the certificate not being trusted. Import-PfxCertificate -FilePath $certificateFilePath cert:\LocalMachine\Root -Password $secureStringPassword
The certificate is now available for use in Report Server Configuration Manager.
The presence of IIS on the same computer as SSRS significantly affects TLS connections to a report server:
Reservations for the report server web service URL and web portal URL are configured independently.
To configure a URL that you can use to access the report server, take the following steps:
If you also want to configure access to the web portal through a TLS-encrypted channel, take the following steps:
Certificate bindings are stored in the HTTP.sys repository. A representation of the bindings that you define are stored in the URLReservations section of the RSReportServer.config file.
The settings in the configuration file are only a representation of actual values that are specified elsewhere. Don't modify the values in the configuration file directly.
The configuration settings appear in the file only after you use Report Server Configuration Manager or the Report Server Windows Management Instrumentation (WMI) provider to bind a certificate.
If you configure a binding with a TLS certificate in SSRS and you later want to remove the certificate from the computer, remove the binding from SSRS before you remove the certificate from the computer. Otherwise, it's not possible to remove the binding by using Report Server Configuration Manager or WMI, and you receive an "Invalid parameter" message.
After you remove the certificate from the computer, you can use the HttpCfg.exe tool to remove the binding from the HTTP.sys repository. For more information, see HttpCfg.exe.
TLS bindings are a shared resource in Windows. When you use Report Server Configuration Manager or other tools like IIS Manager to change the bindings, those changes can affect other applications on the same computer.
The best practice is to use the same tool to create and edit the bindings. For example, if you create TLS bindings by using Report Server Configuration Manager, also use Report Server Configuration Manager to manage the lifecycle of the bindings. If you use IIS manager to create bindings, use IIS manager to manage the lifecycle of the bindings.
If you install IIS on your computer before you install SSRS, it's a good practice to review the TLS configuration in IIS before you configure SSRS.