When a Windows XP machine using Internet Explorer 8 tries to connect to our SQL Server Reporting Services on Windows Server 2008 R2, we get "Internet Explorer cannot display the webpage" (see picture below). We get the following errors in the System Log on the Windows Server 2008 R2 box: Source: SChannel, Event: 36874 - An TLS 1.0 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed. Source: SChannel, Event: 36888 - The following fatal alert was generated: 40. The internal error state is 1205. Internet Explorer 9, Firefox 4, Chrome 12 all work fine connecting to the server. On the Windows XP machine, I've tried disabling TLS 1.0 and SSL 3.0, but it doesn't help. I also tried KB968730 with no luck. Is this really a cipher suite mismatch or something else? PICTURE [cross-post from here as recommended by moderator]

Did you possibly use a SHA2 signature certificate for the Web server? Brian

No, everything is SHA1.

Hi, This error can be caused by the fact the SSL server is configured to use AES based cipher suites only and since schannel on XP doesn't support AES, IE will fail to connect. To check if this is really the case, you can use the open source utility SSLScan-Win : it is a command line program that displays the cipher suites supported by a server. You can get the binary from its web site : http://code.google.com/p/sslscan-win/ . In a command prompt, type the following : SSLScan.exe --no-failed sqlreport.domain.com The first part of the output is "Supported Server Cipher(s):" which lists server's cipher suites. Post the list here so we can see if it explains the error you are getting on XP. I hope this will help. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.frMounir IDRASSI IDRIX http://www.idrix.fr

Mounir, thanks for the reply. I ran the report (on two different machines, XP and Win7) and every suite fails. I ran it without the --no-failed just to get something, but it shows all of them failed. However, I connect just fine with no warnings from other machines/browsers. C:\Documents and Settings\me\Desktop\SSLScan-1.8.2-win-r7>sslscan.exe --no-failed sqlreport.domain.com _ ___ ___| |___ ___ __ _ _ __ / __/ __| / __|/ __/ _` | '_ \ \__ \__ \ \__ \ (_| (_| | | | | |___/___/_|___/\___\__,_|_| |_| Version 1.8.2-win http://www.titania.co.uk Copyright Ian Ventura-Whiting 2009 Compiled against OpenSSL 0.9.8m 25 Feb 2010 Testing SSL server sqlreport.domain.com on port 443 Supported Server Cipher(s): Prefered Server Cipher(s): C:\Documents and Settings\me\Desktop\SSLScan-1.8.2-win-r7>

I just ran it against other servers of ours and it returns supported and preferred ciphers.... Hmmmmm. Why doesn't SQL Server Reporting Services return any supported ciphers?

Hi Jayvan, Have you managed to solve your problem? I hae the same problem (Windows 2008 R2 and XP). The strange thing in my case, is that it was working properly, if I had a certificate without Subject Alternative Names. As soon as I installed a certificate with Subject Alternative Names as IIS certificate for SSL, I can not connect any more from XP with IE (it works with Firefox on XP and with all browsers on Win7). Any suggestions would be much appreciated. Regards Milos

I have not resolved this issue yet, so thanks for the post, Milos. I am using a wildcard certificate and the subject alternative name is the wildcard domain but no sub-domains. So the SAM looks like DNS Name=*.domain.com DNS Name=domain.com I called my certificate issuer and they reissued a wildcard cert without any SANs and now it works. Interestingly enough though I don't have this problem with a SharePoint site running on Server 2008 R2 using the same wildcard with a SAN. So is this limited to SQL Server Reporting Services? Milos is your problem with SSRS?