Distribute Clickonce Application to Windows 8

Question

I have use a valid publisher code signing certificate for signing.

When the user download the setup.exe Windows 8 SmartScreen still alert the user, although the publisher is a valid one.

Now, after installation. Windows 8 SmartSreen will prompt another message "Windows SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk." and the Publisher is Unkown publisher.

Should I sign the assembly too? Why SmartScreen is still prompting when I have the valid certificate?

How can I sign the application exe, not the setup exe?

Answer 1

Should I sign the assembly too?

I suspect this is the problem. ClickOnce requires that its manifests are signed (you have no choice), but I don't think there is a requirement to sign the assemblies themselves (as you alluded to), but it's likely that Windows 8 does have this requirement.

Unsigned assemblies can be modified and any referencing assemblies will dutifully load and execute the code within them - no questions asked, hence a malicious entity could replace one or more of your assemblies on disk and compromise your application. ClickOnce allows for users with low system rights to perform tasks they wouldn't otherwise be allowed to perform, because the permission has been (implicitly) granted via the digital certificate (the cert used to sign the ClickOnce manifests which pre-exists on the target machine, or is trusted via a root cert on the target machine). Therefore by not signing the assemblies there is a weak link in the security chain, and it's likely that this has been tightened in Windows 8 (by default).

To sign as assembly see: How to: Sign an Assembly (Visual Studio)

NB. dotNet assembly signing is usually referred to as strong naming (the terms 'signing' and 'strong naming' seem to be used interchangeably in this context).

NB. A strong named assembly can only refer to other strong named assemblies, although they can be signed with different certificates. This might cause a problem if you have references to third party assemblies that are not strong named - this is rare as it is bad practice to release unsigned code, one option there is simply to sign the assembly with your own certifciate using sn.exe