We build our installer packages with Advanced Installer. In older releases, the tool used a .pfx certificate to code-sign the package and also handled embedding MD5 hashes in the installer, so everything worked together.
Our build team now wants to stop using a dedicated .pfx file and sign through signtool.exe on the build machine, with the private key kept in a remote KMS. I added signing to the pipeline, but installers produced this way are reported as corrupted during installation.
We are still using Advanced Installer 16, which does not appear to support the newer custom third-party signing workflow. I also tried disabling hashing in Advanced Installer and calculating the MD5 values in a PowerShell pipeline task, but that only prints the hashes rather than embedding them where the installer expects them.
What is the correct signing order or build configuration for this setup? Is there a way to configure the older .aip project so the MSI and CAB files are signed before they are packed into the final EXE?
3 Answers
A hash and a digital signature are different things. A PowerShell command that prints an MD5 value does not modify or embed anything in the installer; it only calculates a digest for you to inspect or store elsewhere. Advanced Installer’s package-building process may use hashes internally to verify embedded files, so signing or modifying those files afterward can invalidate the values it generated.
Also, MD5 is obsolete for security-sensitive integrity checks. If you have control over the design, use SHA-256 or stronger instead. Regardless of the hash algorithm, the build order still matters: finalize the files, sign the inner components, generate the package metadata, pack the EXE, and sign the outer package last.
The problem is probably that only the final EXE is being signed. An installer package can contain an MSI, CAB files, and other binaries, and those inner files need to be signed before the outer EXE is created. If the contents change after the package’s hashes or signatures are generated, the installer can detect the package as modified or corrupted.
With the older Advanced Installer version, one workable sequence is:
1. Use a pre-build event to sign every applicable binary in the project.
2. Use a post-build event configured to run before EXE packing, and sign the MSI and CAB files there.
3. Sign the final generated EXE as the last pipeline step.
A PowerShell script can invoke signtool.exe for each file. The key point is that the MSI and CAB signing must happen before they are packed into the final EXE, not after packaging. Upgrading from version 16 would be preferable, since it is very old and newer versions provide a more direct custom-signing option.
Advanced Installer uses signtool.exe under the hood, so changing from a certificate file to a KMS-backed signing operation is not automatically a problem. The important difference is when and which files are signed. Signing only the resulting EXE leaves the embedded MSI and CAB files unsigned, and signing them after the package has been created can invalidate the package’s expected contents.
If upgrading is impossible, build-event scripts are likely the practical workaround. If possible, test the complete sequence on a copy of the project and verify that the signatures on the MSI, CAB, embedded binaries, and final EXE are all present before testing installation.
We already sign the project files and the final EXE from the pipeline, but our post-build signing may be happening after the EXE has been packed. I only have the .aip file in source control and do not normally use the GUI. I am trying to determine how to set the post-build event to execute before EXE packing in the project configuration.