A digital signature is used to help authenticate the identity of the creator of digital information. Digital signatures are based on digital certificates. Digital certificates are verifiers of identity issued by a trusted third party, which is known as a certification authority (CA). Digital signatures help establish the following authentication measures:

• Authenticity
• Integrity
• Non-repudiation

In the Digital Signature page you can sign your application. By digitally signing your installers and products in Advanced Installer, you will increase your user’s confidence in you and your company, giving them peace of mind about your software.

This may happen on a machine with OS lower than Windows 7 -> XP/Vista and if the application is signed using a SHA-2 digital signature. This is happening because the SHA-2 digital signature is recognized only from Windows 7.

Starting with January 1st, 2016 Microsoft is implementing a mandatory update of the Digital Signature system from SHA-1 to SHA-2 in order to deal with the decreasing security of the SHA-1 digital signatures.

All applications signed with SHA-1 certificates will still be accepted until January 1st, 2017. The UAC prompt will still show the correct vendor information but the browser, i.e. Internet Explorer, will warn the users about an invalid signature. Also, the Windows SmartScreen will not recognize the SHA-1 signature and try to prevent the users from running it.

Since not all CA vendors support SHA-2 timestamp for the SHA-2 digital signature you can still use a SHA-1 timestamp. However, all applications signed with a SHA-2 signature and a SHA-1 timestamp will be accepted until January 1st, 2017. After this date, you must use a SHA-2 timestamp for the SHA-2 signature.

The information displayed on the security dialog (UAC prompt) is collected from the digital signature of the package. In this particular case if you set the Description field from the Digital Signature Page it will display the correct package name.

It seems that SmartScreen Protection shows the above message when you try to run a newly released program or an application that has not yet established a reputation. Reputation is established by SmartScreen® service intelligence algorithms based on how an application is used by Windows and Internet Explorer users.

For details, check the passing the smart screen on Win8 when install a signed application? thread that debates this subject.

This can also happen if the setup package is signed with a SHA1-based certificate and timestamped after January 1st, 2016.

This problem occurs only if the SignTool.exe from Windows SDK v.7.0 or later is used to sign the package and the “File From Disk” option is enabled in Advanced Installer’s Sign EXE, MSI or MSP files with a digital signature. The package will appear as signed, but upon a closer inspection the certificate used in the signing process will be reported as invalid. Because of this, the “Unknown Publisher” message will be displayed on Windows Vista or above, during installation.

As a solution, Microsoft recommends importing the certificate in the system store and automatically use it from here everytime a package is being digitally signed, instead of manually selecting the certificate file. In this case, the option “Automatically get certificate from system store” should be used in Advanced Installer’s Digital Signature Page. Another solution, not recommended by Microsoft, is to use the SignTool.exe from an older version of Windows SDK along with the “File From Disk” option enabled in Advanced Installer Digital Signature Page.

When a package is installed, Windows caches the MSI by placing it in the Windows\installer folder. During this process, all the unnecessary information (including the digital signature) is removed in order to decrease the size of the file. When an uninstall is launched from “Add or Remove programs” or through the Uninstall shortcut, Windows Installer uses the cached MSI. Since this file doesn’t have a digital signature, the “Unknown Publisher” message will be shown. A solution for this is to make sure the user can uninstall the package only by launching the original file.

This error occurs when the signature from the .CAB or .MSI does not coincide with the one from the .EXE. This is an authentication security check done automatically by the .EXE boostrapper when the Enhanced User Interface is enabled.

If you need to sign the installation package outside Advanced Installer then you can select the EXE setup with resources next to it as a package type and sign both .MSI and .EXE.

There are several reasons why you may get this error:

