Digitally sign packages - Code Signing¶

When you digitally sign a Self-Extracting package or installer (this is called code signing), you ensure end users that the code within this package they are to receive has not been tampered with or altered. Digital signing is based on Microsoft Authenticode® technology. This enables end users and the operating system to verify that program code comes from the rightful owner. With Paquet Builder, it is easy to sign your installer .exe files since Paquet Builder calls the necessary programs itself.

If you digitally sign your software, end users are generally presented with a digital certificate when your package is downloaded from the web to their system:

For signed packages or installers, the publisher's name is displayed. Your end users know that the .exe file is authentic, and has not been tampered with or altered.

For unsigned installer packages, Windows shows the following warning message:

If you would like to digitally sign your package, enable "Digitally sign my package" in Paquet Builder. Then, follow the steps below.

How to obtain a code signing certificate¶

You have to obtain a valid code signing certificate from a certificate authority (CA), a third party trusted by the industry, akin to a notary who handles electronic IDs. Comodo and Verisign are two examples of CA.

If you are interested in purchasing or renewing a certificate, please go to the Paquet Builder's My Account page and choose "Purchase a code signing certificate" in order to get a coupon code for applying the discount with K Software.

Code signing steps¶

You can digitally sign your package .EXE only if you have received your personal Software Publishing Certificate (SPC) and a private key (PVK) from a Certificate Authority; or a Personal Information Exchange file (PFX).

Paquet Builder calls an integrated code signing utility (GSignCode.exe available in the Paquet Builder's folder). No need to install third-party software: GSignCode is shipped with Paquet Builder. The result of the signing process is included in the compilation log.

Certificate Location¶

In order to sign the package .EXE file, Paquet Builder requires the location to your code signing certificate. It can be stored in an external file (.PFX) or in the Windows Certificate Store. You must select the certificate's location, and provide either the path to the PFX file, the certificate's subject name, or the certificate's thumbprint.

Personal Information Exchange file (PFX)¶

Specify the path to the Personal Information Exchange file you want to use to generate the digital signature for your package. This file type is given the .pfx extension.

To create a PFX file from a CER (or SPC) and PVK file, you need to use the pvk2pfx tool shipped in the Windows SDK. The PFX file combines your public and private keys into a single file. Example: pvk2pfx.exe -pvk MyPrivateKey.pvk -spc MyPublicKey.cer -pfx MyPFX.pfx -po your_password

Associated Password¶

If the Personal Information Exchange file is protected by a password, specify the password. Passwords are automatically hidden, however do not leave the password in your project if you plan to share the latter.

Certificate Subject Name¶

If your code signing certificate is available in the Windows Certificate Store, Paquet Builder can use it if you give the correct subject name. There should be only one certificate with that subject name in the store, otherwise an error will be raised.

Paquet Builder will first look for the certificate in the Current User store => Personal substore (this is the default one) and if not found, in the local machine store => Personal substore. If the certificate is somewhere else, please export it as a .PFX file.

Certificate Thumbprint¶

Same as before, but this time Paquet Builder will look for the certificate based on its unique thumbprint.

Learn more at https://msdn.microsoft.com/en-us/library/ms734695%28v=vs.110%29.aspx

Request For Permission to Use a Key¶

If the selected certificate is protected with a key, a dialog box "Grant or deny this application permission to use this key" can be displayed while signing. If you want to disable this dialog box, you must configure the certificate to allow Paquet Builder and GSignCode to use the key.

Signatures with SHA-256 and SHA-1 digests¶

It is now recommended to use signatures with an SHA-256 instead of an SHA-1 message digest. However, old Windows versions such as Vista or XP do not recognize SHA-256 signatures. In that case, it is possible to add two signatures to the package .EXE file: this is called "dual code signing".

In that case, it is recommended to use Paquet Builder on Windows 8 or higher to benefit from all code signing features!

You can also choose to sign your package with SHA-256 or SHA-1 only. But keep in mind that SHA-1 is being deprecated: http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-authenticode-code-signing-and-timestamping.aspx

Package Information URL¶

This URL is used in your digital certificate to link to a location you would like end users to visit in order to learn more about your product or company. If you do not specify a URL, then Paquet Builder will use the default one from the "About your package" page.

Force integrity check at startup¶

Enabling this option tells the operating-system that the installer package's executable file being loaded must be digitally signed. A flag will be set in the file header of the executable.

Digital Signature Timestamp¶

A timestamp is added to the package / installer, thus the embedded digital signature will never expire.

You should have an Internet connection on the system in which you are building the package. The GSignCode code signing utility requires an Internet connection in order to timestamp the package's signature, so check that your firewall does not block the outgoing connection.

By default, time stamping using RFC 3161 is automatically selected on Windows 8 or higher for SHA-2 signatures.

Two timestamp servers are used: an Authenticode-compatible server and a RFC-3161-compatible server. You can configure their URLs in the Environment Options.

Digitally sign the uninstaller if any¶

If enabled, Paquet Builder will use the same settings to digitally sign the uninstaller EXE file. This is highly recommended.

Digitally sign internal DLL files too¶

If enabled, Paquet Builder will use the same settings to digitally sign the internal runtime libraries your package uses temporarily. If not enabled, these DLL files will keep their original digital signature.

Use of SignTool¶

You can also work with Microsoft SignTool: in that case, you must to disable the Enable package size check option in "Protect Package Files". Otherwise, the following error will be raised: Package integrity check failed: the package has been truncated or corrupted, and it will close.