Why does Chrome complain about "obsolete cryptography"?

Question

I am hosting an ASP.NET website with wildcard ssl certificate on IIS / Windows 2008R2. While Chrome works fine with my website and shows a green lock the https connection, the https details mention "obsolete cryptography":

I assume that this is due to SHA1, which is also being mentioned by chrome in the same window.

However, according to Digicert's SSL Certificate Checker, SHA256 should be used:

Now I am not sure what is going on and how to fix this problem. It appears that this blog post describes a workaround for this problem, but the workaround seems so obscure (1. Step: Install OpenSSL?), that I can't imagine this is the offical way to do it on Windows 2008 R2.

How should I proceed to get rid of the ssl certificate warning?

Edit: After applying the script recommended by Grant, my SSLabs has been improved from C to A and Chrome is using TLS 1.2 instead of 1.0. However, the "obsolete cryptography" warning is still there.

Answer 1

It's not SHA causing the problem, it's TLS 1.0.

The SSL Labs report for your domain gives the full story. Your server only supports TLS 1.0, not 1.1 or 1.2. In addition, it still supports obsolete ciphers like RC4, and doesnt support perfect forward secrecy.

Tuning IIS to get better security is quite possible, but a pain to do by hand. This wonderful script, written by Alexander Hass, will set a variety of registry settings to disable old insecure encryption methods for IIS7.5 and IIS8.

After running the script, reboot the server, and you should get an A rating on SSLLabs, and stop getting the warnings in chrome.

Answer 2

I'm testing this on a fresh 2012 R2 server, when applying the Alexander Hass script (AH-Script), I still get the obsolete cryptography:

My Chrome 43 supports the following Cipher suites:

[C02B]  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
[C02F]  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[009E]  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
[CC14]  TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
[CC13]  TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
[CC15]  TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
[C00A]  TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[C014]  TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[0039]  TLS_DHE_RSA_WITH_AES_256_SHA
[C009]  TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C013]  TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[0033]  TLS_DHE_RSA_WITH_AES_128_SHA
[009C]  TLS_RSA_WITH_AES_128_GCM_SHA256
[0035]  TLS_RSA_AES_256_SHA
[002F]  TLS_RSA_AES_128_SHA
[000A]  SSL_RSA_WITH_3DES_EDE_SHA
[00FF]  TLS_EMPTY_RENEGOTIATION_INFO_SCSV

so the one used is: [C013], quite far down. It seems Chrome prefers SHA256 and GCM over CBC.

I took the AH-Script and added [009E] (3rd from the top) to the cipher suite list, after rebooting I'm now getting:

I tried to get the top two [C08B] and [C02F] to work, but couldn't.

So by fixing the script and running it I got a modern cryptography.

I removed one of the existing ciphers because the length of that string is limited, the beginning of my string now looks like this:

$cipherSuitesOrder = @(
'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521',
'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384',
'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256',
'TLS_DHE_RSA_WITH_AES_128_GCM_SHA256',
'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384',
'TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256',

Edit: I just tested this on sslLabs.com and using TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 gives me a B, down from an A I had before.

This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B.

So you may not want to use it. Why Chrome rates it so high, I don't know?

Answer 3

The "obsolete cryptograpgy" message in Chrome, is because of the server supporting weak Diffie-Hellman (DH) key exchanges. More specifically, this is documented in the HTTP/2 spec on the Cipher Suite Black List.

When you use the PowerShell script from Alexander Hass (from the current Accepted Answer), then it includes these ciphers which are on the blacklist:

TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

If you look at the Azure App Service, it uses the following cipher suite order:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

This results in a A rating in Qualys SSL Labs (Jul 2016), and supports Forward Secrecy for most common browsers.

I found the Chrome issue because on my local IIS Express on Windows 10, it would return error message ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY in Chrome 51 with the blacklisted cipher suites configured on my system.