- ClickOnce Security Overview
- Internet Explorer Security Settings Affecting ClickOnce
- Configuring ClickOnce Security Permissions
- Understanding and Managing Publisher Certificates
- Signing Application Updates
- User Prompting
- Trusted Applications' User Security Policies
- Trusted Publishers' Permission Elevation
- Adding Restricted Code Sections
- Securing the Application Based on User Roles
- Securing Access to ClickOnce Application Files on the Server
- Where Are We?
Signing Application Updates
An important security limitation to understand with ClickOnce is that you cannot deploy updates to an application that are signed by a different publisher certificate than the one that was originally used to sign previous deployments of the application. If ClickOnce sees that an update is available, but that the update is signed by a different publisher certificate than the one used to sign the version currently installed on the client machine, ClickOnce will disable the application and present the message box shown in Figure 6.19.
Figure 6.19 Changed Publisher Certificate Message
If you click the Details buttons to see the error, it will specify that the problem is, "The deployment identity does not match the subscription." This behavior was designed to protect the tamper assurances that were discussed earlier in the section ClickOnce Tamper Protection. If someone were to gain access to your published application directory on the server, he could introduce a virus or malware into one of the application files, and then just regenerate and re-sign the manifests with his own certificate. Because updates do not typically prompt users (unless elevating the permissions of the application beyond their current trust level), there would be no way for users to realize that they could be introducing the compromised application onto their machines. Disabling the application if the certificate has changed is designed to make it as safe as possible and not allow updates to be signed with a different publisher certificate from the original certificate.
As a result, if you do publish an update to an application from Visual Studio 2005 that is signed with a different certificate than the previous version, you will be prompted as shown in Figure 6.20 to ensure this is your intent.
Figure 6.20 Visual Studio Publisher Certificate Change Warning
If you do have a previous version of a ClickOnce application that users have installed and you need to put out a new version signed by a different certificate (perhaps your company changed names or was acquired by a new parent company), you will need to instruct users to launch the new version using the full URL to the deployment manifest on the server. This will force a fresh install of the application, and the new install will not be related to the old version at all. Before users do this, it is recommended that you have them uninstall the previous version first from the Add or Remove Programs item. If they do not, they will end up with two application installations. The old one will have the original program name (e.g., My Application), and the new one will have the old name with a – 1 appended to it (e.g., My Application – 1). This is likely to confuse users when they go to launch the application from the Start menu. Unfortunately, there is no way to automate this process. For online-only applications this is not a problem because if the certificate has been changed, it will just be treated as a new application being launched, and users will be prompted with the security warning again.