And that's why when we try to work with certificates to sign outcoming messages (COM+/Serviced Components) and we load them from the user storage it doesn't work if the user is not logged on. The COM+ service control manager does not load the user profile to improve performance. If we try to sign something, we need access to the private keys, this info is stored in the user profile, so we need the user profile loaded if our application is working with certificates stored in the user Storage.
We can choose any of these options:
- Call UserProfileAPI to load the user profile
- we have to change the implementation
- Create a dummy windows service to run under the same account. It works because windows services control manager loads the user profile, so the windows application has it already loaded
- Then we have to keep this service in mind, but we don't have to change the code.
- Configure the application to load the certificate from the machine storage instead of the user storage. We have to grant access to the account (if it is not an administrator account) to that certificate ( winhttpcertconf.exe tool or wse certificates tool )
- This is my favourite option 🙂
If we are running COM+ 1.5 (xp nd w2k3) we can also configure the com+ application to "run as an NT service" so the user profile will be loaded and it will work