Clickonce signs code with SHA1 when using SHA384 cert

George Waters 21 Reputation points
2022-04-20T03:51:59.967+00:00

I renewed my signing certificate and found out that it's a SHA384, this certificate signs my clickonce project as SHA1. I contacted Sectigo and they just told me that they don't provide SHA256 anymore.

According to Sectigo FAQS, they say I can request the timestamp as SHA256, but when doing it, Visual Studio 2019 says "An unexpected internal error has occurred". Either I request timestamp on 384 or I don't use timestamp server, the outcome is the same: signed as SHA1.

I have been looking for days and just can't find a way to solve this problem, at least, I need to sign my code in SHA256.

Windows Forms
Windows Forms
A set of .NET Framework managed libraries for developing graphical user interfaces.
1,816 questions
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. George Waters 21 Reputation points
    2022-04-20T03:54:27.217+00:00

    When using all timestamp servers in Visual Studio 2019, the outcome is the same (SHA1), but if I use signtool.exe from command line with the stampserver http://timestamp.digicert.com?alg=sha256, my exe file becomes signed with SHA384 !!!

    So far so good, but we're half the way, because the problem seems to be in mage.exe, if I run it from command line: 

    mage.exe -u "D:\AppName.application" -appm "AppName.exe.manifest" -Algorithm sha386RSA -cf "cert.pfx" -Password XXXXXXX

    The result is: Algorithm has to be sha1RSA or sha256RSA. Specified - "sha386RSA".
    If I switch to SHA256RSA, then manifests are still signed with SHA1.

    Now, according to this post there seems to be a bug in mage.exe, if certificate has a higher hash than SHA256 the internal logic signs with SHA1, instead of going down to SHA256.

    Any idea how to workaround this issue?

  2. Josef Bauer 1 Reputation point
    2022-08-16T19:02:54.177+00:00

    I had the same issue and found out that this bug in mage.exe has been fixed in Visual Studio 2022. I upgraded to VS 2022 17.3 and the deployment is now signed correctly using my new sha384 code signing certificate.

    Research regarding this problem brought me to issue 6732 from the MS developer team and it was marked as fixed in milestone VS17 which is VS 2022.
    https://github.com/dotnet/msbuild/issues/6732

    0 comments