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:

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 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 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.

Auto-generating documentation and SDKs in ASP.NET Web API

Whilst I am a big fan of ServiceStack for building REST APIs, it switched last year from a free open-source tool to a licensed business model. For small open source projects without a commercial backer, it means that we have to take a second look at ASP.NET Web API, Microsoft’s own offering.

If you are developing commercial REST APIs then please check out ServiceStack and the hard work Demis Bellot is putting in to the project. He makes awesome products and takes care of his customers.

The benefit of Web API is of course that there are more tools, and extensions being developed by third party developers. There are several challenges in developing APIs that third parties will consume. The two key elements outside the usual development tasks, is the documentation of those APIs, including an API “Explorer” which allows developers to test out the APIs from a sandbox application.

The second major task you have to complete is the provision of SDKs in different languages. For most developers this is a tall task. They struggle to provide SDKs in any other language than the one they are used to working in. Thus, APIs built in Java are unlikely to have a Ruby SDK available.

API Explorer’s using Swagger

Swagger is an awesome and increasingly standard tool for offering developers the ability to try out your API without actually building anything. Using an API explorer they can authenticate using their issued credentials, and then execute REST calls using a web based tool.

Configuring Swagge for ASP.NET Web API just got way easier. Using Swashbuckle you can simply add a Nuget package, apply some configuration and start offering an API explorer in a few minutes. For more information please visit Swashbuckle.

SDKs using AutoRest

Building SDKs in different languages used to be hard, really hard. AutoRest makes it easy. AutoRest uses Swagger extensions to “read” your API definitions and then builds SDKs automatically from those definintions. The following languages/platforms are currently supported:

  1. .NET
  2. Mono
  3. Node.js
  4. Java
  5. Ruby

The AutoRest source code and documentation can be found on GitHub.



How to fix/install the Cisco VPN Client on Windows 10 (64 bit)

I have just upgraded from Windows 7 to Windows 10. The first thing I needed to check (since my work depends on it), is that I can use the Cisco VPN Client. Just to clarify, this is not the AnyConnect client, but the old client (v5.0.07).

I had heard that there are problems with this, since it isn’t a supported Windows 10 application, and isn’t going to be either (since Cisco want people to use the AnyConnect client).

Anyway, problems did arise, and this is how I solved them.

First I uninstalled the existing Cisco VPN Client. I took a copy of the Profiles folder before doing so, although the uninstall program appears to leave them in place. In Windows 10, choose Settings from the main start menu and then search for Programs. From there you can search for Cisco, and you can then choose to uninstall the program:


Once uninstalled you need to install the SonicWall VPN 64-bit CLient from Dell. This will add the Deterministic Network Enhancer (DNE) LightWeight filter, and allow your VPN to correctly download the certificates from the VPN Server.

The Sonic Wall client can be downloaded for free from the following location:

Now you need to install the Cisco VPN Client. If you double click on the self extracting executable then the files will be extracted and by default the executable inside the zip file will be executed. This is not what you want. Uncheck the setting to automatically run the exe:


Once extracted, open the folder where the files are located. Run the MSI. This is important otherwise you’ll see the following error:

Once installed you can uninstall the Sonic Wall client. The application is now needed and the Deterministic Network Enhancer filter remains.

Now fix the display name of the client. You can do this by opening Regedit and then navigating to:

Alter the DisplayName key value, by removing the junk data in front of the description. I left mine as:

Cisco Systems VPN Adapter for 64-bit Windows

It was previously

@oem8.inf,%CVirtA_Desc%;Cisco Systems VPN Adapter for 64-bit Windows


The Cisco VPN client should work as expected.I9xV7Rc

Photo by Kris Krug recipe fails with WordPress recipe

I use Pocket as a personal bookmarking service. Using I can use a recipe that monitors my Pocket feed and then sends new posts to my WordPress blog.

Recently though, this stopped working. The WordPress channel needed reconnecting, and the error I received every time I tried to connect was:

Unable to verify WordPress credentials. Please try again.

Thinking it was one of the security plugins I had used in WordPress, I switched them all off. The error remained. I had been doing some HTTPS redirection to make sure my site in always in HTTPS, so I switched that off too. Still no joy.

Finally I remembered that my site is protected by Cloudflare. When I ‘paused’ Cloudflare, the recipe worked.

My assumption was that Cloudflare was blocking IFTTT requests, assuming that they were attacks on my WordPress installation, but I couldn’t see any logs in the firewall logs in my Cloudflare account.

After wondering around in the Cloudflare settings, I turned items on and off to see if they would make a difference.

It turns out that there is one setting that can cause and therefore fix this problem!

I had a ‘Page Rule’ to force HTTPS always. IFTTT appears to assume HTTP and doesn’t support HTTPS! Bad IFTTT sending my blog logins over HTTP.