How do I sign a Windows App?

Once you have built your app you will want to be able to share it, either with testers or customers. However, to successfully share your app your users must be able to install it easily. Windows 10 requires all applications to be signed, if your app is not signed your users will see warnings and may not be able to install it.

This lesson will show you how to sign a Windows application using the SignTool command-line tool.


In this lesson we will be using the SignTool command-line tool. This tool is part of the Windows SDK which you can download here.

In the lesson we will also use PowerShell, PowerShell comes installed by default on Windows.

The app to be signed

In this lesson I will use a very simple app that has been built as a Windows Standalone.

Windows 10

Creating a Certificate

Before signing your app you will need to obtain a certificate. For testing you can start by create a self-signed certificate but for distribution you will need a certificate from a Certificate Authority.

This is a quote from the Microsoft Documentation.

App package signing is a required step in the process of creating a Windows 10 app package that can be deployed. Windows 10 requires all applications to be signed with a valid code signing certificate.

To successfully install a Windows 10 application, the package doesn't just have to be signed but also trusted on the device. This means that the certificate has to chain to one of the trusted roots on the device. By default, Windows 10 trusts certificates from most of the certificate authorities that provide code signing certificates.

Creating a Self-Signed Certificate

A self-signed certificate can be used for testing purposes. We will create a self-signed certificate using PowerShell running in elevated mode.

To open PowerShell in elevated mode search for PowerShell in the Search box, when it appears in the result right-click and choose 'Run as Administrator'.

Windows 10

Create the Certificate

To create your certificate run this command in PowerShell

New-SelfSignedCertificate -Type Custom -Subject "Your Publisher Details go here" -KeyUsage DigitalSignature -FriendlyName "Your friendly name goes here" -CertStoreLocation "Cert:\CurrentUser\My" -TextExtension @("{text}", "{text}")
Click to copy
  • KeyUsage: For a self-signing certificate, this parameter should be set to DigitalSignature.
  • TextExtension: Indicates addition uses for the certified public key and whether or not the certificate is a  Certificate Authority. For a self-signing certificate the certificate is not a Certificate Authority.

After running the command, the certificate will be added to the local certificate store, specified in the "-CertStoreLocation" parameter. The result of the command will also produce the certificate's thumbprint.

You can find further details in the Microsoft Documentation here.

Export the Certificate

Before you can use the certificate to sign your app you need to export it to a Personal Information Exchange (PFX) file.

Firstly create a password

$password = ConvertTo-SecureString -String <Your Password> -Force -AsPlainText 
Click to copy

then export the certificate

Export-PfxCertificate -cert "Cert:\CurrentUser\My\<Certificate Thumbprint>" -FilePath <FilePath>.pfx -Password $password
Click to copy

This will create a PFX file that you can use to sign your app.

Requesting a Certificate from a Certificate Authority.

When you are ready to distribute your app, either yourself or via a store, you will need a certificate from a recognized Certificate Authority. There are many Certificate Authorities and options for certificates so you will need to find one that suits your needs best.

Create a PFX file

You will need to create a PFX file using the Pvk2Pfx command-line tool. This will create a PFX file from your pvk and spc files.

pvk2pfx -pvk <mypvkfile.pvk> -pi <mypassword> -spc <myspcfile.spc> -pfx <mypfxfile.pfx> -f
Click to copy

This will create a PFX file you can use to sign your app.

You can find more information in the Microsoft Documentation here.

Sign your app

Once you have your PFX file you can sign your app using SignTool.

SignTool sign /f <mypfxfile.pfx> /p <mypassword> /fd <digestalgorithm> <MyApp>.exe
Click to copy

You can find more information in the Microsoft Documentation here.

Checking the Digital Signature

Once you have signed your app you can check the Digital Signature by opening the Properties of the exe.

The unsigned app

Banners and Alerts

The app signed with a self-signed certficate

Banners and Alerts

Running the app

You can then check your signing by running the app on another machine. The first screenshot is the unsigned app, the second screenshot is the app signed with a certificate from a Certificate Authority.

Creating an installer

If you choose to create an installer for your app you would use the same process to sign the installer once it has been built.

  • Sign the app
  • Create the installer
  • Sign the installer


Dirk Beugeling

Sorry, but I don't understand:
where is the certificate stored?
In "Export-PfxCertificate -cert "Cert:\CurrentUser\My\" -FilePath .pfx -Password $password": what do I have to put in Certificate Thumbprint and Filepath ?
Please give an example!

