How to fix Google Chrome SHA1 warnings with StartSSL – StartCom SSL certificates

I recently renewed my SSL certificate for one of my domains. I use the domain specifically so that I can access my Synology Diskstation NAS drive remotely. After updating the certificate in the Diskstation I noticed that the Cloudstation client started reporting errors, namely that “The SSL certificate is untrusted”, and all syncing had paused.

Untrusted SSL warning on the Synology Cloudstation Client Windows 10
Untrusted SSL warning on the Synology Cloudstation Client Windows 10

I checked the certificate using SSL Labs. All was good. The certificate chain appeared to be in order. I also checked in on SHAAAAAAAAAAAAA, and again all was good. I decided to check it in Google Chrome, and oops, a little yellow warning triangle stating that there was a problem with my certificate. The problem it seemed was that one of the certificates in the chain was using SHA1.

Google Chrome SHA1 warning intermediate certificate from StartCom StartSSL
Google Chrome SHA1 warning intermediate certificate from StartCom StartSSL

I double checked SHAAAAAAAAAAAAA and SSL Labs. Both the root and intermediate certificates from StartCom seemed to be using SHA256. What is going on?

I then notice a warning on SHAAAAAAAAAAAAA that said:

If Chrome still says the site uses SHA-1, it’s probably a chain caching bug on your computer.

Interesting, let’s look further. Now I start to get a bit more detail. To cut a long story short, it seems that Windows has a weird bug in its CryptoAPI. It is a bug that has been there for ages, and all certificate authorities should be more than aware of it. As a result, certificate authorities should have re-issued new intermediate SHA256 certificates signed with new private keys, rather than reuse the keys they used previously. It appears the StartCom hasn’t done that, and as a result, we are seeing these weird caching bugs in Windows (as I understand the issue).

So, how do we solve this? First we need to get the correct intermediate certificates. Apparently StartCom had issued new intermediate certificates at some point. This website allows you to download them: https://class1.test.itk98.net/.

Note: I know it seems weird to download a security certificate from some website that is unrelated to StartCom, but if you think about it, the certificate has to be genuine. Please correct me if I’m wrong!

I have a class 1 certificate, so I’ll download the PEM version of that (top of the page on itk98.net). I now go into the Diskstation manager and from the control panel I choose the ‘Security’ option and the ‘Certificate’ tab. From there I can ‘Import’ a new certificate. I choose my private key used to sign the CSR, my certificate I downloaded from StartSSL (.crt) and the newly downloaded intermediate certificate I just downloaded from that ‘dodgy’ sounding itk98.net URL.

screenshot of Synology DSM certificate import modal window
Synology DSM certificate import control panel

After installing, the web server on the diskstation restarts. I now need to clear out the old SHA1 StartCom Intermediate Server certificate from Google Chrome’s certificate cache.

How to clear out the StartCom intermediate certificate from Google Chrome's certificate cache.
How to clear out the StartCom intermediate certificate from Google Chrome’s certificate cache.

After opening a new incognito window in Chrome, I have a nice green SSL marker. Yay!

solved problem with StartCom intermediate certificate
Google Chrome with the SHA256 intermediate certificate from StartCom StartSSL. Problem solved!

Finally back to the Synology Cloudstation Client on Windows 10. I have to click on the little icon (three blue lines and a down arrow) on the far right of the diskstation name. Choose Edit Connection. A modal appears in which you can just re-enter your password and click ‘Done’. You will receive a message that states that the SSL certificate has changed and asks you if you want to trust it. Hell yes….

Once reconnected the Synology client, you’ll notice that the untrusted SSL warning has now gone away and the Synology Cloudstation Client is back syncing again.

Untrusted SSL error screenshot
Synology Cloudstation Client on Windows 10, no more untrusted SSL certificate warnings or errors

And that was my Wednesday evening.

VirtualMin, SSL Perfect Forward Secrecy and StartSSL

I’ve recently been setting this website up to use SSL. To do so I used a couple of great guides and tools on the internet. I got my SSL certificate for free from StartSSL. I found the guide by Eric Mill invaluable to working through the relatively poor UI that StartSSL has to gain the free certificate.

To check the state of your SSL certificate you can the SSL Test Tool from Qualys SSL Labs.

To start with I received a C grade. I had two things to remedy:

  1. I had SSL3 enabled which is vulnerable to an attack called POODLE
  2. I did not have Perfect Forward Secrecy enabled, which prevents back decryption of previous conversations even when an attacker gains access to your private key (which happened with Heartbleed).

To remedy both these elements I needed to set Apache to use the correct SSL Protocols and the correct ciphers. More specifically I had to prioritise the ciphers that I prefered clients to use. I specifying the more secure ciphers first, clients that support it, will use Forward Secrecy as a priority.

Using Webmin you can go to Servers -> Apache Webserver -> Global Configuration -> Edit Config files

Comment out the existing SSL config. Change to the following:

[code]SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite “EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS”[/code]

I got this from Configuring Apache, Nginx, and OpenSSL for Forward Secrecy. See the Apache section.

If you want to install your SSL certificate in VirtualMin, you need to select your virtual server, then go to Server Configuration -> Manage SSL Certificate.

By default VirtualMin will have install a self-signed certificate, which sadly could be MITMed, which is why we are using the certificate from StartSSL, since they as a Certificate Authority have verified who I am (in the loosest sense of the word, by validating they can send an email to the domain for which I am trying to request a certificate for). More expensive certificates require you to prove your actual identity. More more expensive certificates allow you to have one certificate for multiple subdomains . The whole thing is a racket but I digress.

Luckily a new EFF backed program is coming called Let’s Encrypt, which will issue free certificates and they will be easy to install. This guide will become obsolete (is the hope).

Back to VirtualMin we need to install the certificate that StartSSL has provided us. You need to upload the signed certificate and the private key you used, but you need it in a PEM format. To do that you can use the following command:

[code]
openssl rsa -in mydomain.com.key -outform PEM -out mydomain.com.pem.key
[/code]

You can now upload that via VirtualMin. Now you also need to rest of the certificate chain. You want to get the SHA-2 version since SHA-1 is vulnerable. You can download the Class1 StartSSL PEM file directly from StartSSL.

Now go to the CA Certificate tab and upload that file. Once uploaded you should see the following:

Certificate authority name StartCom Class 1 Primary Intermediate Server CA
Organization StartCom Ltd.
Issuer name StartCom Certification Authority
Issuer organization StartCom Ltd.
Expiry date Oct 24 20:54:17 2017 GMT
Certificate type Self-signed

If you don’t take the SHA-2 certificate then you’ll be downgraded. Google will also be downgrading sites that use SHA-1 based on this too in the future so it is worth getting right now.

To check your SHA configuration, you can use the wonderful shaaaaaaaaaaaaa.com.

Once you have completed this guide, you should get an A grade on the SSL Labs page.

 

The First Few Milliseconds of an HTTPS Connection

In the 220 milliseconds that flew by, a lot of interesting stuff happened to make Firefox change the address bar color and put a lock in the lower right corner. With the help of Wireshark, my favorite network tool, and a slightly modified debug build of Firefox, we can see exactly whats going on.

via Moserware: The First Few Milliseconds of an HTTPS Connection.