This content has moved - please find it at https://devblog.cyotek.com.

Although these pages remain accessible, some content may not display correctly in future as the new blog evolves.

Visit https://devblog.cyotek.com.

StartSSL code signing certificates are crippled

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.

What is the problem with the certificates

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

Why would this dialog be displayed for digitally signed software?

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

I swore a lot when I saw 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

Oh look, a kill switch

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.

The solution?

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

Our new certificate with not a kill switch in sight

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

Update History

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

About The Author

Gravatar

The founder of Cyotek, Richard enjoys creating new blog content for the site. Much more though, he likes to develop programs, and can often found writing reams of code. A long term gamer, he has aspirations in one day creating an epic video game. Until that time, he is mostly content with adding new bugs to WebCopy and the other Cyotek products.

Leave a Comment

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?

Styling with Markdown is supported