Chrome Version 42 Starts Marking SHA-1 SSL Certificates As Insecure

Mattias Geniar, Tuesday, April 7, 2015 - last modified: Friday, April 17, 2015

As announced in September 2014, Chrome version 42 will start to block mark SSL connections using the SHA-1 algorithm as insecure, with a big red cross in the browser.

Update #1: this article originally mentioned Chrome blocking SHA-1 certificates. Chrome will mark them as insecure, but won't actively block the connection. More in the post below.

Update #2: Chrome 42 is now the default and is auto-updated on all clients. SHA-1 certificates are now marked as insecure. (Chrome Release Blog: the Stable channel has been updated to 42.0.2311.87)

Chrome v42 is now publicly released. The browser now starts marking SSL certificates that still use the SHA-1 algorithm as insecure with a big red cross.

What is valid on Chrome 41, isn't on Chrome 42. The xkcd.com site is a prime example. Here's the site on Chrome 41.

xkcd_sha1_chrome

That same site is showing SSL certificate errors on Chrome 42.

xkcd_sha1_chrome_blocked

If you haven't already, check your certificates. If they're still using the SHA-1 algorithm, ask your SSL provider for a re-issue (hopefully free of charge) using a SHA-256. There are some additional rules on when SHA-1 certs are blocked shown as insecure, and when they aren't, depending on the expiration date.

The tl;dr: only SHA-1 certificates with a validation date > 2015 are reported as insecure.

The problem is, it's not only your certificate that needs to stop using SHA-1. Every intermediate needs to be updated as well. In the case of XKCD's site, their certificate was correctly using a SHA-256 algoritme, but their intermediate isn't.

xkcd_sha265_certificate

xkcd_rapidssl_intermediate_sha1

Better check your certificate chains!

As I've said before, the chain of trust is only as strong as its weakest link.



Hi! My name is Mattias Geniar. I'm a Support Manager at Nucleus Hosting in Belgium, a general web geek & public speaker. Currently working on DNS Spy & Oh Dear!. Follow me on Twitter as @mattiasgeniar.

Share this post

Did you like this post? Will you help me share it on social media? Thanks!

Comments

mike Tuesday, April 7, 2015 at 15:25 - Reply

If we trace our intermediate certificates all the way back up into our operating system’s trusted root certificates, we see on many sites that there are SHA-1 root certificates. Chrome 42 has identified this as a bug wherein better, shorter certificate roots are available (a root certificate store has its own children, and a path to any of them is sufficient to establish a chain of trust). Here’s a link to the bug. Point being, if someone reads this article and panics because theres a certificate at the very top that is SHA-1, it should be remedied in chrome 42. There’s nothing for a web server administrator to have a panic over.

https://code.google.com/p/chromium/issues/detail?id=437733


    o Tuesday, April 7, 2015 at 16:23 - Reply

    we see on many sites that there are SHA-1 root certificates

    The signature of root certificates do not matter much, they are self-signed and trusted by default. There is no parent in the chain who could sign this signature by definition.


Federer Tuesday, April 7, 2015 at 21:15 - Reply

I really wonder why just the cert and intermediate certs need SHA2 and not the root CA. According to the deprecation plan, they just want to deprecate the actual certs and the intermediates.

Can I know why the root CAs with SHA1 are OK to go?


    Federer Tuesday, April 7, 2015 at 21:19 - Reply

    Okay! Got the answer form the Google blogpost itself:

    Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.


Leave a Reply

Your email address will not be published. Required fields are marked *

Inbound links