How One Misconfigured Cert Template Broke Auto-Enrollment for 500 Devices

The Change That Seemed Harmless

A PKI administrator needed to update a certificate template. The requirement was simple: increase the key size from 2048-bit to 4096-bit for the “Computer Authentication” template used by all domain-joined machines.

The change was made on a Tuesday afternoon. By Thursday, 500 devices had stopped receiving new certificates. WiFi authentication started failing. Machine-to-machine communication broke. And it took another 48 hours to figure out why.

Here’s exactly what went wrong, how to diagnose it, and how to prevent it.

The Setup

Template Configuration Before the Change

Template: "Corp-Computer-Auth" (v3)
────────────────────────────────────
Purpose:         Computer Authentication
CA:              COMPANY-ISSUING-CA
Auto-enrollment: Enabled
Security:        "Domain Computers" → Enroll + Auto-Enroll
Key Spec:        AT_KEYEXCHANGE
Key Size:        2048 bits
CSP:             Microsoft RSA SChannel Cryptographic Provider
Validity:        1 year
Renewal:         45 days before expiry
Subject:         Built from AD (DNS name)
EKU:             Client Authentication (1.3.6.1.5.5.7.3.2)

The “Simple” Change

The admin modified the template to use 4096-bit keys. But they also inadvertently changed two additional settings:

