Daniel's Blog At The End Of The Blog Sphere

ClickOnce and expired Certificates

danielma — Mon, 19 Mar 2007 02:05:00 GMT

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).

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?

sn -m n // switch to user based container
sn -c "Microsoft Enhanced Cryptographic Provider v1.0" // set the default CSP
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)
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:

Obtain the renewed / new certificate, sign and publish the application update on your server
Use cstore.vbs and figure out the key container of the expired publisher certificate and the hash of the new / renewed certificate
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

SiteMinder and ASP.NET

danielma — Wed, 16 Nov 2005 21:36:00 GMT

Some weeks ago I was integrating SiteMinder authentication within an ASP.NET application. Fortunately, this was not a big deal because the whole SiteMinder stuff is absolutely transparent to the ASP.NET application. The only thing what must be done (beside the installation and configuration of the Web Agent, Policy Server, etc, of course) is to extract the SiteMinder HTTP headers from the web request and construct a GenericPrincipal object which holds the identity of the authenticated user.

Process Description

User types the URL for an ASP.NET application into the web browser.
The SiteMinder Web Agent intercepts the request and checks its resource cache. If there is no information in cache about this resource (URL), the Web Agent then sends the request to the Policy Server, asking if the resource is protected.
The Policy Server responds indicating that the resource is protected.
The Web Agent forwards the request to a login page for challenging the user for their credential.
The Web Agent forwards the credentials back to the Policy Server for authentication and authorization.
The Policy Server authenticates the user against a directory. After verifying the user’s identity, the Policy Server checks rules in the Policy Store, where user entitlements are stored and grant the user access to the resource.
The Policy Server notifies the Web Agent that the user is authenticated and authorized for this resource.
The Web Agent constructs several SiteMinder HTTP headers with information about the authenticated user (userid), generates an encrypted session cookie and redirects the request to the original target URL.
The request reaches the ASP.NET application where the userid can be extracted from the SiteMinder headers for further processing.

Source Code of HTTPModule to Extract SiteMinder Headers

   1:  /// <summary>

   2:  /// This HttpModule is responsible for retrieving the SiteMinder headers from the web

   3:  /// request.

   4:  /// </summary>

   5:  public class SiteMinderModule : IHttpModule, IRequiresSessionState

   6:  {

   7:      /// <summary>

   8:      /// Required default constructor

   9:      /// </summary>

  10:      public SiteMinderModule()

  11:      { }

12:

  13:      /// <summary>

  14:      // Required Dispose Method

  15:      /// </summary>

  16:      public void Dispose()

  17:      { }

18:

19:

  20:      /// <summary>

  21:      /// Register for events that are handled within this module

  22:      /// </summary>

  23:      /// <param name="app">Application object</param>

  24:      public void Init(HttpApplication app)

  25:      {

  26:          app.PreRequestHandlerExecute += new EventHandler(Application_PreRequestHandler);

  27:      }

28:

29:

  30:      /// <summary>

  31:      /// This event occurs just before ASP.NET begins executing a handler such a aspx page.

  32:      /// We use this event to extract the SiteMinder headers from the request and construct

  33:      /// our principal object

  34:      /// </summary>

  35:      /// <param name="sender"></param>

  36:      /// <param name="e"></param>

  37:      private void Application_PreRequestHandler(Object sender, EventArgs e)

  38:      {

  39:          if (HttpContext.Current.Request.Headers["SM_USER"] != null)

  40:          {

  41:              // Get a collection of all available HTTP headers from the request

  42:              NameValueCollection coll = HttpContext.Current.Request.Headers;

43:

  44:              // Retrieve the userid from the SiteMinder header SM_USER

  45:              string smUser = coll["SM_USER"];

46:

  47:              // Create GenericPrincipal with authentication type "SiteMinder".

  48:              GenericIdentity webIdentity = new GenericIdentity(smUser, "SiteMinder");

  49:              GenericPrincipal principal = new GenericPrincipal(webIdentity);

50:

  51:              // TODO: Attach additional attributes to the principal object (e.g. from session

  52:              // object, DB, directory, etc.)

53:

  54:              HttpContext.Current.User = principal;

  55:              Thread.CurrentPrincipal = principal;

  56:          }

  57:          else

  58:          {

  59:              // Throw an exception, because SiteMinder headers are not available.

  60:          }

  61:      }

  62:  }

A future article will cover how to integrate .NET SmartClient applications with SiteMinder.

PDC 2005 ...

danielma — Sat, 27 Aug 2005 03:12:00 GMT

... and fortunately I'll be there, too. See you!

TechEd 2005 Europe ...

danielma — Fri, 27 May 2005 17:03:00 GMT

... I'll be there!

You can find me somewhere at the Ask The Experts booth. Feel free to visit me and to just say hello. If you make an evidence photo, I will post it on this blog...

I always known this ...

danielma — Fri, 27 May 2005 13:35:00 GMT

... I am a Gauntlet Adventurer!

I strive to improve my living conditions by hoarding gold, food, and sometimes keys and potions. I love adventure, fighting, and particularly winning - especially when there's a prize at stake. I occasionally get lost inside buildings and can't find the exit. I need food badly