Elanor Buchanan

Hi Dirk

The filepath is the path to where you want the exported certificated to be saved, this can be anywhere you choose. The thumbprint comes from the result of the command that created the certificate.

These steps use a Microsoft tool so I would recommend looking at the Microsoft Documentation for more details.

I hope that helps.

Kind regards


Dirk Beugeling

Thank you. After some digging, got it working:

Using the New-SelfSignedCertificate command in Powershell as administrator. Open powershell and run these 3 commands.

1) Create certificate:
$cert = New-SelfSignedCertificate -DnsName -Type CodeSigning -CertStoreLocation Cert:\CurrentUser\My

2) set the password for it:
$CertPassword = ConvertTo-SecureString -String "my_passowrd" -Force –AsPlainText

3) Export it:
Export-PfxCertificate -Cert "cert:\CurrentUser\My\$($cert.Thumbprint)" -FilePath "c:\cert.pfx" -Password $CertPassword

Your certificate cert.pfx will be located at C:\


If you only want SignTool and really want to minimize the install, here is a way that I just reverse-engineered my way to:

Download the .iso file from
The .exe download will not work, since it's an online installer that pulls down its dependencies at runtime.
Unpack the .iso with a tool such as 7-zip.
Install the Installers/Windows SDK Signing Tools-x86_en-us.msi file - it's only 388 KiB large.

you will now have the signtool.exe file and companions in C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\

SIGNTOOL COMMANDO in WINDOWS POWERSHELL (als Administrator starten):
cd ("C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\")


.\SignTool sign /a /tr /td sha1 /fd sha1 /f "C:\cert.pfx" /p aktivator "c:\yourfile.exe"

jeff k

The instructions in this lesson are fine for Windows users, but as a Mac user who can barely navigate Windows, it’s a non-starter. I’m probably not alone in this regard, so here’s the alternative that works for me.

As mentioned, it is necessary to purchase a code-signing certificate from a recognized Certificate Authority. Several LiveCoders have reported in our forums that they purchase this from K Software, which partners with Sectigo to provide competitively-priced certificates:

There are alternative sources, of course. But whether or not one purchases the certificate through K Software, the company provides a free utility for Windows – dubbed kSign – that makes code-signing a Windows .exe incredibly quick and simple. (The EULA does permit users who purchase a certificate elsewhere to employ kSign, although it may display a “nag” screen.)

Once the .exe has been code-signed, there is the issue of creating a Windows installer (.msi) file to distribute the application. Software vendor Caphyon provides a freeware version of its Advanced Installer tool that does create a functional installer:

The interface is rather complicated, but there is a tutorial that guides one through creating a simple (free) project. The finished .msi installer itself is not especially attractive graphically, but it can create a desktop shortcut along with installing the application, and when run again it can uninstall the app and shortcut. (Note: It does have a paid “analytics” feature – which I’ve never examined – that may or may not compromise the privacy of one’s end users. So just be aware.)

Once one has created the .msi installer, this too can be code-signed using kSign.

Hope this helps.

jeff k

Matthias Rebbe

there is another free InstallerMaker, called Innosetup.
As far as i know it only creates .exe installers and not .msi installers, but it is very easy.

jeff k

Matthias --
Folks who are comfortable with Windows and a scripting approach should indeed check out Innosetup, which has a long track record and good support. But frankly my eyes glazed over when I ran across it last year. Coming from a Mac background, even an inelegant GUI seems easier to navigate. (There do appear to be third-party GUIs for Innosetup, but that just adds an additional level of complexity to deal with.)

Matthias Rebbe

Jeff, i know. That's why i created a free Windows Wrapper/GUI for Innosetup.I called it InstaMaker. You just select the folder with your Livecode Standalone and the InstaMaker creates the installer. The Mac version of InstaMaker only creates a DMG. But i also created a Wine version of the Windows InstaMaker. So one was able to create the Windows installer on macos. Currently, due to the fact that it's some time ago that i created it, it only supports 32bit Windows standalones. But i am currently working on a 64bit version so 64bit installers for 64bit standalones are possible in near future.

Regarding Code signing for Windows. Did you know that you can code sign your Windows standalones also on MacOS? You need a 3rd party tool for it.
I've created a short doc about it here

The information it not completely current anymore. But the main information is.
Please be aware that SHA1 is not supported anymore and that the timeserver should be now
According to the documents of Comodo and Sectigo the time server automatically selects the correct protocol according to the selected hash algorithm

Add your comment

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.