Site hosting news, tutorials, tips, How Tos and more
Note: beginning with Chrome version 46 the yellow caution triangle has been removed from the https URL when Chrome encounters minor errors such as those described in this article.
If you use an SSL certificate (https) on your site, you may have seen a couple of new things happening in Google Chrome.
When you upgrade the Google Chrome browser to version 41 or later, you may see various warning messages such as, “The identity of this website has not been verified,” “Your connection to <domain> is not encrypted,” or other visual indications that the https connection is not secure.
Those indications can appear when your SSL certificate uses a SHA-1 signature (most SSL certificates issued before 2015 use SHA-1).
To fix the problem of browser security warnings you must get your SSL certificate re-keyed for SHA-2. If you don’t see those warnings in Chrome and you purchased your certificate recently, it may already be SHA-2. You can verify using this test site.
1) Contact us and we will re-generate and re-submit the CSR.
2) You’ll then get an email from GeoTrust with a link to complete the process. When completing the re-key on the GeoTrust site, be sure that SHA-2 is selected as the “Hashtag Algorithm.” You can find step-by-step instructions (and a video) here.
3) After you’ve completed the reissuing process, you’ll receive an email with the new certificate. Go to Control Panel and paste the new certificate into the SSL manager and you’re finished.
1) Contact us and we will re-generate the CSR and email it to you. Then you’ll have to contact the issuer of your certificate to get your certificate re-keyed for SHA-2.
2) When you receive the re-keyed certificate, go to Control Panel and paste the new certificate into the SSL manager and you’re finished.
There is another potential problem after you’ve re-keyed your SSL certificate. While the address bar will show the green lock icon, if visitors dig deeper in Chrome, they may see an “Obsolete Cryptography” message.
Basically what’s happening now is they are ignoring the cipher preference we use on the server (which includes their preferred ciphers) and pointing out any “weak ciphers” they find. You might notice that many large corporate sites (such as Apple) are also insecure according to Chrome, for similar reasons.
That “obsolete cryptography” message may be with us for a while because Google is not providing any information (yet) on exactly what they want from the server to stop calling it insecure. It would seem that what Google would like to see is every server everywhere removing support for all older cryptographic methods.
The problem with that is removing some of those methods will shut out visitors using some older browsers and operating systems that don’t support newer methods (i.e. Windows XP). Since our servers are shared by many customers, it isn’t really an option for us to make global changes that prevent some visitors – even a small number – from accessing our customer’s sites.
We do run some special servers that do not support any of the older cryptography methods, they are primarily used by customers who need a “hardened” server to pass a PCI compliance scan. But the added security comes at a cost, as older browsers can’t connect to sites on those servers via https. Additionally, a few other things that you may take for granted now may not work, or may require adjustment or a work-around on your part. But if you’d like to move your site to such a server, just let us know.
And of course we continue to monitor information from Google on recommended server configuration, as well as continuing to test various configurations ourselves to prevent the “obsolete cryptography” message.
If you have any trouble re-keying a certificate, or if you have any questions about these ongoing changes, drop us a line and we’ll do our best to help.
—> Basically what’s happening now is they are ignoring the cipher preference we use on the server
Google Chrome negotiates TLS_RSA_WITH_AES_128_CBC_SHA (0x2f), the second cipher in your preference, despite being obsolete. Your first cipher is TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c), but Chrome doesn’t support it.
—> You might notice that many large corporate sites (such as Apple) are also insecure according to Chrome, for similar reasons
Isn’t it because Apple servers don’t support ephemeral key exchange, which is considered modern?
Your server supports ECDHE key exchange, but with the lowest priority. Since your server is Microsoft IIS, I don’t even wonder. Microsoft made unfortunate practices such as SSL 2 being enabled by default (older versions) and prioritizing static RSA over ephemeral ECDH.
Even after prioritizing ECDHE, Chrome will still warn about obsolete cryptography, because AES mode is CBC instead of GCM. Since Microsoft IIS doesn’t support ECDHE_RSA + AES GCM, use traditional DHE, but here is an unfortunate practice again: IIS doesn’t support Diffie-Hellman parameters > 1024 bits, which are already considered weak. Either migrate to full elliptic curve key exchange by getting an ECDSA certificate or use Apache/nginx instead of Microsoft IIS.
—> The problem with that is removing some of those methods will shut out visitors using some older browsers and operating systems that don’t support newer methods (i.e. Windows XP).
How will prioritizing ephemeral key exchange and authenticated encryption do this, if you are still free to support static RSA with Triple DES? You can even support RC4 with the lowest priority and still get “modern cryptography”, despite RC4 use in TLS being forbidden.
—> pointing out any “weak ciphers” they find
Since 18 November 1996, servers do not leak this information to browsers. 19 years already!
Please check: https://www.ssllabs.com/ssltest/analyze.html?d=winhost.com&hideResults=on&latest
and you will see why “Obsolete cryptography”… You are enforcing non-ECDHE ciphers. See also comments on: https://community.qualys.com/message/29849#29849
> use Apache/nginx instead of Microsoft IIS.
I don’t think most of our users would appreciate that, considering they specifically bought hosting on Windows/IIS servers.
You guys are very well versed in security, that’s good. The article isn’t written for you though, it’s written for customers who see warnings that they may not understand.
We’re working with commercial production servers and they are Windows/IIS servers. We do as much configuration as we can, but there are still elements that are controlled by IIS that we can’t change. And as far as what we can change, every security change has a potentially negative effect on some users, so while a change may seem trivial to you, we can’t be cavalier where server configuration is concerned.
I appreciate your concern and your expertise though.
>You guys are very well versed in security, that’s good. The article isn’t written for you though, it’s written for customers who see warnings that they may not understand.
Some of the assumptions in above article are wrong… You can still improve your security by prioritizing ECDHE ciphers on your system. Execute SSL/TLS test: https://www.ssllabs.com/ssltest/analyze.html?d=winhost.com&hideResults=on and you are going to see the ECDHE are not prioritized, but it should be.
I am more a Apache http guy, so can’t advice how to set cipher order in IIS, but try searching Google for: SSL Cipher Suite Order in Microsoft IIS
or something similar