Buying a Code Signing Certificate

Towards the end of last year, I decided to buy a code signing certificate. Why would I want to do that? Well, I've been working on publishing a new Skype call recording utility, and if you leave your applications unsigned, then Windows SmartScreen can block users from installing and running it. There is a way to ignore the warning messages, but many users will not know how to do this, and I wanted to remove as many barriers to installation as possible.

Having a signed application doesn't automatically make these warnings go away. After all, what's to stop a malicious hacker from signing their own code? But once Windows decides that they trust my application, the theory is that any updates or new applications signed with the same certificate will also be trusted.

Step 1 was to find a code signing certificate that wasn't horrendously expensive. Code signing certificates are a lot more expensive than SSL certificates (I recently picked up an SSL certificate for $25 for five years), and can be several hundred dollars a year. This is of course no big deal if you are Microsoft or Adobe, but for an independent developer, this is a significant investment, particularly if you don't have a high volume of sales, or are producing freeware.

I eventually settled on using K Software, whose website seemed to contain relatively up to date information about code signing certificates. Their cheapest authenticode certificates were about $80 per year, and they promised a fast turnaround time. Apparently certificates could be issued as quickly as 15 minutes, or 1-2 days if identify verification was needed.

So I made the order, and my order was passed on to Comodo, who were the actual certificate authority who would be issuing me with my code signing certificate.

After a few days of silence I chased up to ask what was going on, and I got a reply back telling me I needed "face to face verification". In other words I needed to prove I was who I said I was. Fair enough, I was expecting to send some proof of identity to them, but I hadn't anticipated they would require me to visit a Notary Public.

They also told me they wanted my details on 192.com and scoot.co.uk. This was something I really didn't want to do, since these open you up to nuisance marketing phone calls. But I had no option if I wanted to, and registered my business on scoot.

Visiting a notary was a bit of a hassle as it required me to take a half-day off work. It cost me £40, and he took copies of my passports, bank statements and various other forms of identification, and faxed them through to Comodo. I was required to "overnight" the documents to Comodo, but that isn't an option the Royal Mail offer to America, so I went for their best service of tracked and signed, which supposedly delivers in five working days.

That proved to be a mistake, as my documents took 16 days to arrive. This was extremely frustrating as scoot were constantly pestering me with phone calls trying to upsell me to their paid offering. They kept explaining that their free option doesn't show your company website URL to visitors, and wondering why I didn't seem to care about this. I didn't want them to boot me off their listings, so I had to stall them for as long as possible, while I waited for the interminably slow overseas postal service to deliver my documents.

Very concerningly, after I got confirmation of delivery from Royal Mail, Comodo claimed not to have received my documents at all. But after several emails they eventually decided they had received them. Now they needed to contact my Notary Public and get him to verify that he really did send the documents. This took another a few days, and finally, well over a month after making the order, I got my signing certificate.

To actually download the certificate, I needed to use the same computer and browser as I had used to make the original order. This was a bit of a problem at first because I had actually forgotten which one I used now that a whole month had elapsed. But eventually I downloaded my certificate, and it downloaded into some mysterious location in Chrome, but fortunately allowed me to export it as a .pfx file, which is what I needed for signing ClickOnce applications.

So I did finally get my code signing certificate, and it certainly didn't take anything like the 1-2 days advertised. It meant I had to delay the launch of my product by a month. The good news is that as far as I can tell, signing my code has had the desired effect - the installs I've tried haven't been blocked by Windows SmartScreen.

So if you decide you want a code signing certificate, do give yourself plenty of time to get it sorted out and don’t leave it to the last minute. You may also want to check out this very thorough article from Eric Law in which he explains how he went about getting his code signing certificate and set up a hardware security token.

ClickOnce Deployment Fundamentals

I'm delighted to announce that my sixth Pluralsight course, ClickOnce Deployment Fundamentals is now live. In it I go through all the options available for customising your ClickOnce deployment, as well as how to handle updates, the capabilities of the deployment API, and what gets stored where on the disk. I also have modules covering some of the more advanced parts of ClickOnce such as handling pre-requisites with the bootstrapper, signing your deployment, and using the MAGE tool.

Why ClickOnce?

You may be surprised that I'm doing a course on ClickOnce, since it is now a fairly old and oft-maligned technology. As I explain in the course, it's not the right choice for all installers, but for simple .NET applications, it may actually prove to be the simplest solution for keeping your application automatically up to date. I go through some of the pros and cons in the course, as well as pointing out a few alternatives you might want to consider.

Some ClickOnce Resources

I've tried to give a fairly comprehensive coverage of ClickOnce capabilities in the course, but you can't cover everything, so here's some of what I consider to be the most helpful resources if you are planning to use it yourself.

• RobinDotNet Robin is one of the few genuine ClickOnce experts out there on the web, and she has provided several really helpful articles, including things like how you can host your ClickOnce deployments in Azure blob storage.
• MSDN - MSDN may not be the most thrilling documentation to read, but don't overlook it when it comes to ClickOnce, as it is really the only comprehensive source of information you’ll find. Have a look here and here for some useful material.
• Smart Client Deployment book by Brian Noyes. This really is the best book out there on ClickOnce. Don’t be put off by the fact that it is fairly old now. ClickOnce hasn’t changed an awful lot though, so pretty much everything in the book is still relevant.
• Finally here’s a video that discusses re-signing with MAGE, which shows how to work around a nasty gotcha when re-signing if you are using .deploy file extensions (which you probably are if deploying via the web).

More to Come on Signing…

I’m also hoping to follow this up with another post about the process of signing your ClickOnce applications. I actually attempted to buy my own code signing certificate which I wanted to use in my demos in this course, but it has proved surprisingly difficult to complete the purchase of my certificate (certainly a story for a future blog post), so for the course I just used a self-generated certificate. As soon as I finally get the real deal, I’ll post showing what difference it makes to the warnings you receive during installation when your app is signed by a certificate issued by a trusted Certificate Authority.