SSRS 2008- Underlying connection was closed â could not establish trust relationship for SSL/TLS
Everything is on my local laptop. No issues with Web page URL etc (using fully qualified name). After connecting to SSRS thru SSMS, right-click on Jobs/Security/Shared Schedules, will get the error below. How to fix this? (already tried some solutions posted). Thanks for the help.
April 16th, 2012 8:26am
Hi Dennis, From your description, the issue may be caused by the Secure Sockets Layer (SSL) certificate is installed on the report server. If the SSL Identity is not a necessity, you can remove the SSL Identity from the Reporting Services Configuration Manager. Otherwise, to narrow down the root cause, I suggest you help to clarify: Can you access the Report Server and Report Manager through the SSL Identity URLs properly? Navigate to <Drive>:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer folder, open the RSReportserver.config file and check the value of the SecureConnectionLevel key.In the Reporting Services Configuration Manager, click the Web Service URL tab, click Advanced, and then please elaborate how the SSL Identities are configured. If possible, I suggest that you post a screenshot of the window. In addition, I also suggest that you remove the current SSL Identities from Reporting Services Configuration Manager, create a Self-Signed Certificate in Internet Information Services (IIS), and then check the issue using the new certificate. For the details, please see: Create a Self-Signed Server Certificate in IIS 7 References: URLs in Configuration FilesConfiguring a Report Server for Secure Sockets Layer (SSL) Connections If you have any questions, please feel free to let me know. Regards, Mike Yin
April 17th, 2012 4:50am
Hi Dennis , I have the same issue were you able to find a solution for this .. Thanks, Jack
October 17th, 2012 12:48pm
I too am having the same problem with 2008 R2. Everything works fine in the web browser using the identity URL, but management studio balks. The only cert on the system is a computer cert, deployed via autoenrollment from our CA (Server 2012). Obviously the hostname matches the cert, and the issuing authority is trusted. Of course, changing the secureconnectionlevel setting from 2 to 0 resolves the issue, but it shouldn't even *be* an issue.
November 13th, 2012 4:45pm