Code signing error - but my exe is signed ???

[NewsArchive]

Trying to sha2-sign.

I can sign installer/uninstaller with no problems - but it shows sha256.

When I try codesigning my own exe (using #pragma in the script) I get an
error GEN1053. *But* the exe is signed ok although only with sha256.

If I sign the exe from the command line using /fd SHA512 everything is
fine (using signtool verify).

I've set #pragma CODESIGN_SHA = "2"

What am I missing?

Peter

[NewsArchive]

Peter,

> Trying to sha2-sign.
>
> I can sign installer/uninstaller with no problems - but it shows sha256.
>
> When I try codesigning my own exe (using #pragma in the script) I get an
> error GEN1053. *But* the exe is signed ok although only with sha256.
>
> If I sign the exe from the command line using /fd SHA512 everything is
> fine (using signtool verify).
>
> I've set #pragma CODESIGN_SHA = "2"
>
> What am I missing?

I think timestamping failed on your .exe and so you have a signature without
a timestamp (SHA256 is SHA-2, btw). The signature is worthless without a
timestamp. Check your firewall, anti-spyware and anti-virus software.

Friedrich

[NewsArchive]

Thanks Friedrich, but why is it then that if I comment out the signing
of my exe the uninstaller/installer both get signed and timestamped and
no error?

Peter

[NewsArchive]

Ok, so I ended up writing a .bat file (yup, in 2016) that does the
signing of all my exe's and dll's. Removed the code-signing from my SB
script so it only signs the installer itself. At least this gives me an
installer I can publish.

That's not the way it used to be and it's certainly not the way I expect
to work with SB.

Peter

[NewsArchive]

Peter,

> Thanks Friedrich, but why is it then that if I comment out the signing of
> my exe the uninstaller/installer both get signed and timestamped and no
> error?

If your code-signing configuration is correct in your #pragma (make sure you
are using the same timestamp server, etc.) then your protection software
(its real-time monitoring) does not like the Authenticode timestamp action.
Try to put your SignTool.exe to the exclusion list of your security
software.

Make sure that you are using a SHA-2 timestamp server for your SHA-2
signature! Do not use a SHA-1 timestamp server.

Friedrich

[NewsArchive]

Peter,

> That's not the way it used to be and it's certainly not the way I
> expect to work with SB.

Of course, that's not caused by SetupBuilder at all !!! SetupBuilder can
SHA-1, SHA-2 or dual SHA-1/SHA-2 code-sign your own application files and
the setup.exe/uninstall.exe. Not batch required.

Friedrich

[NewsArchive]

> Of course, that's not caused by SetupBuilder at all !!! SetupBuilder can
> SHA-1, SHA-2 or dual SHA-1/SHA-2 code-sign your own application files and
> the setup.exe/uninstall.exe. Not batch required.
>
Yeah I know, I'll have to play some more with it. I just needed to get
something out the door thus the quick fix.

Peter

[NewsArchive]

Peter,

>> Of course, that's not caused by SetupBuilder at all !!! SetupBuilder can
>> SHA-1, SHA-2 or dual SHA-1/SHA-2 code-sign your own application files and
>> the setup.exe/uninstall.exe. Not batch required.

> Yeah I know, I'll have to play some more with it. I just needed to get
> something out the door thus the quick fix.

Yes, I understand. But if your code-signature is incorrect (signtool.exe
does not check the signature or timestamp type) then I would not distribute
it. It might result in a support nightmare. For dual SHA-1/SHA-2
code-signing (to support legacy and modern Windows OS) you need a SHA-1
signature with a SHA-1 timestamp and a SHA-2 signature with a SHA-2
timestamp. For only SHA-2, you need a SHA-2 timestamp (and not a simple
SHA-1 one).

Friedrich

[NewsArchive]

I'm only doing SHA-2 and so far no support calls (I know it's being
used) but I keep my fingers crossed <g>.

I really appreciate all *your* support on these matters! I wish someone
would do a webinar on the various types of codesigning with SB
(hint-hint) - that would make a blockbuster!

Peter