• When the target machine has no internet connection and Windows Installer fails to verify online the digital signature. Since Windows installation is unable to contact the certificate provider that can verify the installer’s security certificate, it will prompt with that error during installation. This error sometimes disappears if you switch to using a different time stamp URL.
• When is not be possible to compute the digital signature. This usually happens when you are using a SHA256 certificate or a SHA256 signature algorithm as a digest algorithm at signing time. Setup packages signed with a SHA256 certificate or digest algorithm will not have their digital signature recognized on XP and Vista operating systems. There is an official Windows issue regarding the computation failure of SHA256 certificates on Vista operating systems. So, if your setup package still targets Windows XP and Windows Vista operating systems it is recommended to disable the option “Sign only for modern operating system (Windows 7 or newer)” from Sign EXE, MSI or MSP files with a digital signature.
• When the CAB file has a large size. On Windows XP and Windows Server 2003 there is an operating system bug which consists in the operating system inability to compute the digital signature of the large installation files. So, if your setup package still targets Windows XP and Windows Server 2003 operating systems, as a workaround you can package your installation files into multiple CAB files of a smaller size (e.g. 64 MB) by using our Multiple volumes option.

When you build an EXE setup package with resources inside our EXE bootstrapper checks at install time his signature and its embedded MSI signature. If there is a signature mismatch between the EXE and its embedded MSI file or the digital signature cannot be computed, then the above error will be spawned during installation after the [Install] button is pressed.

The signature mismatch may appear when the EXE setup package is signed outside of Advanced Installer. Since the MSI is embedded in the EXE, only the EXE will be signed and, therefore the MSI will remain unsigned. This will generate the conflict at install time.

Also, there are situations when may not be possible to compute the digital signature. This usually happens when you are using a SHA256 certificate or a SHA256 signature algorithm as a digest algorithm at signing time. Setup packages signed with a SHA256 certificate or digest algorithm will not have their digital signature recognized on XP and Vista operating systems and, thus the installation will fail. There is an official Windows issue regarding the computation failure of SHA256 certificates on Vista operating systems. So, if your setup package still targets Windows XP and Windows Vista operating systems it is recommended to disable the option “Sign only for modern operating system (Windows 7 or newer)” from Sign EXE, MSI or MSP files with a digital signature.

Starting with Advanced Installer 13.0 if you have Enhanced UI enabled and you built an EXE setup type without signing it from the Sign EXE, MSI or MSP files with a digital signature, the installation can end right after you click on [ Install ] button without any prompt or error dialog. This is the case of many developers that build the EXE installer without having access to the digital certificate. Then, when someone signs the EXE manually outside the Advanced Installer project, the MSI inside doesn’t get signed. Basically, when launching a signed EXE with an unsigned MSI inside it, this behavior occurs.

The workaround is to use any (dummy/test) certificate to sign the EXE from the Advanced Installer project at build time. This will also sign the MSI inside it and once signing the EXE with the correct signature afterwards, the MSI dummy signature will be kept. With both EXE and MSI inside it signed, you won’t get this behavior anymore.

This may happen when creating a test installation package and adding an empty file (its size is 0 KB) in the test project. The build error should be fixed if the empty file is removed from the project and a valid one is added.

This error appears when you’re trying to add an invalid PE file(i.e. EXE, DLL, etc.) to your package, and the binary has a broken certificate. Meaning the executable considers it exists but in reality is either missing or corrupted. The SignTool won’t allow you to add an executable with a broken signature.

This error happened because one or more of your binary files has already been signed and has an invalid digital signature. The SignTool cannot resign a file, so you must first remove its previous signature before using the tool. An excellent way to do this is presented by Martin Kunc in his blog post SignTool.exe returned error 0x800700C1.

This can happen when using “SignTool.exe” to sign the package if you only selected the “Windows SDK Signing Tools for Desktop Apps” feature when installing the Windows 10 SDK. The resolution is to also install the “Windows SDK for UWP Managed Apps” feature.

In order to achive this you can use the build events support. To sign the files before being packed, a pre-build event is required.

To sign the result .MSI package a post-build event is required. If the result setup package is an .EXE setup package, two post-build events are required:

