SecureBlackbox 16: Accessing system certificates under restricted user accounts

Note: This article applies only to SecureBlackbox Legacy. For future development please consider using the latest version.

A number of applications running in restricted environments face the need to access certificates stored in system certificate stores. While having no problems with accessing the certificates themselves (for chain validation purposes, for instance), the use of the corresponding private keys is often not permitted to them. Examples of such applications include, but are not limited to, ASP.NET web applications, web services, and various network services.

Windows maintains a separate certificate store set for each user account, and one system-wide store set shared by all the user accounts. That is, each user account has its own copy of the MY, CA, and ROOT stores for keeping certificates for their own purposes (e.g., the authentication or validation of certain hosts) and also has access to the system-wide MY, CA, and ROOT stores that contain certificates common for all the user accounts (e.g., widely known root CA certificates, such as VeriSign or Thawte). Particular stores comprising the user-specific store set are often referred to as "current user" stores (from the point of view of the user account that uses them), while system-wide stores are known as "local machine" certificate stores.

In most cases, the ideal location for application-specific certificates is the current user store set. Usage of local machine stores is subject to certain security restrictions due to this store's importance to the health of the system. In particular, only accounts with administrative privileges can add or delete certificates from local machine stores; and only administrator accounts or accounts with explicitly granted permissions can use private keys associated with certificates residing in such stores. However, sometimes it is technically impossible to use current user stores with applications that should run under specific system accounts, such as NetworkService (e.g., ASP.NET websites); other examples also exist where the use of current user stores is unacceptable. Under such conditions, the local machine store set is the only in-system certificates location available for an application.

In order to make private keys associated with the certificates contained in local system certificate stores available for an application running under a restricted account, explicitly allow them to be used by this application. Follow the steps below to adjust the access rights:

  1. Install the certificate along with the corresponding private key to a local machine system store. This can be done with the use of MMC or the SecureBlackbox TElWinCertStorage component. You will need administrative rights for this procedure. Skip this step if you already have the certificate installed in the local machine system store.
  2. Download and install the Microsoft WinHttpCertCfg utility.
  3. Run the following command to allow the private key to be used from the AccountName account:
WinHttpCertCfg.exe -g -c LOCAL_MACHINE\Store -s "IssuedToName" -a "AccountName"

where Store is the name of the store, IssuedToName is the common name contained in the subject RDN of the certificate, and AccountName is the name of the system account.

For example:

WinHttpCertCfg.exe -g -c LOCAL_MACHINE\MY -s "EldoS Corporation" -a "ASPNET"

After execution of the above command the private key of the certificate should be accessible for applications running under the ASPNET account.

We appreciate your feedback.  If you have any questions, comments, or suggestions about this article please contact our support team at kb@nsoftware.com.