SHA256 Server Certificate forcing ECDHE ciphers

Question

I am experiencing a strange issue with assigning a new SHA256 certificate to an IIS web server.

The server has SSL 3.0, TLS 1.0, 1.1 and 1.2 enabled and when using a server certificate on a site signed with RSA (rather than SHA256RSA) the client connects and negotiates TLS_RSA_WITH_AES_256_CBC_SHA for the TLS encryption.

The second the SHA256 certificate is used on the site it then tries to use TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.

What is odd is that when checking using www.ssllabs.com server test I can see that completely different ciphers are presented from the server when the SHA256 certificate is used or is not.

Ciphers Suites presented when site using SHA1 certificate.

TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECHDE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WTH_RC4_128_MD5

Ciphers Suites presented when site using SHA256 certificate.

TLS_ECHDE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

I can find no information to show why this happens but I was aware TLS_RSA_WITH_AES ciphers were TLS 1.2 compatible and there seems to be no literature to state if the server certificate is SHA256 that it enforces Elliptical Curve Difie Helman Exchange for the key encryption.

Can anyone explain why this might be happening?

Kind Regards

James Tighe

Answer 1

I have now managed to resolve this issue in case anyone else is getting it.

It seems that it is to do with the Cryptography/Key Store Provider used to request the CSR.

If the CSR is generated on the Windows Server 2008 R2 machine using a Crypto API providers (such as Microsoft Strong Cryptographic Provider) and the KeySpec is not specifically mentioned when generated the CSR it sets the KeySpec = 2 AT_SIGNATURE. The KeySpec determines whether the key can be used for Signatures, Key Exchange (encryption) or both.

When setting the Cryptography provider to a Crypto API provider seems to cause the Windows Server 2008 R2 machine to complete the request but default to KeySpec = 2 In our case it was because we had generated a .INF file to be used with CERTREQ as IIS was not able to enforce the use of SHA256 as the signing algorithm.

If the KeySpec is set in the .INF file to KeySpec = 1 AT_KEYEXCHANGE then this should work although we resolved this issue a different way.

In order to resolve the issue we changed the .INF file to set the ProviderName = "Microsoft Software Key Storage Provider" (a CNG provider). When the certificate was completed it showed the KeySpec = 0 AT_NONE which is when the key store provider is set to CNG.

This issue was raised to Microsoft to help us get a better understanding and it appears that we were right in the KeySpec behaviour and the usage of the Cryptography Provider.

They confirmed that in the .INF file (or the customer template enrolment in Cert MMC) you need to ensure the KeySpec property is set to 1 AT_KEYEXCHANGE or else it will default to 2 AT_SIGNATURE. If you use a CNG provider it will instead default to use 0 AT_NONE and will work correctly.

I hope this can help other people that might be getting this annoying issue as it was quite hard to find a solution.

Kind Regards

James Tighe