Signtool error 0x80070057 attempting to RE-SIGN a bootstrapper setup.exe file after changing the bootstrapper -url value by Keith Dorken

We are facing same error.

we just embed manifest using "mt" command.
Then we are just signing setup.exe at the end of build process using signtool.

We tried to sing it without embedding manifest but same error. In short, even without doing any change in setup.exe, signtool is giving same error.

we are able to sign all other files without any error.

We have vs2008 sp1 and targeting .net 3.5 sp1.

is there any solution/workaround to this problem?

The deal here for most developers using ClickOnce is that they are trying to release an application which needs some specific customizations done before it can be deployed on to their customers servers. This is the typical case where a ClickOnce application is being built for resale and generally in these cases it is required that this customization process be automated because of the volume of deployments that need to be customized.

Desired Capabilities:
Be able to build a complete ClickOnce application deployment that can be signed at the time it is built and then sold to our customers. At the time the customer installs the application on their server the customer will need to customize the ClickOnce update URL and possibly the name of the application amongst other values. All of these customizations need to occur without invalidating the original signing that was done when the application was built since our customers will not be willing to fumble around with purchasing and maintaining code-signing certificates and we are definitely not willing to embed such certificates into the server-side installer.

Current Capabilities:
We can sign the application when it is built. We can also customize through scripts (although near impossible for the bootstrapper) parameters that were embedded during the build however doing so requires that we basically undo the signing that was done at build time and then attempt to resign it. In order to get this to work we would have to make specialized installer packages for each one of our customers otherwise they would have to maintain a code-signing certificate.

I've tried many ideas/hacks/workarounds to get the desired results but so far I've settled on just resigning the manifests with a meaningless self generated certificate and to not worry about the bootstrapper singing after it is invalidated. This allows me to make all of my customizations but makes all of our applications untrusted.

Below are some links to the things I've tried to work around this issue.

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=423026

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=519149

http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/080df9e2-05a8-46cb-b932-44c5e0258c49

Hi Keith-
I've spoken with the team that provides us with the signtool and they said that this is a known issue. They have provided me with the following information and a possible workaround:

Why can't I re-sign an Authenticode signature if the old signature has been corrupted?

    The second signing may be confused if the certificates directory does not match the structure in which the authenticode signature resides.

    Following are possible scenarios:

    •         The resources section was expanded and overwrote a portion of the data where the certificates directory says the Authenticode signature is located. If we “cleaned up” the certificates directory as specified, then added a new signature, the update to the resources section could be stomped.
    •         If we simply added a new signature without cleaning up the old signature, we might leave some garbage data behind
    •         Or the file may just be corrupted. In such a case it is better not sign, for a number of reasons.


    Due this ambiguous state, Authenticode fails, and leave it up to the user to not try to sign corrupted files.

What do I do to fix a corrupted signature?

    In all solutions you must update your build process. You have a few options (in descending order of preference):
    1)     update your build process so that you do not sign the file until after you have done all processing on the file (preferred - but may not be possible).
    2)     Remove the Authenticode signature prior to processing the file , as it will be invalidated anyway (customer can create a cmdline app that calls ImageRemoveCertificate http://msdn.microsoft.com/en-us/library/ms680214(VS.85).aspx to remove the signature.
    3)     Update the processing tool to remove the signature, then resign the file later.


Please let me know if you still have further questions.

Thank you,
Lisa Rugen
Windows SDK Program Manager

Thanks for reporting this issue. We are escalating this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team