I hate code-signing like I hated networks in the 1980s.

Warning: This blog is a mix of technical help to those in the same situation as myself, as well as a gripe/snarl/outpouring/angry rant about of the idiocy of this. Ends with an expletive not deleted.
In the 1980s getting a network to go between 2 or more computers was, to me, a chaotic enterprise. The knowledge you needed was baroque and ever changing. So as soon as you understood it the technology would change and you'd have to learn new stuff to do the same thing all over again. So I left networks to the masochists who liked them.

Now there's another subject about which I have the same feelings. Code signing. I have to do it once every three years or so and I forget how it works each time, or it changes how it works each time. So I hate the subject.

But I thought: If I blog about it I'll have to be clear, precise and informative in the blog. I'll have to really understand it.

So here goes...

Code signing means adding some bytes to a program so that if it is altered by a virus (or less menacingly copied badly because of a hardware or download error) the infection (or error) can be detected.

Microsoft gives red-alert warnings if you try to download or install a program which has not been code signed.

So I have been signing all my programs and all my install exes for years. I was smug and happy until January 2016.

The idea of code signing is to guarantee two things:

1. The source of the program. When a program is associated with a publisher's unique signature, distributing software on the Internet is safer.
2. The fact that the program is not infected by a third party or damaged.

However it does nothing of the sort.

A code signing certificate is something a trusted authority (like Comodo) gives you, the developer. It is the certification authority which says "Yes, this is who made this program." (Note it does not say that the program is safe, just that it purports to say where the program comes from.) Once the program or installation is code-signed you cannot deny that you did. (Even if you didn't.) It makes you take responsibility for the file. (In theory.)

So if you right click on a Windows program and select properties you'll get a dialog with a tab which says Digital Signature. Here it is on an Italian system:

Programs which don't have a digital signature don't have that tab.

The problem for me is that, now, in January 2016, Microsoft is telling users that programs which are code-signed using an older method have corrupt or damaged digital signatures. Here it is in Italian:

With a big red warning! The words corrupt and damaged really scare potential customers. So I need to move to the newer more secure codesigning certificate. I used SHA-1 to avoid that warning in the past, but now have to use SHA-256 to avoid that warning.

That is the only reason I will sign code. I repeat: Code signing does not guarantee anything to anyone, except that user's won't get a big scary red graphic warning on download.

The more I read about code-signing the less I am impressed. I use the Tarma installation creator for my programs. But look what Tarma says about code-signing:

"Digital signatures do not solve any major software problems and introduce a few of their own." All I am doing by signing my executable files is jumping though pointless hoops to avoid the big red warning.

With code-signing there are two numbers, a public key and a private key. The private key is the one I, the developer, own. It is stored in my browser or in a file on my computer. The problem is that anyone who gets hold of the private key can sign any program and say it came from me. And Windows will believe it. In fact so will workers in nuclear power stations, as the stux-net virus proved. Search "stux-net virus and code signing" in your favorite search engine to find out more.

Code-signing works if you know you can trust the issuer of the certificate and the user (me, the developer) of the certificate. But how the hell do you know you can trust the user of the certificate? Because his .EXE files are digitally signed! But the .EXE file may be signed with a stolen private key file. So you'll never know you can trust the user unless you work with him, in the office and see how he stores his private keys.

The private key is only known to the owner, you. In theory. If it has not been stolen. You, the developer, should store you private key well. Like on more than just your old hard disk. The digital signature (which is put inside your EXE) is created using your private key.

The public key is known by anyone who wants to. The private key generates the signature, the public key validates it. 

So when you right click and see the digital signature tab Windows puts the two keys together (one inside the EXE and one on a server) and decides if the EXE is safe.

What is going on is that from January 2016 Microsoft has changed what it considers a valid code sign. Reports of big red warnings on my software began coming in. "Expletive deleted!" and "Hells Bells!" I thought. "I am signing them and my certificate has not expired. What is going on?" MicroSoft changed the hoops to jump through.

So, if you're a developer here is an overview of the steps to code sign your files.

1. Buy a certificate. I buy mine from K-Software (an excellent service) who are resellers of Comodo.
2. You will be sent a "collection link." Visit the link using your browser (the same browser you used to order the certificate) and the certificate will be placed inside the "store" of your browser.
3. Export your certificate from your browser using the advanced options in the browser. It will be a .PFX file. Firefox will call is a .P12 file, just rename it to have the .PFX extension. The .PFX file contains the private key and the certificate.
4. Use the PFX file in the tools which can be used to codesign your executables.

I was slightly comforted that I heard that Comodo (a code signing authority) had an "insane backup" of upgrade orders, so I wasn't the only one caught out.

(What is the PFX file? It contains the certificate and the private key. It may be password protected. It combines .spc and .pvk, or maybe is directly made from the browser. .P12 and .PFX are the same.)

Anyway. I thought I'd sussed it when I managed to get an SHA-256 siganture:

But I'd forgotten to use the SHA-256 certificate:

So when verifying your EXE files make sure that they are signed with SHA-256 and that they contain a SHA-256 certificate. Thanks again to K-Software for pointing this out.

BUT BUT BUT: Microsoft now does not give a warning when someone downloads my files, however it does give a Big Red Warning when they try to install them from Internet Explorer if the files are new. So I've jumped through the hoops of a security system with huge holes (?!?), imposed by Microsoft... and they still tell users not to install my programs. Expletive deleted. Or maybe not. Fuckit.

(My latest post about code signing, the practical steps, is here.)