Share via

TF255455: SQL Server Reporting Services is configured to require a secure connection. However, no HTTPS URL is configured with a valid certificate.

  • Article

If you are seeing this error, it means that your Reporting Services instance was set up to require a secure (SSL) connection, but for some reason your configuration does not meet all the requirements for SSL.  Reporting Services will not work correctly until you've ensured you meet all the requirements for SSL (a real, valid certificate; a matching machine name; etc.) or you've reduced your connection security requirements.

 

In the most common scenario, there was for some reason already a (invalid) certificate on the machine that made an SSL assumption when Reporting Services was installed, so it set up HTTPS and set a SecureConnectionLevel of 2.  This can be any certificate in the local store with the purpose set to * (anything) or server authentication.  When TFS detects that SecureConnectionLevel=2, it requires that the user use HTTPS; however, if the certificate doesn't work, HTTPS will fail.  The best way to fix this is to change the Reporting Services config file to set the SecureConnectionLevel to 0 - ie, do not require a secure connection - instead of 2.  The steps are as follows:

  1. Open the rsreportserver.config file, which is usually located in %Program Files% \Microsoft SQL Server\MSRS10. <instancename> \Reporting Services\ReportServer\
  2. Search for the line that reads <Add Key="SecureConnectionLevel" Value="2">
  3. Change it to <Add Key="SecureConnectionLevel" Value="0">, and save the file.
  4. Restart setup.

 

If you did intend to use a certificate but find that it isn't working, please check that the name the certificate applies to exactly matches the name of the server you are trying to connect to.  Note that certificates will not recognize when a local name and fully qualified domain name belong to the same machine, so if you are trying to connect to Reporting Services using the local name, but the certificate knows that machine by its FQDN, .NET will fail the communication.  To avoid this issue, either ensure that the name of the machine you're connecting to always matches the name in the certificate, or add another certificate that applies to the second name.  Another possible issue you could be facing lies in the fact that .NET will fail communication with your server if the certificate you have is self-signed and not trusted.  This is only an issue if your Reporting Services is remote; communication will still work if it is local.  To work around this issue, try using a certificate that is signed by a recognized certificate authority.

 

For more information on SQL's connection security settings, see the official docs here: