|
ewessely
Posts: 55
Joined: 2019-01-31
|
Hi,
I'm in the process of deploying my addin and having some issues with signing.
For signing I'm using an official EV codesigning certificate from Globalsign deliverd on a token.
Issue 1: No timestamp with SHA-1:
When selecting SHA-1, the output is only signed, but not timestamped. Doing the signing with signtool.exe the output is correcly signed AND timestamped - so I'm using the correct timestamp server (SHA-1 based: http://rfc3161timestamp.globalsign.com/standard as documented by https://support.globalsign.com/code-signing/dual-code-signing).
Signing with SHA-256 works as expected.
Selecting both will sign SHA-1 and SHA-256, but only SHA-256 is timestamped.
Issue 2: Setting signing options:
Changes to eg. SHA-1 vs SHA-256 reflected only to my dll.
The adxloader will stay on the previouse settings unless you: disable signing - rebuild (without signing) - switch on signing with new setting - rebuild (with signing)
Issue 3: Signing when publishing
I select my certificate from store but was not able to sign (certificate not found).
When selecting the certificate, the input box for the certificate is filled with the following information automatically:
Issued To: <my name>'s Digital Signature; Expiration Date: xx.xx.xxxx xx:xx:xx
Doing once more a "Select from Store" my certificate does not appear anymore (and also many others are not listed).
The Phrase "<my name>'s Digital Signature" seems to be the friendly name (setted by Globalsign) and NOT the real "Issued To" value.
Changing the name displayed here in "Issued To:" to the real value of the "Issued To" of the certificate, let me sign without giving the "Certificate not found" error and also when you click again on "Select from Store" all certificates are shown as expected.
Selecting SHA-1 and SHA-256 results in: The exe is signed SHA-1 without timestamp and SHA-256 with timestamp, the msi ist signed SHA-1 only and not timestamped (of course: I know that msi don't support dual code sign, but it should have been timestamped).
So - as workaround for me, I'll only use SHA-256 but the signing components in ADX seems to have some minor problems. Or am I doing something wrong here?
br
Erichew |
|
|
ewessely
Posts: 55
Joined: 2019-01-31
|
Further observed issues:
Issue 4:
When setting sign options (with SHA-256 only), the loaders, the dll and the manifest get signed and timestamped correctly. After that I create the msi and setup.exe with the installer project and also sign both.
When starting, the adxloader fails with Error code: 0x8009210d
Workaround: here: Build the addin WITHOUT signing and use adxpatch manually, build the installer then like before: AddIn works as expected.
Issue 5:
Using adxpatch in Post-build event does not work as expected: The loaders, manifest and dll get signed, but the loaders and the manifest gets overwritten after the signing done during the post-build event resulting in unsigned files.
Total workaround:
*)Build the AddIn without signing
*)Manually sign the build with adxpatch
*)Build setup
*)Sign msi and setup.exe (can be done in post-build of the installer-project
This workaround is far away from automation and using the features theoretically offerd by adx.
Any hints for what I'm doing wrong here are welcome.
PS: using an official EV Codesigning certificate is essential
br
Erichew |
|
|
Andrei Smolin
Add-in Express team
Posts: 18821
Joined: 2006-05-11
|
Hello Erich,
Do #1 and #2 describe issues that occur after you try to sign *and timestamp* the add-in after you signed it with no timestamp? If so, try to turn signing off and the sign and timestamp in a single go.
#3. We suppose the certificate name and friendly name are different. Will try to reproduce this.
ewessely writes:
Selecting SHA-1 and SHA-256 results in: The exe is signed SHA-1 without timestamp and SHA-256 with timestamp, the msi ist signed SHA-1 only and not timestamped (of course: I know that msi don't support dual code sign, but it should have been timestamped).
Will send you a download link for a non-public build soon; we can't reproduce these issues with it. Do you specify the timestamp server url for SHA-256 or SHA-1?
#4. Can it be that you signed the loaders after Add-in Express did this? Maybe you haven't signed the manifest? We would need to know the exact steps to reproduce the issue.
#5. As far as I know it isn't possible to influence the order of Post-Build events. As to adxpatch.exe, it should be specified in the Pre-Build event of the setup project.
Andrei Smolin
Add-in Express Team Leader |
|
|
ewessely
Posts: 55
Joined: 2019-01-31
|
Hello Andrei,
thank you for your reply.
Do #1 and #2 describe issues that occur after you try to sign *and timestamp* the add-in after you signed it with no timestamp? If so, try to turn signing off and the sign and timestamp in a single go.
ad #1: SHA-1 never get's timestamped
Steps to reproduce:
switch off signing, clear bin folder and rebuild (to have a consistent start)
switch on signing SHA-1 only and enter the timeserver
rebuild
Result: manifest, loaders and dll are signed but not timestamped
the second part of #1: (only SHA-256 gets timestamped)
Steps to reproduce:
switch off signing, clear bin folder and rebuild (to have a consistent start)
switch on signing SHA-1 and SHA-256 and enter both timeservers
rebuild
Result: manifest, loaders and dll are signed SHA-1 and SHA-256 but only the SHA-256 are timestamped
ad #2 switching between signing configurations (without switching signing off)
Steps to reproduce:
switch off signing, clear bin folder and rebuild (to have a consistent start)
switch on signing SHA-1 only and enter the timeserver
rebuild
intermediate result: manifest, loaders and dll are signed SHA-1 but not timestamped
go to signing options and select SHA-256, unselect SHA-1, remove timeserver for SHA-1 and add timeserver for SHA-256
rebuild
Result: dll signed and ts SHA-256 (expected), the manifest is signed (method I don't know) but the loaders stay on SHA-1
It seems that when switching the configuration something is not "cleared" or resetted in background. As I wrote: it's not a big deal. You just have to knwo it and take care of it when changing the signing option.
#3. We suppose the certificate name and friendly name are different.
Yes, exactly. "Issued To" and "Friedly Name" are different.
Unfortuinatly you have no chance to set these values by yourself when ordering the certificate at GlobalSign.
#4. Can it be that you signed the loaders after Add-in Express did this? Maybe you haven't signed the manifest? We would need to know the exact steps to reproduce the issue.
No. I just switched on signing SHA-256 + timeserver in the dialog from adx - nothing more.
#5. As far as I know it isn't possible to influence the order of Post-Build events. As to adxpatch.exe, it should be specified in the Pre-Build event of the setup project.
Good idea. The minor disadvantage here: you don't have access to the folder via a variable. So you have to hard-code the path to the manifest output of the addin project.
Best regards
ERichew |
|
Forums
Topics
Search
Help
Login
Register