When working with HTTPS bindings or client certificate authentication in IIS 7.5 on Windows Server 2008 R2, you'll encounter situations where your application needs programmatic access to certificates stored in the Windows Certificate Store. Unlike Windows Server 2003 where winhttpcertcfg.exe provided a straightforward solution, the process in newer Windows versions requires understanding both the security model and IIS architecture.

Modern IIS versions use Application Pool Identities rather than NETWORK SERVICE for isolation. By default, these virtual accounts (like IIS APPPOOL\DefaultAppPool) don't have access to private keys in the certificate store.

Here's how to properly configure certificate access:

1. Locate the Certificate

First, open the Certificate Manager:

mmc.exe -> File -> Add/Remove Snap-in -> Certificates -> Computer account

Navigate to Personal -> Certificates and identify your target certificate.

2. Grant Private Key Access

Right-click the certificate -> All Tasks -> Manage Private Keys:

1. Click 'Add' and enter 'IIS AppPool\YourAppPoolName'
2. Grant 'Read' permissions
3. Optionally add 'NETWORK SERVICE' for backward compatibility

3. Verify Using PowerShell

For automation or verification, use this script:

$cert = Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Subject -match "yourcert"}
$rsaCert = [System.Security.Cryptography.X509Certificates.RSACertificateExtensions]::GetRSAPrivateKey($cert)
$fileName = $rsaCert.Key.UniqueName
$fullPath = "$env:ProgramData\Microsoft\Crypto\RSA\MachineKeys\$fileName"
(Get-Acl $fullPath).Access | Format-Table IdentityReference,FileSystemRights

For bulk operations or scripting:

certutil -verifystore My "SerialNumber"
certutil -store My "SerialNumber" | findstr /i "Unique"
icacls "%ProgramData%\Microsoft\Crypto\RSA\MachineKeys\<UniqueName>" /grant "IIS AppPool\AppPoolName":RX

• Ensure the certificate is in LocalMachine\My store
• Remember to restart IIS (iisreset) after permission changes
• For clustered environments, permissions must be set on all nodes

If you still encounter issues, check the cryptographic service provider (CSP) type. Modern certificates might use CNG providers which store keys differently:

# For CNG certificates
$cert = Get-ChildItem -Path Cert:\LocalMachine\My | Where Thumbprint -eq "YourThumbprint"
$key = [System.Security.Cryptography.X509Certificates.RSACertificateExtensions]::GetRSAPrivateKey($cert)
$keyPath = $key.Key.UniqueName
$fullPath = "$env:ProgramData\Microsoft\Crypto\Keys\$keyPath"

In Windows Server 2003, administrators commonly used winhttpcertcfg.exe to grant certificate access to service accounts. However, the process changed significantly with Windows Server 2008 R2 and IIS 7.5. Microsoft integrated this functionality directly into the certificate management console, but many administrators find the new approach less intuitive.

For IIS 7.5 applications, the identity accessing the certificate depends on your application pool configuration. Common scenarios include:

Application Pool Identity       | Service Account
-------------------------------|----------------
Default (Integrated Pipeline)  | IIS APPPOOL\YourAppPoolName
Classic Pipeline               | NETWORK SERVICE
Custom Identity                | YourDomain\YourCustomAccount

Follow these steps to grant certificate access in Windows Server 2008 R2:

1. Launch MMC (press Win+R, type mmc)
2. Add the Certificates snap-in (File > Add/Remove Snap-in)
3. Select "Computer account" and navigate to the certificate store
4. Right-click the target certificate > All Tasks > Manage Private Keys

The critical UI change is that you must first select the certificate before the "Manage Private Keys" option appears, unlike previous Windows versions where this was more prominently displayed.

For automation scenarios, use this PowerShell script to grant permissions:

$cert = Get-ChildItem -Path Cert:\LocalMachine\My -Thumbprint "YOUR_THUMBPRINT"
$privateKey = $cert.PrivateKey
$rsaCrypto = [System.Security.Cryptography.RSACryptoServiceProvider]$privateKey
$fileName = $rsaCrypto.CspKeyContainerInfo.UniqueKeyContainerName
$keyPath = "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\"
$fullPath = $keyPath + $fileName
$acl = Get-Acl $fullPath
$permission = "IIS APPPOOL\YourAppPool","Read","Allow"
$accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule $permission
$acl.AddAccessRule($accessRule)
Set-Acl -Path $fullPath -AclObject $acl

Scenario 1: "Manage Private Keys" option missing
Solution: Ensure you're viewing certificates in the Personal store and have selected an actual certificate (not the folder)

Scenario 2: Access denied after permission assignment
Solution: Check the certificate's private key location using certutil -store My and verify permissions on the actual key file in C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

• Always use the most specific application pool identity rather than NETWORK SERVICE
• Audit certificate permissions quarterly using Get-Acl PowerShell cmdlet
• Consider certificate expiration dates in your monitoring solution