Did the following ever happen, where a digital certificate is choose-able by hash? The post suggest the option was implemented in version 8.8 but I don't see it here in version "10.9.1 build 55086".
http://www.advancedinstaller.com/forums ... ate#p48325
I'm asking, and wondering if there are other improvements planned for the signing mechanism, because I've had to get very creative to enable signing within Advanced Installer. The assemblies I'm signing are for internal business use and we (developers) do not have code signing certificates... we just have the certificates issued to us on our smart cards, similar to all employees. I've had to write a C# executable named "signtool.exe" with all desired options (certificate hashcode, generic key usage code, description, etc.) and specify its use as the external "signtool.exe" tool used by Advanced Installer since the options I need to accomplish signing are not exposed by Advanced Installer's Digital Signature UI. I then had to create a bogus public/private key pair and specific its use in the UI just to make Advanced Installer proceed with signing operations. My workarounds are functional but that's a lot of working-around for such a seemingly mature product.
Suggested Articles
Re: Digital Signatures options and workarounds
A reply to my own question/suggestion (sorry) since I forgot to mention something on my mind...
Advanced Installer currently doesn't support signing of the native-code wrapper for Java products, with the reason given that the Java specification doesn't support this. This isn't entirely true. You can use the open-source "sign4j" project, included with "launch4j" to sign such native wrappers, which are basically self-extracting ZIP archives (what a JAR file is) with the up-front execution code replaced by a native assembly used to launch the contained JAR.
Advanced Installer currently doesn't support signing of the native-code wrapper for Java products, with the reason given that the Java specification doesn't support this. This isn't entirely true. You can use the open-source "sign4j" project, included with "launch4j" to sign such native wrappers, which are basically self-extracting ZIP archives (what a JAR file is) with the up-front execution code replaced by a native assembly used to launch the contained JAR.
Re: Digital Signatures options and workarounds
Hello,
First of all I apologize for my delayed answer. Lately we are quite busy.
- go to "Digital Signature" page and check the "Enable signing" option
- configure the digital signing options accordingly and, then uncheck the "Enable signing" option (in this way when you will build the project it will skip the signing step)
- on your build machine all you have to do is to manually check the "Enable signing" option or even simple you can use our "SetSig" command line option to set this flag in your project before building the project
This solution is also used by us in our application development environment.
Also, if you need to use different signing options than the ones we currently support on our "Digital Signature" page, then I'm afraid the only workaround is the one you've already used (by creating a wrapper EXE over the "SignTool.exe"). Currently, we support only the signing options from our "Digital Signature" page because these are the common requested by most of our users.
All the best,
Daniel
First of all I apologize for my delayed answer. Lately we are quite busy.
We didn't exactly add the mentioned improvement. What we really implemented in our newer versions of Advanced Installer was an option to choose the desired certificate to be used from system store. Currently, you can choose in our "Digital Signature page -> Use a certificate from system store" combo box, what certificate from system store to be used.Did the following ever happen, where a digital certificate is choose-able by hash? The post suggest the option was implemented in version 8.8 but I don't see it here in version "10.9.1 build 55086".
viewtopic.php?f=1&t=19839&p=48325&hilit=code+signing+certificate#p48325
If you don't have access to the signing certificates, then you can simply proceed like this:The assemblies I'm signing are for internal business use and we (developers) do not have code signing certificates... we just have the certificates issued to us on our smart cards, similar to all employees. I've had to write a C# executable named "signtool.exe" with all desired options (certificate hashcode, generic key usage code, description, etc.) and specify its use as the external "signtool.exe" tool used by Advanced Installer since the options I need to accomplish signing are not exposed by Advanced Installer's Digital Signature UI. I then had to create a bogus public/private key pair and specific its use in the UI just to make Advanced Installer proceed with signing operations. My workarounds are functional but that's a lot of working-around for such a seemingly mature product.
- go to "Digital Signature" page and check the "Enable signing" option
- configure the digital signing options accordingly and, then uncheck the "Enable signing" option (in this way when you will build the project it will skip the signing step)
- on your build machine all you have to do is to manually check the "Enable signing" option or even simple you can use our "SetSig" command line option to set this flag in your project before building the project
This solution is also used by us in our application development environment.
Also, if you need to use different signing options than the ones we currently support on our "Digital Signature" page, then I'm afraid the only workaround is the one you've already used (by creating a wrapper EXE over the "SignTool.exe"). Currently, we support only the signing options from our "Digital Signature" page because these are the common requested by most of our users.
Maybe such an improvement will be available in a future version of Advanced Installer. Thank you for your suggestion. Until then, as a workaround, you can use a pre-build event which will sign your Java products files.Advanced Installer currently doesn't support signing of the native-code wrapper for Java products, with the reason given that the Java specification doesn't support this. This isn't entirely true. You can use the open-source "sign4j" project, included with "launch4j" to sign such native wrappers, which are basically self-extracting ZIP archives (what a JAR file is) with the up-front execution code replaced by a native assembly used to launch the contained JAR.
All the best,
Daniel
Re: Digital Signatures options and workarounds
With regards to last your last comment, that is exactly what I did. I actually have two "Builds". The first signs my JAR, builds the wrapped JAR (exe), and signs the exe using sign4j. The signed wrapper then gets included in the main feature. The second build contains all other features, as well as the feature containing the wrapped JAR so as to install the Java Product's INI file with the install. There is some renaming and deleting of certain files that takes place at strategic points (via both build events and custom events) to ensure that the version of the wrapped Java Product (and accompanying INI file) left behind by an install, maintenance, or even rollback is the signed version.
Also added a custom action today to add a JVM parameter to the installed INI file, when the product is installed on Windows Vista, to disable true double buffering in the JVM (Swing API). Testing on a couple of machines running Vista, along with web searches, indicated that Vista has unexpected behaviors that gum up the JRE's ability to properly paint a JFrame as another JFrame is dragged over it.
I was a bit critical of Advanced Installer initially. There is a big learning curve, and there is room for improvement (goes for any project), but I'd say I'm a fan now!
Thanks Daniel!
Also added a custom action today to add a JVM parameter to the installed INI file, when the product is installed on Windows Vista, to disable true double buffering in the JVM (Swing API). Testing on a couple of machines running Vista, along with web searches, indicated that Vista has unexpected behaviors that gum up the JRE's ability to properly paint a JFrame as another JFrame is dragged over it.
I was a bit critical of Advanced Installer initially. There is a big learning curve, and there is room for improvement (goes for any project), but I'd say I'm a fan now!
Thanks Daniel!
Last edited by jeffb on Wed Apr 23, 2014 12:15 pm, edited 1 time in total.