• Use a post-build event to sign the MSI package and the CAB files. Also, make sure that you enable the “Execute this before EXE packing” option from the edit events dialog;
• Use another post-build event to sing the .EXE setup package.

Make sure that your certificate exists in the Member List of the Windows Root Certificate Program. To fix the issue follow the Import a Certificate tutorial and add your certificate in the Certificate Store of your target machines.

You are using an older version of the SignTool SDK that does not support SHA256 encryption. To fix this issue, you can install the latest version of the Windows Standalone SDK, or you could use Advanced Installer SignTool by going to File > Settings > External Tools > Digital Signatures and unchecking “Use an external tool”.

When using a USB token certificate our build process will trigger the USB password prompt multiple times. A prompt will be triggered each time the installation files are signed (setup files, CAB archive, MSI/EXE package, etc).

The only way to avoid the multiple certificate password prompt during build is to contact your certificate vendor and check if they have a Single password prompt per session option you can enable for your USB token.

For example you could use the “Enable single logon” option from SafeNet Authentication Client, a software for authentication management.

This error may occur if you are using a timestamp server URL that is no longer valid.

To get this fixed we recommend to use the DigiCert timestamp service url: http://timestamp.digicert.com

Files contained by the project can be signed before putting them into the final package.

The default implementation is to sign these files one-by-one.

There is also an optional Batch Signing which involves signing multiple files at once (in the same SignTool call) for speed improvement. This method has the drawback that during signing Advanced Installer may become unresponsive.

Batch signing can be activated through the following DWORD registry entry:

HKEY_CURRENT_USER\Software\Caphyon\Advanced Installer\Settings\UseBatchSigning

If this entry exists and its value is “1” then batch signing will be used. Otherwise, one-by-one signing will be used.

Even if batch signing is used there are multiple signing operations involved. For example, three signing operations are executed for a dummy test file to validate the selected digital certificate (e.g. it is not expired, it is of Microsoft Authenticode type – can be used to sign MSI and CAB files). Then there is one signing operation for all files (bulk signing) included in “Files and Folders” page, one signing operation for the CAB file, one for the MSI file and one for the EXE setup file (in case of EXE setup packages).

This is happening when the Cryptographic service provider (CSP) is invalid

This is happening when the Private key container (PKC) is invalid.

The list of all available cryptographic service providers (CSP) can be checked by executing certutil -csplist command:

Provider Name: Microsoft Base Cryptographic Provider v1.0
Provider Type: 1 - PROV_RSA_FULL

Provider Name: Microsoft Enhanced Cryptographic Provider v1.0
Provider Type: 1 - PROV_RSA_FULL

Provider Name: Microsoft Strong Cryptographic Provider
Provider Type: 1 - PROV_RSA_FULL

Provider Name: Microsoft Smart Card Key Storage Provider
CertUtil: -csplist command FAILED: 0x80090030 (-2146893776 NTE_DEVICE_NOT_READY)

CertUtil: The device that is required by this cryptographic provider is not ready for use.

Only providers of PROV_RSA_FULL type can be used for digital signature. Those are installed by default.
If an eToken is connected (and has been installed) you’ll see it’s CSP (ex. eToken Base Cryptographic Provider) in the list too.

One can check if the eToken fields are correct by executing certutil -csp “CRYPTO_PROVIDER” -key command with the below example output:

cbData: 17 ==> 40
eToken Base Cryptographic Provider:
  C25F5EC3CA53AEB0
  RSA
    AT_KEYEXCHANGE

  64DB908B84BD89FE [Default Container]
  RSA
    AT_SIGNATURE

CertUtil: -key command completed successfully.

Signtool.exe can only search for the most suited certificate under Current User\Personal or Local Machine\Personal stores. Certificates stored under Current User\Trusted Root or Local Computer\Trusted Root are not scanned by Microsoft’s Signtool.exe. Please make sure you place your certificate under the correct Personal store if you want to allow Signtool.exe to use the most suited certificate to sign your package.