views:

157

answers:

3

Let's say we have version 2.0 of an application deployed with around 3000 users already running the application.

So far, the application was unsigned(signed by some auto generated certificate from VS).

The users are using .NET 2.0.

Now we would like to deploy a new version that will be signed using a certificate from tucows. One of the answers below indicates that in case we are targeting .NET Framework 2.0, changing a code signing certificate would "break" the identity of the application. What does this mean?

How can one add a new code signing certificate to existing deployment?

Notifying all the users to reinstall the application from scratch (or from a new URL) is not possible.

( EDIT: this was previous requirement, is not valid now:

I would like to ensure that the existing users will not be able to see the update at all (they should not receive notification that a new version is available), while all new users will receive the signed version when they are installing for the first time. Just signing the deployment should not be a reason to bother existing users. )

A: 

Yes, this will work 100%. The new signing will of course take affect if the program is downloaded again. The signing should not affect users with a current version though, only if the program is downloaded/updated.

If you have auto update, they will get it, however this is a reason to bug existing users, as it shows your application is now more secure as they know it now comes from you.

Kyle Rozendo
Thanks for you answer, I know it is possible. My question is how to accomplish this without bothering existing users, that means for example somehow just replacing the deployed dlls, manually editing version in manifest, somehow marking the signed version as "skip for update", deploying at a different URL or similar...
Marek
A: 

Hi,

As Kyle said, it will work if you're careful. (and of course publish the exact same version)

Caveat: The existing users need to have at least .NET 3.0 SP2 OR .NET 3.5 SP1.

Reason: Before this, the signature was considered part of the app's identity and changing it would break the app for the installed base of users.

But please try these things out for yourself, easy to do with a mini-project that you just keep publishing to a share on your own machine and try signing etc between releases.

andyhammar
This is not our case, majority of users are on .NET 2.0. How can we accomplish adding the certificate to the deployment in this case? What do you mean by "changing the signature would BREAK the app for the installed base?". In case we would like to add the certificate along with a new version (increment in version number), would that be a problem for .NET 2.0 users?
Marek
A: 

I just found an excellent post explaining the issue in depth:

This applies to both changing of certificate from temporary to a trusted certificate provider and to expired certificates.

They may receive the following error: + The deployment identity does not match the subscription.

The solution is also to let the .NET 2.0 users re-install the whole clickonce application, which is not feasible Another solution is to push .NET 3.5 SP1 as a prerequisite - which triggers reinstall anyway and is a huge download.

Link: http://social.msdn.microsoft.com/Forums/en/winformssetup/thread/1217520d-6dc4-4fb1-83d1-0fa148d60e5d

Breaking the app in case of .NET 2.0 means that the existing users will get an error when installing the update, or will not see the update at all.

It links to a post including source code that can fix the application for .NET 2.0 users: http://robindotnet.wordpress.com/2009/03/30/clickonce-and-expiring-certificates/

The update process lies within re-signing an intermediate update with a certificate with the same key as the expiring certificate, publishing the intermediate update that uninstalls the application and forcing an install of the new version.

Very painful!

Marek