ClickOnce is a Microsoft.NET technology that allows you to build an application that is easy to deploy in an enterprise environment. It has the added benefit of providing the capability of being self-updating. While we live in a society that places a strong emphasis on moving to the cloud, there are still instances in which developers need to push code to desktop and laptop computers, especially in an enterprise environment. Although ClickOnce has been around since Microsoft.NET 2.0, it is still a handy technology for desktop application deployments.
ClickOnce Makes Digital Signatures Easy
One great and often overlooked feature of ClickOnce is that it provides an easy way to sign a .NET assembly with a digital certificate. Instead of relegating to a command line to use a complex utility like signtool.exe that takes a number of parameters that are difficult to remember, a developer can sign an assembly with just a couple of clicks in the Visual Studio IDE.
Note that digitally signing an assembly is not the same as strongly naming an assembly. Strongly naming an assembly allows you to verify that the content of an assembly has not been changed when it is loaded. Digitally signing an assembly allows the operating system to verify the author of the assembly. Both digital signatures and strong names are incredibly important, but there is no trivial way to digitally sign an assembly using the Visual Studio IDE without using ClickOnce.
In an enterprise environment, digital signatures offer a huge advantage in endpoint security. It is incredibly easy to white-list signed applications using software such as Carbon Black or Airlock Digital. By denoting that all applications signed with a particular certificate are safe, you can take quite the burden off of your operations and security teams.
Windows Firewall May Pose Some Issues
You can also use digital certificates to automatically allow an application to open a specific network port on a machine without having Windows Firewall prompt for permission. However, you may run into issues if you are using the wrong version of the .NET Framework to compile your application, if you are using a SHA-256 certificate, and if you are running your application on a more modern version of Windows.
For example, you may run the application and find the Windows Firewall prompting for permission to allow the application to access the network. You’ll notice in the image below that the Publisher is unknown. This is, of course, an oddity considering that the assembly has been digitally signed.
If you dig through the build logs, you’ll notice that Microsoft Visual Studio invokes the SignFile task. This build task signs the assembly using a certificate of the developer’s choice. Thankfully, Microsoft provides some documentation regarding this build task.
The documentation indicates that SHA-256 certificates are only allowed on machines running version 4.5 or later of the .NET Framework. Additionally, if you compile your application against .NET 4.0 or below, the SHA-256 hash of the certificate will not get used. This mismatch will present complications that will ultimately prevent the Windows Firewall from determining the validity of the publisher.
The best solution to this problem? Compile against Microsoft.NET version 4.5 or later.