Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Problem: Windows Server 2008 R2 will only support the following ssl cipher suites when using certain certificates on the server:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

This prevents XP clients from connecting to the server since the XP Cryptographic API doesn't support any AES ciphers by default.
As a result, the following errors appear in the server logs when attempting to connect using internet explorer or remote desktop. (since they use microsoft's CAPI)

Schannel Error 36874 "An TLS 1.0 connection was recieved from a remote client application, but dodne of the cipher suites supported by the client are supported by the server. The SSL connection request has failed."
Schannel Error 36888 "The following fatal alert was generated: 40. The internal error state is 1204"

share|improve this question
2  
Gary, if you solved your own question please mark it as answered. –  Bernie White Nov 5 '12 at 8:50

3 Answers 3

If the certificate being used on the server was generated using the Legacy Key option in the certificate request form, the private key for that certificate will be stored in Microsoft's legacy Cryptographic API framework. When the web server tries to process requests using its new, Cryptographic Next Generation (CNG) framework, it appears that something related to the RSA private key stored in the legacy framework is unavailable to the new framework. As a result, the use of the RSA cipher suites is severely limited.

Solution:
Generate the certificate request using the CNG Key template in the custom certificate request wizard.

MMC | Local Computer Certificate Manager | Personal Certificates Folder | (right click) | All Tasks -> Advanced Operations | Create Custom Request | "Proceed without enrollment policy" | select "(no template) CNG key" | proceed to complete the certificate request according to your needs.

Verifying that the key is in the right place:
http://msdn.microsoft.com/en-us/library/bb204778(VS.85).aspx
http://www.jensign.com/KeyPal/index.html

Tools for verifying correct cipher-suites:
http://pentestit.com/2010/05/16/ssltls-audit-audit-web-servers-ssl-ciphers/
https://www.ssllabs.com/

SSL cipher-suite settings:
http://support.microsoft.com/kb/245030
http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order-in-internet-explorer-7-on-windows-vista.aspx

This took us a week to figure out. I hope this saves someone the same trouble.

share|improve this answer
    
Anyone know how to do this - or otherwise solve the issue - for self-signed certificates? –  MGOwen Jun 17 '13 at 7:14
    
Thank you very much Gerry for your work and sharing your results! We opened a Microsoft Support Case and Microsoft itself was not able to find out why certain clients could not connect. We have had the Issue exactly as you described. But according to technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx Microsoft itself recommends using the Legacy Key Template to archive the best compatibility! Great Work! –  user207290 Jan 29 at 8:57

Thanks, your post did help me, although my problem was not exactly the same.

However, the cause was a WINHTTP SERVER API configuration mistake on my part. My IP changed, and when I put a new server certificate into the machine "MY", I ignored the ALREADY_EXISTS return code for HttpSetServiceConfiguration.

So I used a previous server TLS certificate which had the wrong common name and did not match my new server name.

If you don't do HttpDeleteServiceConfiguration() or the command line "netsh http delete sslcert 0.0.0.0:8443" correctly you will get a nasty error with these symptoms:

1) In TLS, your Client Hello is immediately met with a TCP packet from your server with Ack and Reset flag bits set. (A handshake failure alert, I think?)

2) The event viewer gets "The following fatal alert was generated: 40. The internal error state is 107."

"An SSL 3.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."

So before you go chasing a cipher suite mismatch, ensure that you really are using the server certificate you want to use with:

         netsh http show sslcert

and check the hash values !

share|improve this answer
    
This answer is very unclear and doesn't make a lot of sense. You should aim to directly answer "Why does Window's SSL Cipher-Suite get restricted under certain SSL certificates?" and follow up with an explanation of the Schannel error. –  Bernie White Nov 5 '12 at 8:56

This could be the KeySpec = 2 -- AT_SIGNATURE issue

certutil -verifystore -v My "Thumbprint of cert" to verify KeySpec value. If its 2 the you will need to export the certificate as a PFX file and then run certutil -importpfx AT_KEYEXCHANGE to fix it.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.