[Setup]: SignTool

Valid values:	A name followed by zero or more parameters, space separated

Description:

Specifies the name and parameters of the Sign Tool to be used to digitally sign:

Setup
Uninstall and any temporary self-copies used by Setup, unless SignedUninstaller is set to no
Original source files if the [Files] section's sign or signonce flag is used

When Setup has a valid digital signature, users will not see an "unidentified program" warning when launching it.

Note: When Setup is started, it may use temporary self-copies. If you digitally sign Setup yourself after compilation, instead of using a Sign Tool, these copies are not signed by default. Security software can then block them from running, making Setup fail to start. One example is Microsoft Defender's Attack Surface Reduction (ASR) rule Block executable files from running unless they meet a prevalence, age, or trusted list criterion [external link] . If you can't use a Sign Tool, at least set SignedUninstaller to yes.

The specified Sign Tool name and its command have to be defined in the Compiler IDE (via the Tools | Configure Sign Tools... menu) or on the compiler command line (via the --signtool or -s option), else an error will occur. The name can't contain spaces or = characters.

The following special sequences may be used in Sign Tool parameters and commands:

$f, replaced by the quoted file name of the file to be signed. (required)

$p, replaced by the Sign Tool parameters.

$q, replaced by a quote, useful for defining a Sign Tool which contains quotes from the command line.

$$, replaced by a single $ character.

Assume the following Sign Tools have been defined in the Compiler IDE or on the compiler command line:

mystandard=signtool.exe sign /a /n $qMy Common Name$q /t http://timestamp.comodoca.com/authenticode /d $qMy Program$q $f
mycustom=signtool.exe $p
byparam=$p

then some examples would be:

Examples:

[Setup]
SignTool=mystandard

[Setup]
SignTool=mycustom sign /a /n $qMy Common Name$q /t http://timestamp.comodoca.com/authenticode /d $qMy Program$q $f

[Setup]
SignTool=byparam signtool.exe sign /a /n $qMy Common Name$q /t http://timestamp.comodoca.com/authenticode /d $qMy Program$q $f

;The [Setup] section may also list multiple SignTool directives which will be executed in order of appearance. This can be used to dual sign (SHA1 & SHA256) Setup and Uninstall:

[Setup]
SignTool=mycustom sign /a /n $qMy Common Name$q /fd sha1 /t http://timestamp.comodoca.com/authenticode /d $qMy Program$q $f
;the /as parameter in the following SignTool requires a recent signtool.exe version and a SHA256 (SHA-2) certificate
SignTool=mycustom sign /a /n $qMy Common Name$q /as /fd sha256 /td sha256 /tr http://timestamp.comodoca.com/rfc3161 /d $qMy Program$q $f

;Note: for security reasons you should give a unique name to any Sign Tool set to $p, and not use a byparam name copied from this example. Consider what happens if you #include a third-party file that says:

[Setup]
SignTool=byparam format c:

Further details on obtaining signing certificates and using code-signing tools are beyond the scope of this documentation.

Note: If you use a Sign Tool and your Setup contains a large amount of data, it is recommended that you enable Disk spanning with DiskSliceSize set to max. If you don't do this, the user might experience a long delay after starting Setup caused by Windows verifying the digital signature against all your data. There should be no security reduction from using disk spanning in practice: all files extracted from the unsigned .bin files undergo SHA-256 verification (provided dontverifychecksum isn't used). The SHA-256 hashes for this (along with all other metadata) are kept inside Setup's EXE, which is protected by the digital signature.

Alternatively, use the [Files] section flag download to download large files during installation instead of including them in Setup. Downloaded files don't undergo this verification. To verify them, also use the issigverify flag or the Hash parameter.