Template: "Corp-Computer-Auth" (v3 → v4)
────────────────────────────────────────
- Key Size:        2048 bits
+ Key Size:        4096 bits
- CSP:             Microsoft RSA SChannel Cryptographic Provider
+ CSP:             Microsoft Software Key Storage Provider
- Key Spec:        AT_KEYEXCHANGE
+ Key Spec:        (blank - KSP doesn't use Key Spec)

The CSP change from a legacy provider to a KSP (Key Storage Provider) seems reasonable for modern crypto. But here’s the problem: many devices still running Windows 10 1809 and older couldn’t handle this combination during auto-enrollment.

AD CS vs. CLM: Capability Coverage

Each tool excels in its domain — together they provide full lifecycle coverage

AD CS = Issuance Engine

Templates, enrollment, renewal, key generation

CLM = Visibility Layer

Inventory, alerts, deployment, ownership, compliance

The Cascading Failure

Day 1: The Change

Tuesday 14:30 - Template modification saved
Tuesday 14:31 - AD replication begins (template stored in AD)
Tuesday 15:00 - All DCs have new template version (v4)
Tuesday 15:30 - First auto-enrollment cycle runs on some machines
               → New machines get: "The requested operation is not supported"
               → Existing machines: Still have valid v3 certificates (not yet renewing)

Day 2: The Spread

Wednesday - Auto-enrollment processing continues
  - Machines whose certs are within 45-day renewal window attempt renewal
  - Renewal uses NEW template (v4) → FAILS
  - Old cert still valid → No immediate impact
  - 12 machines in renewal window fail silently
  
Wednesday 16:00 - IT notices: 4 new machines can't join WiFi
  - Attributed to "image issue" — re-imaged machines
  - Re-imaged machines also fail (same template problem)
  - Attributed to "AD replication issue" — moved on

Day 3: The Avalanche

Thursday - More machines enter renewal window
  - 87 machines now failing auto-enrollment
  - WiFi failures increasing (EAP-TLS needs machine cert)
  - Some VPN connections failing
  - Helpdesk tickets spike: 34 tickets by noon
  
Thursday 10:00 - Network team investigates WiFi
  - NPS certificate: Valid ✅
  - Client certificates: Missing or expired ❌
  - Pattern: All affected devices missing recent certs
  
Thursday 14:00 - PKI team engaged
  - Template change discovered in AD change log
  - Root cause identified

Day 4-5: The Recovery

Thursday 15:00 - Template reverted to v3 configuration
  - But machines that already failed need manual intervention
  - 500 devices in various states of broken enrollment
  
Friday - Mass remediation effort
  - Force Group Policy refresh: gpupdate /force
  - Force enrollment: certutil -pulse
  - ~200 devices recover automatically
  - ~300 devices need certutil -delstore + re-enrollment
  - Some devices need reboot for CSP cache clear

Diagnosing the Problem

Step 1: Check Auto-Enrollment Events

# On affected machine, check auto-enrollment events
Get-WinEvent -LogName "Application" -FilterHashtable @{
  ProviderName = "Microsoft-Windows-CertificateServicesClient-AutoEnrollment"
  Level = 2,3  # Error, Warning
} -MaxEvents 20 | Format-Table TimeCreated, Message -Wrap

# Typical error seen:
# "Automatic certificate enrollment for local system failed to 
#  enroll for one Corp-Computer-Auth certificate (0x80090029 - 
#  The requested operation is not supported)"

Step 2: Test Template Enrollment Manually

# Try manual enrollment to reproduce the error
certreq -enroll -machine "Corp-Computer-Auth"

# Expected error output:
# CertReq: The requested operation is not supported. 0x80090029 (WIN32/TPM: 0x80090029)
# Certificate Request Processor: The requested operation is not supported.

# This confirms the template configuration is the issue

Step 3: Compare Template Versions

# Export current template configuration
certutil -ADTemplate "Corp-Computer-Auth" > current-template.txt

# Key fields to check:
# pKIDefaultCSPs - Which crypto providers are configured
# msPKI-Minimal-Key-Size - Key size
# msPKI-RA-Application-Policies - Key spec

# Check AD for template version/modification time
$template = Get-ADObject -Filter {displayName -eq "Corp-Computer-Auth"} `
  -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=company,DC=com" `
  -Properties *

$template | Select-Object Name, whenChanged, 
  @{N='Version';E={$_.'msPKI-Template-Schema-Version'}},
  @{N='MinKeySize';E={$_.'msPKI-Minimal-Key-Size'}},
  @{N='CSPs';E={$_.'pKIDefaultCSPs'}}

Step 4: Verify CSP Compatibility

# List available CSPs on the affected machine
certutil -csplist

# Check if the configured CSP is available
certutil -csptest "Microsoft Software Key Storage Provider"

# For legacy machines, check what they support
certutil -csptest "Microsoft RSA SChannel Cryptographic Provider"

Step 5: Check Enrollment Status on Scale

# Bulk check: Which machines have valid certs?
$computers = Get-ADComputer -Filter {OperatingSystem -like "*Windows*"} `
  -Properties Name, OperatingSystem

$results = @()
foreach ($computer in $computers | Select-Object -First 100) {
    try {
        $cert = Invoke-Command -ComputerName $computer.Name -ScriptBlock {
            Get-ChildItem Cert:\LocalMachine\My | 
              Where-Object {
                $_.EnhancedKeyUsageList.FriendlyName -contains "Client Authentication" -and
                $_.NotAfter -gt (Get-Date)
              } | Sort-Object NotAfter -Descending | Select-Object -First 1
        } -ErrorAction Stop
        
        $results += [PSCustomObject]@{
            Computer = $computer.Name
            OS = $computer.OperatingSystem
            HasValidCert = [bool]$cert
            CertExpiry = $cert.NotAfter
            DaysLeft = if($cert){($cert.NotAfter - (Get-Date)).Days}else{-1}
        }
    } catch {
        $results += [PSCustomObject]@{
            Computer = $computer.Name
            OS = $computer.OperatingSystem
            HasValidCert = "UNREACHABLE"
            CertExpiry = $null
            DaysLeft = -1
        }
    }
}

# Show machines without valid certificates
$results | Where-Object {$_.HasValidCert -eq $false} | 
  Sort-Object DaysLeft | Format-Table

The Root Cause: CSP vs KSP Incompatibility

The Technical Detail:
━━━━━━━━━━━━━━━━━━━━

CSP (Cryptographic Service Provider) - Legacy API
  ✅ Works on: All Windows versions
  ✅ Supports: AT_KEYEXCHANGE, AT_SIGNATURE
  ⚠️  Limitation: Max RSA 4096 with some CSPs, older API

KSP (Key Storage Provider) - Modern API (CNG)
  ✅ Works on: Windows Vista+ / Server 2008+
  ✅ Supports: Larger keys, ECC, modern algorithms
  ❌ Issue: Some enrollment scenarios on older OS fail
  ❌ Issue: TPM-backed keys may not support 4096-bit

The conflict:
  Template says: Use KSP + 4096-bit key
  Device has: Older TPM that maxes at 2048-bit for KSP
  Result: Enrollment fails with "operation not supported"
  
  Even on devices with capable TPMs:
  Template says: Use KSP (no Key Spec)
  Auto-enrollment logic: Expects Key Spec for renewal
  Result: Renewal of existing CSP-based cert fails

The Fix

Immediate: Revert Template

# Option 1: Revert via AD (PowerShell)
$templateDN = "CN=Corp-Computer-Auth,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=company,DC=com"

Set-ADObject -Identity $templateDN -Replace @{
    'pKIDefaultCSPs' = '1,Microsoft RSA SChannel Cryptographic Provider'
    'msPKI-Minimal-Key-Size' = 2048
}

# Option 2: Revert via certtmpl.msc (GUI)
# Open Certificate Templates console
# Right-click template → Properties → Cryptography tab
# Change to: RSA, Microsoft RSA SChannel, 2048-bit

Recovery: Force Re-enrollment

# For machines that already failed, clear the bad state
# Run remotely against affected machines

$affectedMachines = Import-Csv "affected-machines.csv"

foreach ($machine in $affectedMachines) {
    Invoke-Command -ComputerName $machine.Name -ScriptBlock {
        # Clear failed enrollment state
        certutil -delstore My "Corp-Computer-Auth"
        
        # Clear auto-enrollment cache
        Remove-Item "HKLM:\SOFTWARE\Microsoft\Cryptography\AutoEnrollment\AECache" -Force -ErrorAction SilentlyContinue
        
        # Force fresh enrollment
        certutil -pulse
        
        # Wait and verify
        Start-Sleep -Seconds 30
        $cert = Get-ChildItem Cert:\LocalMachine\My | 
          Where-Object {$_.Subject -like "*$env:COMPUTERNAME*" -and $_.NotAfter -gt (Get-Date)}
        
        if ($cert) {
            Write-Output "✅ $env:COMPUTERNAME - Certificate enrolled successfully"
        } else {
            Write-Output "❌ $env:COMPUTERNAME - Enrollment still failing"
        }
    }
}

Proper Approach: Safe Template Upgrade

How to SAFELY increase key size:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. Create NEW template (don't modify existing)
   Name: "Corp-Computer-Auth-v2"
   Key Size: 4096
   CSP: Keep the SAME as original (legacy CSP)
   
2. Test with pilot group
   Create security group: "PKI-4096-Pilot"
   Grant Enroll + AutoEnroll to pilot group only
   
3. Add pilot machines to test group
   Monitor for 1 week: successful enrollment?
   Check all dependent services (WiFi, VPN, etc.)
   
4. Gradual rollout
   Week 1: 50 machines
   Week 2: 200 machines
   Week 3: Remaining machines
   
5. Decommission old template
   Only AFTER all machines have new cert
   Revoke old template publishing

Prevention Checklist

Before ANY Template Change

☐ Document the current template configuration (export)
☐ Create a change request with rollback plan
☐ Test in lab environment first
☐ Identify all machines using this template:
    certutil -view -restrict "CertificateTemplate=Corp-Computer-Auth" -out RequestID
☐ Create a NEW template instead of modifying existing
☐ Pilot with <10 machines for 48 hours
☐ Verify dependent services work (WiFi, VPN, mTLS)
☐ Schedule change during business hours (not Friday afternoon)
☐ Have rollback ready (original template published as backup)

Ongoing Template Health Monitoring

# Weekly check: Auto-enrollment health across the fleet
$failedEnrollments = Get-WinEvent -ComputerName "CA-SERVER" -LogName "Application" `
  -FilterHashtable @{
    ProviderName = "Microsoft-Windows-CertificationAuthority"
    ID = 53  # Failed enrollment request
  } -MaxEvents 100

$failedEnrollments | Group-Object {$_.Properties[2].Value} | 
  Sort-Object Count -Descending |
  Select-Object Count, Name | Format-Table

# If any template shows increasing failures, investigate immediately

Template Change Impact Assessment

Change Type	Risk Level	Test Required
Key size increase (same CSP)	Medium	48-hour pilot
CSP change (legacy → KSP)	High	1-week pilot
EKU modification	High	Full regression
Validity period change	Low	Basic validation
Subject name format	Medium	Cross-service test
Security permissions	Medium	Enrollment verification
Crypto provider change	Critical	Full OS matrix test

---

About QCecuring

QCecuring monitors AD CS template health and auto-enrollment success rates across your device fleet. Our platform detects enrollment failures in real-time, alerts on template changes, and helps you maintain healthy certificate provisioning for all devices — preventing incidents like this one before they impact 500 machines.

Tags: AD CS, certificate template, auto-enrollment, certutil, PKI, Windows PKI, machine certificates, GPO, certificate provisioning, troubleshooting, CSP, KSP, enterprise PKI