views:

409

answers:

3

We are working on creating an installation package for a WCF-based web service. The service uses message-level encryption via an installed certificate. I am trying to come up with an automated way to both install the certificate and set its permissions.

Currently, we are manually installing the certificate via the MMC snap-in. After it is installed, we need to find the file containing the installed certificate and modify the permissions so that the Network Service account can access it. The only way I know to find the file is to open the "...\Microsoft\Crypto\RSA\MachineKeys" folder (exact path differs based on platform) and identify the file with the most recent modified date.

I'm thinking we'll use WIX to create the installation package. WIX has a specific feature for installing a certificate, but I assume permissions will still be an issue. Is there some utility or API or other means to get the physical path for an installed certificate identified by the subject name (or similar).

Of course, maybe there's a more direct solution to this problem.

Thanks for any help with this issue.

A: 

Does the certificate need to be installed? Could you reference it from a PFX file or similar instead, negating any need for installation?

sascha
Thanks for replying, Sacha. No, it doesn't need to be installed.
Daniel Pratt
+1  A: 

Source: Least Privilege

There is no clean way to do that in managed code. The general procedure is:

  1. Select a certificate
  2. Create an RSACryptoServiceProvider object from the certificate's PrivateKey property
  3. Retrieve the UniqueKeyContainerName property.
  4. Search for this file name in the various locations where keys are stored. Thats under ApplicationData for user keys and CommonApplicationData for machine keys

If you want to do this in a custom action, I recommend you do this in C++. (Managed Custom Actions are most of the time not a good idea.)

If you only want to set ACLs, there are two tools that can do that for you:

  • WinHttpCertCfg.exe
  • The certificates tool included in WSE3

See the link for the details, hope this helps!

Jeroen Landheer
For managed custom actions I would say it depends. If you are installing a .net app that already has a launch condition requiring the .net framework you'll be ok. We have been using managed C++ custom actions in WiX for 2 years and are moving to their new DTF C# custom actions, never had problems.
Rob McCready
@Rob: I know that managed custom actions actually can work... but they are not supported. Rob Mensching (a leading member of the WiX team) has made a blog post explaining why this is unsupported: http://robmensching.com/blog/posts/2007/4/19/Managed-Code-CustomActions-no-support-on-the-way-and-heres
Jeroen Landheer
@Jeroen: DTF custom actions are not subject to the technical limitations noted in Rob's post mostly because they are run in a separate process. Recent builds of WIX include DTF project types.
Daniel Pratt
@Jeroen, the post you reference is older than the DTF post I made later. @Daniel Pratt is correct.
Rob Mensching
@Daniel Pratt and Rob Mensching: Thank you for clarifying that to me, I seemed to have missed that. Apologies for the confusion...
Jeroen Landheer
A: 

A certificate itself doesn't have permissions. It can be in either a user's certificate store, such as the MY, CA or ROOT stores. Or it can be in the computer's version of those stores. It sounds like you are also installing a private key along with the certificate. To make a private key accessible to a service, it should be installed to the computer's key store. If you doing the import manually via something like CryptImportKey, you should specify CRYPT_MACHINE_KEYSET when the key container is acquired with CryptAcquireContext.

Murray