NServiceBus problems with RavenDb

I work on a .NET application that uses NServiceBus. Under the hood, NServiceBus uses RavenDb for persisting data and state. I hadn’t needed to work on this part of the application for a while, but today I needed to get NServiceBus up and running again.

Unfortunately it wouldn’t work. NServiceBus kept crashing out with the error:

Exception when starting endpoint, error has been logged. Reason: Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).

What had happened since I had last run NServiceBus last. Ah yes, Windows 10…

I decided to reinstall the RavenDb Windows service. You can do this relatively easily by opening a command prompt in the RavenDb folder where the raven.server.exe file lives and typing these two lines:

There was also another error being raised internally:

NServiceBus performance counter for Critical Time not set up correctly. Please run the NServiceBus infrastructure installers to rectify this problem

Because we are using NServiceBus v3 rather than v4 (upgrading our application would more than likely be painful and currently it just works – never touch a running system and all that), I checked the RavenDb version support. A colleague was running build 2910, so I decided to do the same.

After installing RavenDb again the initial problem was still apparent and a bit of Googling led me to a StackOverflow post about corrupted NServiceBus performance counters.

After rebuilding the performance counters using lodctr /R, everything started working again. Note that if you are on 64 bit Windows, you’ll need to run that command under syswow64 and not system32.

Happy NServiceBus-ing…

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.

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: http://help.mysonicwall.com/applications/vpnclient/

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