Blog Articles and information on C# and .NET development topics

TL;DR: StartSSL code signing certificates are crippled and your binaries no longer trusted once they have expired, even if they have been counter signed.

Two years ago I purchase a code signing certificate from StartSSL which was extremely smooth - I originally documented the process in a blog post.

Fast forward two years of happily signing binaries and the certificate was due to expire - time to renew. StartSSL has recently had some trouble and their root certificates were going to be distrusted by some of the major browsers. Although this was a concern, I still probably would have purchased a new code signing certificate from them, except for a "lucky" incident.

This blog post had quite long introduction as we haven't had the best of luck with code certificates, but I decided against publishing it. Suffice to say, I delayed purchasing a new certificate until after it expired while I tried to determine if we were going to go with another CA. By chance, I was testing one of our signed setup programs in a virtual machine while looking at an unrelated deployment issue. The binaries had been countersigned before the expiry and by rights should have been perfectly fine. Should have.

Instead of the usual Windows Vista UAC dialog (we use Vista VM's for testing) I was expecting, I got the following instead

As I noted that binary was signed before the certificate expired and the certificate hadn't been revoked, so what was the problem? After all, signed software doesn't normally stop being trusted after the natural lifetime of a certificate. (I tested using a decade old copy of the Office 2003 setup to confirm).

On checking the signed programs properties and viewing the signature, I was greeted with this

Now fortunately, this is a) after the fact and b) I try to keep my writing professional given that anything you write on the internet has a habit of hanging around. But there was substantial amounts of swearing going on when I saw this. (And a wry chuckle that at least I'd removed the validation checks so I wouldn't have a repeat of all software breaking again. (Something else I subsequently verified as our build process checks our binaries to make sure they are signed, now any Cyotek binary which came from a NuGet package failed the deployment check)).

Not being a security expert and unable to find answers with searching, I took to Stack Overflow and got a helpful response

Not all publisher certificates are enabled to permit timestamping to provide indefinite lifetime. If the publisher’s signing certificate contains the lifetime signer OID (OID_KP_LIFETIME_SIGNING 1.3.6.1.4.1.311.10.3.13), the signature becomes invalid when the publisher’s signing certificate expires, even if the signature is timestamped. This is to free a Certificate Authority from the burden of maintaining Revocation lists (CRL, OCSP) in perpetuity.

That sounded easy enough to verify, so I checked the certificate properties, and there it was

That innocuous looking Lifetime Signing value is anything but - it's like a hidden kill switch, and is the reason that the binaries are now untrusted. Except this time around instead of 9 months of affected files, I've got two years worth of untrusted files.

Checking other certificates (such as that Office 2003 setup) just had the Code Signing entry, including my original two Comodo certificates.

Maybe StartSSL stopped doing this in the past two years, but somehow it seems unlikely. It may also be that only some classes of certificates are affected by this (the first two I had from Comodo and the one from StartSSL were class 2. I can say that the Comodo certificates weren't crippled however.)

Regardless of whether class 3 aren't affected, or if they don't do this anymore, I'm not using them in future. There wasn't even the hint of a suggestion that the certificate I'd bought in good faith was time bombed - clearly I would never have bought it if I knew this would happen.

Add that and the fact that StartSSL are now owned by WoSign (a Chinese CA I'd never heard of before), and are being distrusted due to certain practices, it doesn't seem like a good idea for me personally to use their services.

Against my better judgement I went back to Comodo as I couldn't justify the price of other CA's. However, bar an initial hiccup, the validation process is complete and we have our new company certificate - I can switch the CI server back on now that the builds aren't going to fail! And in fact, the process this time was even easier and just involved the web browser.

And best of all, no kill switch in the certificate...

I wonder what will go wrong with code signing next? Hopefully nothing and I won't be writing another post bemoaning authenticode in future.

• 2017-01-05 - First published
• 2020-11-21 - Updated formatting

While we appreciate comments from our users, please follow our posting guidelines. Have you tried the Cyotek Forums for support from Cyotek and the community?