2

I'm working on a ClickOnce application which now I want to sign with a certificate I got from Comodo, solely for the purpose of avoiding the "Unknown Publisher" warning (and now also the SmartScreen ban) when users install it.

I managed to sign the ClickOnce manifest at Project -> Signing -> Sign the ClickOnce manifests in Visual Studio. But wasn't able to sign the assembly by checking the Sign the assembly check box using my Comodo certificate due to several errors. Then I tested it with a test certificate generated by Visual Studio, and I got an error telling me "Assembly generation failed -- Referenced assembly 'blah.dll' does not have a strong name". So apparently, even if I was able to sign my assembly with my actual certificate, I'd need to sign the dll too.

Then I read here that you can sign your assemblies by entering something like this into the post-build command line: "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\signtool.exe" sign /f "$(ProjectDir)actual_cert.pfx" /p password /v "$(ProjectDir)obj\x86\$(ConfigurationName)\$(TargetFileName)". Which got rid of the non-signed referenced dll error too.

I published my application to a test location and all 3 (or 2?) warning dialogs showed my name as the publisher (I understand users would need to install my application several times to get rid of the SmartScreen thing). So everything seemed to be OK. Which is precisely what worries me, since the dll is not signed.

Is this a hack that will eventually backfire on me? Will the SmartScreen thing never go away even after users install my application several times because the dll doesn't have a strong name? Or is everything going to be OK? And if so, why wouldn't Visual Studio let you use an unsigned dll if it is actually possible.

Juan
  • 15,274
  • 23
  • 105
  • 187
  • I've only bothered with Authenticode signing using signtool and not with the click once manifests/strong naming. What files are you attempting to use signtool on? Does not signtool correctly sign your DLL? While I sign my DLL's, I notice it is only on the .exe's that I haven't signed that the browsers show a warning when downloading the file, or Windows shows a warning about Unknown Publisher. Not signing Dlls don't make a difference on whether these warnings appear. – David Ching Mar 10 '15 at 06:27
  • Yes, it seems to me too that it only shows the warning for the EXE and not for referenced DLLs. But I'm curious, [as any programmer would](http://imgur.com/l3aFizL), about why wouldn't Visual Studio let you reference unsigned DLLs while being able to do this if I sign it post-build using signtool. Like is something I shouldn't be doing for some reason. – Juan Mar 10 '15 at 19:05
  • I am not very familiar with signing assemblies in VS, because I use signtool primarily for signing my C++ exe's and DLL's. But it seems the problem there is you can't sign the DLL because it isn't strong-named? If you made it strong named, does it work? – David Ching Mar 10 '15 at 20:57

1 Answers1

1

signing the assembly and signing the click once manifest are really two different things. You are unable to sign an assembly that has unsigned references because that is how strong names work in .net and it would use a different tool (sn.exe) to do this on the command prompt

What is a "STRONG NAME" in .NET?

has a good answer to what it means to be strong named.

signing the click once manifest is really just adding the authenticode signature and is unrelated, generally you as a publisher would want your authenticode signed executable to also be strongly named to limit exposure to the dll being replaced.

So the reason why you can use signtool on your non-strong named assemblies is because that is not required by the tool but it is probably a good idea to do so regardless.

Community
  • 1
  • 1
Mark
  • 356
  • 1
  • 5