Hi guys,
I've spent the last 2 hours almost going crazy with this.
This is the situation:
I'm using the AI Professional Version and I have a package with two .exe files packaged inside the Installer (one Launcher and one Self-Updater).
These were manually signed by me with a OV certificate issued by Certum, using a card connected via USB reader (hence there is no way to move the certificate somewhere else) which requires me to enter a PIN.
Output format is single EXE with resources packaged inside using one CAB archive for all files.
So far, I just didnt sign the Installer at all and manually signed it afterwards and that worked great.
With the most recent Update to AI 23.1 however (I upgraded from 22.6), this doesnt work anymore - when running the installer there is a ".exe and .msi signature mismatch" error (the packaged exe files were signed with the same certificate).
I tried signing everything with the built in signing tool, but it just wont work.
"Built-In" requires me to manually punch in the PIN for every single file, and that's ok for the CAB and MSI files... but in the stage of creating the .exe file it just keeps asking for the PIN in a seemingly never-ending loop (I already checked, the Certum tool has the option for PIN caching in CSP enabled by default but it doesnt help).
I also attempted "Custom" with the windows sign tool delivered with visual studio, also doesnt change anything. It also asks me to keep entering the PIN in a seemingly endless loop when getting to the "creating exe" stage.
-Bulldog
Suggested Articles
-
TheBulldog
- Posts: 1
- Joined: Sat Sep 27, 2025 5:32 pm
Re: Digital Signture with Certum OV Problematic
Hello Bulldog and welcome to our forums,
If it worked for you in 22.6, it was a bug on our end. It shouldn't have worked.
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.
You can overcome this behavior by signing the package during the build operation. Since you cannot use your certificate, please note that you can create a test certificate that you can use during the Build operation for signing. You can either create by yourself the certificate, or you can let Advanced Installer to generate a certificate that will be used for signing at build time.
After build, you will further sign the installer with your certificate, of course, just the .EXE. No error should be displayed during installation.
Initially, the signature checking between MSI and EXE was an extra security measure that Advanced Installer was offering.
When you run the .EXE, the boostrapper will extract the MSI during installation. Someone, could open the MSI and make changes to it. If there would have been any changes made, the digital signature was broken. So, the security that was added in the boostrapper was to check if the EXE and MSI have same signature.
It seems there are cases when the setup is build on one machine and signing on another. Only the resulted EXE was signed. So, we had to add a new possibility, in case the EXE is signed but the embedded MSI is not signed, then we do not raise that error anymore (if during the build operation the setup (EXE and MSI) are signed).
There should be no issues with signing both the exe & msi (through Advanced Installer digital signature support at build time) with the self generated cert and then re-signing the resulting installer with a different certificate.
We recommend signing with your certificate in Advanced Installer, as this way CAB, MSI, and configuration files are signed, plus DLL files used in custom actions.
Hope this helps! Let us know if you have any questions.
Best regards,
Liviu
If it worked for you in 22.6, it was a bug on our end. It shouldn't have worked.
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.
You can overcome this behavior by signing the package during the build operation. Since you cannot use your certificate, please note that you can create a test certificate that you can use during the Build operation for signing. You can either create by yourself the certificate, or you can let Advanced Installer to generate a certificate that will be used for signing at build time.
After build, you will further sign the installer with your certificate, of course, just the .EXE. No error should be displayed during installation.
Initially, the signature checking between MSI and EXE was an extra security measure that Advanced Installer was offering.
When you run the .EXE, the boostrapper will extract the MSI during installation. Someone, could open the MSI and make changes to it. If there would have been any changes made, the digital signature was broken. So, the security that was added in the boostrapper was to check if the EXE and MSI have same signature.
It seems there are cases when the setup is build on one machine and signing on another. Only the resulted EXE was signed. So, we had to add a new possibility, in case the EXE is signed but the embedded MSI is not signed, then we do not raise that error anymore (if during the build operation the setup (EXE and MSI) are signed).
There should be no issues with signing both the exe & msi (through Advanced Installer digital signature support at build time) with the self generated cert and then re-signing the resulting installer with a different certificate.
We recommend signing with your certificate in Advanced Installer, as this way CAB, MSI, and configuration files are signed, plus DLL files used in custom actions.
Hope this helps! Let us know if you have any questions.
Best regards,
Liviu