--- title: "Does loadUserProfile matter when an IIS app reads the CurrentUser certificate store?" description: "Does loadUserProfile matter when an IIS app reads the CurrentUser certificate store?" author: "Ashu Sharma ji" published: 2026-10-06 updated: 2026-10-10 canonical: https://www.mindstick.com/forum/162244/does-loaduserprofile-matter-when-an-iis-app-reads-the-currentuser-certificate-store category: "App Pool Identity" tags: ["iis", "Application Pool Identity", "Certificates"] reading_time: 3 minutes --- # Does loadUserProfile matter when an IIS app reads the CurrentUser certificate store? An application hosted in IIS needs to read a certificate from the Windows **CurrentUser** store. It works when I run it under my own account, but the behavior changes in the app pool, and I’m trying to understand whether the pool’s `loadUserProfile` setting is relevant. Does enabling it create the worker process identity’s user profile so the per-user certificate store is available, or is there another IIS-specific detail I should check? I’m also curious how this differs from placing a certificate in the machine-wide store. I’d prefer to keep the certificate scoped appropriately rather than changing settings blindly, so any experience with this setup would help. ## Replies ### Reply by Ashutosh Verma It can, but it helps to separate two questions: can the worker process *see* the certificate, and can it *use* the certificate’s private key? `CurrentUser` refers to the Windows identity running the IIS worker process—not the administrator who installed the certificate. The **Load User Profile setting** affects whether that identity’s profile is loaded, which can matter when the certificate is stored in its **CurrentUser\My store**. Changing the setting won’t make a certificate installed under a different account appear. If the certificate is visible but signing, TLS, or decryption fails, check **private key permissions** separately. The worker process identity needs access to the key; loading its profile does not grant that access. For a useful check, inspect the store from code running inside the application and confirm the worker’s actual identity. If the certificate is intended for a server application rather than a particular user, consider placing it in the **LocalMachine certificate store** and granting the application pool identity access to its private key. After changing the profile setting, recycle the app pool and test again. ### Reply by Erick Wilsom Yes, it can. IIS’s **Load User Profile** setting controls whether the application pool identity’s Windows profile is loaded. The **[CurrentUser certificate store](https://www.mindstick.com/forum/162244/does-loaduserprofile-matter-when-an-iis-app-reads-the-currentuser-certificate-store)** belongs to the process identity, so it is not automatically the store of the administrator who installed the certificate. If the profile is not loaded, code that expects certificates in that identity’s personal store may find the store empty or behave differently than expected. Enabling the setting can help when the application is meant to use certificates installed in the pool identity’s profile. Recycle the pool after changing it, and make sure the certificate was installed for the same **application pool identity** the app runs as. For many server-side applications, the more predictable option is the **LocalMachine certificate store**. The app can read from that store when its identity has the needed access. If the certificate has a private key, grant the pool identity permission to use it; loading the profile alone does not grant that permission. So, check both the pool’s profile setting and the store location your code opens. If you keep the certificate in CurrentUser, verify the store under the actual pool identity rather than under your own login. --- Original Source: https://www.mindstick.com/forum/162244/does-loaduserprofile-matter-when-an-iis-app-reads-the-currentuser-certificate-store Copyright © MindStick Software Pvt. Ltd. This Markdown version is provided for developers, AI systems, and offline reading.