before we start, note that this article describes code-signing on Microsoft Windows for applications designed to run on Microsoft Windows 32 or 64bit. Apple’s macOS, iOS and the Android OS also use code-signing but this process is different and uses a different chain of incompatible tools.
Open the pod-bay doors
We all know that writing code is a non-stop smorgasbord of fun, adventure games and caffeine-induced migraines. But eventually the party music has to stop and we need to get our programs out into the sweaty hands of the unsuspecting general public.
Or as Embarcadero (and Microsoft) call it: deploy.
Deployment of applications back in the halcyon days of Windows XP really meant “copy it to a CD” or, if you’re a “mature” programmer like myself maybe even a floppy disk. Oh such happy, carefree, virus-laden days.
Now of course operating systems have become a lot more sophisticated and gained complexity in deployment thanks to the preponderance of computer viruses, worms and trojan apps.
The old ways of trusting our luck just don’t work any more and the virus-writers are almost constantly engaged in a digital arms race against the anti-virus and operating system vendors.
Add to that the huge improvement in connectivity with fiber-optic cables or super-fast internet being ubiquitous in most of the Western World and gradually to the neglected rest too, then installation of applications is often digital – a link on the internet – rather than via some physical medium.
It’s a matter of trust
With easy digital distribution problems started to crop up. The hackers and crackers started to spoof URLs of popular application vendors. More than once popular applications were copied and injected with viruses. The spoofing got so good that it soon became very difficult to tell if the program you had downloaded was actually from the genuine vendor or from some nefarious bandit chomping Cheetos in a sweat-laden bedroom viper pit while he/she scooped up your banking details.
Enter a solution – code signing. Code signing uses a mechanism to embed a cryptographic-protected digital ‘certificate’ into your application’s exe or package. The certificate is issued by a Certificate Authority which is one of a handful of well-known, publicly-listed companies. The certificate is issued to the application vendor using a secure mechanism after which the application vendor (that’s you!) then uses one of a selection of special tools to sign their applications with the certificate.
This ‘signing’ embeds the certificate into the application’s exe or executable module. Once embedded in this way the certificate or any other part of the signed application file cannot be changed without breaking the certificate. This is important as it stops viruses from infecting your application and then giving the user a false sense of security because they trust you and the appearance of the certificate means you and only you created that application module. Note that it doesn’t mean you can’t accidentally code sign an application module which has already been infected with a virus or contains trojan code – but it does mean everyone will know you did it. Of course, I’m sure you use several layers of anti-virus protection on the computers which you use to build and deploy apps… right?
With the advent of Windows Vista the Windows operating system introduced User Account Control started to look for these embedded certificates and if the application you were trying to launch didn’t have a certificate Windows would show a slightly fear-inducing message telling you the publisher was unknown with a passive-aggressive hint that this would be a Bad Idea
Once you code-sign your app the sick-yellow warning gets replaced with a much more comforting blue-skies thumbs up:
As you can see in the above dialog – my name appears by “verified publisher”. This is because this was the name of the publisher on the code signing certificate. So it’s important to pick the right name if you go to purchase one.
Now, signed like this no-one can be in any doubt over who created this application because it was me who signed it or at least someone I gave the code signing certificate to along with the credentials to use it.
How to get a code-signing certificate
There are a few types of code signing certificate. Note that none of them are the same as SSL certificates used for web sites.
This is a confusion which seems to crop up regularly – the two things are similar in nature but used for different purposes and you can’t use an SSL certificate to sign code and you can’t use a code signing certificate to enable SSL and make the padlock appear on your website.
The main types of code signing certificate are:
Self-signed certificate
You create this yourself and there is even a button in Delphi 10.3 Rio’s provisioning page when you select a distribution type of “Windows Application Store”. It has the least amount of ‘trust’ and is used either for internally-distributed apps (for example within your company) or for testing purposes. You can’t use this type of certificate for ‘regular’ apps that you want to distribute to large numbers of people and even among friends you may find they are unable to run your app as they might have Windows settings which prevent this; in particular Windows 10 S is a particular flavor of Windows, installed on Microsoft Surface devices by default, which prevents installing any apps at all unless they arrive via the Microsoft App Store. In short, self-signed certificates are only just better than unsigned apps. They do have the advantage that they’re easy to create and they’re free but that’s about it.
OV Certificate
OV Certificates – or “organization validated” certificates are the most common and cheapest form of code signing certificate. This certificate costs money. The OV certificate requires the person in whose name the certificate will be issued to go through a verification process. This process can take a day or two – sometimes longer depending on what information the certificate issuing authority asks for and how easy it is for you to obtain.
For registered companies such as Ltd, PLC, LLC, Inc and charities the verification process usually uses publicly-available information such as Dun & Bradstreet and other public legal listings to validate the existence of the organization. There is usually some extra machinations such as providing a letterhead and taking part in an automated verification phone call to a number listed in the public records for that organization. It’s usually straight-forward.
For individual developers it’s a more involved process. In my case when I wanted a code signing certificate in my own name – rather than a company – I had to take various proofs of identity to a Notary Public. This is because I am based in Dallas, Texas, USA. Developers in Europe and other countries will have a different but similar process. The notarized copies of ID (there was more than one document) were then sent by the notary to a specific fax number and scans were emailed too. The whole process took about a week. I used my local UPS store for the notary services – they were cost-effective, less than $10,and I use them now for all notarization (which in the USA seems to crop up a lot!)
Despite what you may hear in most cases an OV code signing certificate is perfectly fine for the job. I write code for a number of software houses and one in particular signs all app resources using an OV certificate. These apps go out to in excess of 10,000 active customers in a huge variety of operating system configurations and deployment scenarios from regular Joe public to small offices to blue chip public listed companies including several airports and at least one Embassy that I am aware of, maybe more.
To code sign with an OV certificate you can use a utility I will describe later or Microsoft’s own MSSign application. Delphi 10.3 Rio also can sign your apps too with the OV certificate as long as you’re targeting Ad-Hoc on Windows.
EV certificates
EV Certificates or “extended validation” certificates are a much more complicated thing to obtain.
For a start the validation process is much more rigorous. Once you pass this validation process you will be issued with a USB hardware ‘key’ which is a device that acts as a ‘token’. This token must be physically present each and every time you wish to sign some code. I know that for some people this has proved to be a problem and can make automated builds a pain since you have to physically type in a password to authorize access to the token – a step which apparently can’t be fully automated.
Once you do obtain an EV certificate it does mean that things like Microsoft Smart Screen will provide you with the highest level of trust. For some scenarios this is going to be an absolute requirement.
For me, I’ve not found it necessary to get anything other than an OV code signing certificate – I recommend you read through the links above and make your own choices.
Microsoft App Store Code Signing
This final type of certificate is a bit of a weird one. When you submit an app to the Microsoft App store – either paid or free – Microsoft pass it through a validation process which checks that you’ve not used any forbidden API calls or included any other obviously infringing content. Once you pass that validation Microsoft will then sign the app for you. The code signing still identifies the author as you and is based on the “publisher” details you provided to Microsoft when you signed up to their App Store as a developer and submitted the package. I’ve yet to work out quite how Microsoft validate this as strongly as an EV or OV certificate but in the end I guess it’s not relevant to you as the developer.
Where to get a code-signing certificate
A disclaimer – I don’t have any association with any of the companies I’ve linked to here and elsewhere in this article. I can vouch for K Software because I’ve used them for a few years now for several customers of mine and always get my certificates from them but beyond that I don’t know them and they don’t know me 🙂
The cheapest/most cost effective certificate vendor I’ve found is https://ksoftware.net – they are resellers for Sectigo (previously known as Commodo) and provide both OV and EV certificates. The renewals are discounted too. I assume they survive off Ramen noodles for lunch every day. Either way, I’ve used them for a while and they’re still going strong so more power to them.
The number one main source for code signing certificates is Sectigo (Commodo) themselves and can be found here: https://sectigo.com/signing-certificates/code-signing – weirdly enough they are a lot more expensive than K Software who resell their certificates. I’m not sure why this is.
There are a large number of other resellers and top-level certificate authorities. I do not have experience of them so I’ll leave you to wade through the morass. Don’t pay too much, is my advice, but make sure you’re getting the correct thing.
How to code-sign your apps
I’m not going to describe the process of actually getting the certificate because the vendors do a good job of walking you through it. But however you do it you will end up with a file which either ends in .p12 or .pfx – here’s a pro tip: some apps and techniques for code-signing ask for P12 files and some want a PFX file. Whatever one you have make a copy of it and rename the copy’s extension to whatever the other one is. So P12 to PFX or PFX to P12. The reason this works is they are exactly the same file format at the binary level. Only the file extension is different. I know of one person who was going to pay for a second code signing certificate “because they had the wrong format”. Luckily they ranted in my direction and I was able to save them doling out cash unnecessarily.
If you have an EXE and you simply want to code sign outside of the IDE
Using KSign
No matter where you got your certificate, go to K Software’s website and scroll to the link which says Download KSign Now. KSign is a small Windows app which allows you to manually code sign any of your exes.
The app has areas for the certificate details and an area where you can drop or select one or more exes to code-sign. It’s easy to use.
Manually signing using Microsoft’s SignTool
You can use Microsoft’s command line code signing tool. This may be already installed on your machine.
If it’s not installed you can go here to read more about it and download the necessary software kit: https://docs.microsoft.com/en-us/windows/win32/seccrypto/signtool
Using SignTool is fairly easy. You need to open a terminal Window and use a command line like so:
"C:\Program Files (x86)\Windows Kits\10\bin\x64\signtool.exe" sign /f C:\PATH\TO\YOUR\CERT\certname.p12 /p passwordforthecert "C:\PATH\TO\EXE\myapp.exe"
Obviously that needs to be all on one line. Note the use of the P12 certificate extension.
I use Signtool in some of my automated builds where I am signing several hundred different exes and modules which are built via a script.
Code signing in the RAD Studio Delphi IDE
There are two ways to do this. You can either use SignTool as post-build task in the IDE. You can read more about how to set up these tasks here: http://docwiki.embarcadero.com/RADStudio/Rio/en/Creating_Build_Events – essentially just replicate the line above for the manually signing using SignTool paragraph and tweak it for your situation.
The other way to sign your apps is to target the Windows Application store and select “ad hoc” as the distribution type as shown here:
In the section which says “certificate file” put (or choose) the path to your PFX code-signing certificate.
In the password field put the password which you used when securing your certificate file. You’ll know which one this is when you’ve got your certificate.
Now when you select build and deploy it the resulting application will have been signed with your certificate.
7 thoughts on “Delphi 10.3 Rio – Code signing, provisioning and the Microsoft App Store”