How to Identify the Original Server When CSR and Private Key Mismatch Occurs in IIS/Win2008R2 Environments


2 views

Ever been in this situation? You generated a Certificate Signing Request (CSR) months ago on one of multiple Windows Server 2008 R2 machines, and now you're staring at the CA's response with no clue which server holds the matching private key. Here's how I troubleshooted this recently:

First, check the certificate enrollment requests store:

certmgr.msc → Certificates (Local Computer) → Certificate Enrollment Requests → Certificates

If you spot your CSR there with its private key, you've found the source server. But what if IIS won't complete the request properly?

When running:

certreq -accept -machine "c:\cert.crt"

You might encounter:

Certificate Request Processor: Cannot find object or property. 0x80092004 (-2146885628)

In my case, comparing certificate metadata revealed the issue:

# PowerShell to compare CSR and certificate subjects
$csr = Get-ChildItem -Path Cert:\LocalMachine\Request | Where-Object {$_.Subject -match "yourCN"}
$cert = Import-Certificate -FilePath "cert.crt" -CertStoreLocation Cert:\LocalMachine\My
Compare-Object $csr.SubjectName.RawData $cert.SubjectName.RawData

Option 1: Rekey the certificate if possible

Option 2: Export/import the private key manually:

# Export from source server
certutil -exportPFX -p "password" My "cert_thumbprint" cert.pfx

# Import on target server
certutil -importPFX -p "password" -f cert.pfx

Always document CSR generation with:

# Create a tracking log
Add-Content -Path "C:\CSR_Log.txt" -Value "$(Get-Date) - Generated CSR for $subject on $env:COMPUTERNAME"

In Windows Server environments, particularly when working with IIS on 2008R2, administrators frequently face the problem of losing track of which server generated a specific CSR. This typically occurs when:

  • Multiple servers have similar configurations
  • CSRs were generated months before receiving the CA response
  • No documentation exists about the CSR generation process

Here's the methodology I developed through troubleshooting:

# First, check Certificate Enrollment Requests on suspected servers
certmgr.msc → Certificates (Local Computer) → Certificate Enrollment Requests → Certificates

This MMC snap-in approach helps visually identify the private key association. For programmatic checking:

# PowerShell command to list pending certificate requests
Get-ChildItem Cert:\LocalMachine\Request

The initial approach might fail if:

  • The CA response doesn't match your CSR (verify Issued To fields)
  • IIS loses track of the original key container
  • Permission issues prevent access to the private key

For the specific certreq error (0x80092004), try this alternative approach:

certreq -accept -machine "C:\cert.crt" -config "CA_HOST\CA_Name"

To avoid this situation in future deployments:

# Create a tracking system for CSRs
$csr = New-CertificateRequest -Subject "CN=example.com" -Exportable
$csr | Export-Clixml "\\fileshare\csr_$(hostname)_$(Get-Date -Format yyyyMMdd).xml"

If you absolutely need to extract keys from an existing certificate:

# Export certificate with private key (requires mmc)
certmgr.msc → Right-click certificate → All Tasks → Export
# Select "Yes, export the private key" and choose PFX format

Remember that certificate management in Windows Server 2008R2 has particular quirks compared to newer versions. The CNG key storage provider introduced in later versions makes key management more straightforward.