ClickOnce and expired Certificates

ClickOnce and expired Certificates

  • Comments 4

As you may know, ClickOnce has an issue with application updates and expired certificates. This issue is documented in the following Knowledge Base article: KB 925521

Problem description

ClickOnce allows application updates only, if the updated application manifests are signed with the same certificate (publisher) as was used to originally sign the application manifests. However, most CA's like Verisign, and many enterprise customers own CA's generate new certificates with new key pairs and only the same common name (CN).
The certificate is used for the Authenticode signature element and for the strong name signature element of the manifest file to protect it against tampering, and to provide identity information for the trust manager. If the signing certificate expires and you publish an application update with a renewed certificate which has different keys, then the update will fail with the error message described in the KB article.

Problem solution

To avoid this issue, you need to use 2 different keys for signing: One key for the Authenticode signature - this is the private key from the new / renewed certificate, and one key for the strong name signature. Unfortunately, neither Visual Studio/Mage nor the sign tool (signtool.exe) from the .NET Framework SDK supports this kind of signing.

However, the Windows Server 2003 R2 Platform SDK (see reference below) contains a newer version of the sign tool with a new switch "/manifest" and with options to use different keys for signing! With this tool you can sign the ClickOnce manifests with different keys for each of the two signatures.

The following picture shows a manifest file which has been signed with two different private keys. Since the public key token has not changed, ClickOnce recognize it as a valid update. Compare this with your own .application file and you will notice that the public keys are identical (which means the same private key has been used for the two signatures). ClickOnce Application Manifest

The syntax of this tool is:

signtool sign /manifest /snkc <SN key container name> /sncsp "Microsoft Enhanced Cryptographic Provider v1.0" /sha1 <hash of publisher cert> <.application manifest file>

Example:

signtool sign /manifest /snkc {7E1383C4-8641-4089-9521-004D4007F21F} /sncsp "Microsoft Enhanced Cryptographic Provider v1.0" /sha1 D1545335AED57249E32DCC27E4F2513BD24676DE MyApp.application

{7E1383C4-8641-4089-9521-004D4007F21F}     is the name of the key container that contains the SN private key
D1545335AED57249E32DCC27E4F2513BD24676DE   is the hash of the valid publisher certificate used for the Authenticode signature

How to generate a SN key and store it into a key container?

  1. sn -m n                                                                           // switch to user based container
  2. sn -c "Microsoft Enhanced Cryptographic Provider v1.0"       // set the default CSP
  3. sn -k 2048 sign.pfx                                                           // generate a new key pair and store it into a key file (or use VS to create a password protected .pfx file)
  4. sn -i sign.pfx {7E1383C4-8641-4089-9521-004D4007F21F}  // import the key file into a key container (here a GUID is used as the name)

Note:

  • The SN key is identified by both the /SNKC and /SNCSP. In most cases, the CSP is "Microsoft Enhanced Cryptographic Provider v1.0", but you should substitute it with the actual CSP which contains the private key.
  • You need to sign both .application files (the root and the reference to the updated version), e.g. MyApp.application and MyApp_2_0_0_0.application

How to find these values (hash, key container, etc.)? In the platform SDK there is a tool called CStore.vbs which displays all these information. The location is: \Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Samples\Security\capicom\vbs


Approach for ClickOnce applications which are already deployed

If you have an already deployed ClickOnce application which publisher certificate has expired, and you need to publish an application update, you can use the following approach:

  1. Obtain the renewed / new certificate, sign and publish the application update on your server
  2. Use cstore.vbs and figure out the key container of the expired publisher certificate and the hash of the new / renewed certificate
  3. Sign your published ClickOnce application (both .application files) with the new sign tool with the key of the expired certificate and the hash of the renewed/new certificate:

signtool sign /manifest /snkc <SN key container name of expired certificate> /sncsp "Microsoft Enhanced Cryptographic Provider v1.0" /sha1 <hash of new publisher certificate> .application manifest file

After signing with the old key and the new certificate, the application updates seamless as you would expect it.

Security concerns in using a key from an expired certificate?

Well, what we are doing here? We are using a key to sign a manifest file. Yes, originally this key was associated with a certificate which now has expired. However, private key associated with a cert is normally not known to anyone, except the holder of the key. The holder of the key must take proper precaution to protect it, which he/she has been doing while the cert was still valid.

What is the difference to the "normal" SN key (sn.exe) usage? Does it have an assertion to vouch for its authenticity and revocation status? No, it does not! If your generated SN key is compromised today, you have no way to revoke it! So, what is the difference in using a key from an expired cert than in using a fresh generated SN key from beginning? A key is just a key! You have to make sure it is well protected and not compromised!


Summary

Nevertheless, this is not an official recommendation! The next version of ClickOnce / Visual Studio (Orcas) will solve this issue by design, and you don't need to use different signing keys. This article provides a solution if you are facing this issue today.

References

The "new" sign tool and cstore.vbs can be found in the Microsoft Windows Server 2003 R2 Platform SDK

Leave a Comment
  • Please add 2 and 8 and type the answer here:
  • Post
Page 1 of 1 (4 items)