This is quite strange story... but I decided to publish this post because I didn't find any proper solution anywhere; and I mean it ANYWHERE!

It begins like that: I am running an asp.net 2.0 web application that as part of its work, it has to communicate 3rd party assembly, which suppose to retrieve some validation data. Until here everything is just fine right?

In order to invoke the 3rd party service (using an API of course), there is a need to install a X509Cerificate with 'secret' password and to install it on the server that runs the web application. After doing it you must  impersonate the ASP.NET process with the logged-in user that installed the certificate in order to 'grant' this user permission (administrator) to the current context of the web application.

Note: the user credentials will be kept in the web application web.config encrypted of course.

When running this application in my dev box, everything was working just fine, but when done with unit testing and was ready to QA, only when the user that installed the X509Certificate was logged in to the system (windows) the access to this specific certificate could be done. When the user was logged off, the Initialize method that initializes the certificate, couldn't find it in the CurrentUserStore:

public void Initialize(some parameters...)
{
   X509CertificateCollection certificates;
   X509CertificateStore store = X509CertificateStore.CurrentUserStore("My");
   
   store.Open();
   certificates = store.FindCertificateBySubjectName("<subject>");
   if (certificates.Count <= 0)
   {
      throw new Exception("<message>"));
   }
}

I admit that I didn't have any clue of how solving this acute problem, which of course stuck all the process of dev.

After consulting with some colleagues, we decided to try a 'detour solution', that will raise the user up into the system (will keep it alive, unlike doing log off to the user that terminates it from the OS).

Finally the solution (what you've waited for of course): 

We created a blank window service (with an installer) that actually does nothing, complied it and installed it in the QA server. Now here is the catch: First, the window service's startup type is set to Automatically (will be started always when the OS is up). secondly we adjusted the service's log on to a specific account that held the credentials of the user that installed the certificate of course. The purpose of this action is to keep this user up all time in order let our 3rd party application find its certificate in its store.

Outcome - it is working smoothly like magic. We can continue working...