Certificate Autoenrollment Failing: Event 13 and CAPI2 Diagnostic Errors

What You’re Seeing

It is 08:30 on a Monday morning when the service desk ticket queue begins accelerating. Workstations across a corporate branch office are dropping off the 802.1X authenticated wireless network, returning generic network policy handshake errors. Concurrently, newly provisioned Windows application servers fail to bind their TLS endpoints, and administrators logging into tier-1 jump boxes discover that smart card authentication is failing with invalid certificate status alerts.

When you inspect the Application event log on an affected Windows workstation or member server, the symptom presents as a recurring pair of error events from the CertificateServicesClient-AutoEnrollment source, logged every eight hours or immediately following a Group Policy refresh:

# Application Event Log - Event ID 13
Log Name:      Application
Source:        CertificateServicesClient-AutoEnrollment
Date:          10/5/2026 08:15:22 AM
Event ID:      13
Task Category: None
Level:         Error
Keywords:      Classic
User:          SYSTEM
Computer:      WORKSTATION-42.corp.example.com
Description:
Certificate enrollment for Local system failed to enroll for a WorkstationAuthentication certificate with request ID N/A from ca01.corp.example.com\Corp-Issuing-CA (The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)).

# Correlated Event ID 6
Log Name:      Application
Source:        CertificateServicesClient-AutoEnrollment
Date:          10/5/2026 08:15:22 AM
Event ID:      6
Task Category: None
Level:         Error
Keywords:      Classic
User:          SYSTEM
Computer:      WORKSTATION-42.corp.example.com
Description:
Automatic certificate enrollment for local system failed (0x800706ba) The RPC server is unavailable.

In other scenarios, the error description in Event 13 shifts to different Win32 status codes that identify distinct breakdown stages:

# Variant A: Permission or DCOM failure
Description: Certificate enrollment for Local system failed to enroll for a Computer certificate with request ID N/A from ca01.corp.example.com\Corp-Issuing-CA (Access is denied. 0x80070005 (WIN32: 5 ERROR_ACCESS_DENIED)).

# Variant B: CA template mismatch
Description: Certificate enrollment for Local system failed to enroll for a WebServer-Internal certificate with request ID N/A from ca01.corp.example.com\Corp-Issuing-CA (The requested certificate template is not supported by this CA. 0x80094004 (-2146877436 CERTSRV_E_UNSUPPORTED_CERT_TYPE)).

# Variant C: Missing directory attribute
Description: Certificate enrollment for Local system failed to enroll for a UserEncryption certificate with request ID N/A from ca01.corp.example.com\Corp-Issuing-CA (The email address is empty and cannot be found. 0x80094812 (-2146875374 CERTSRV_E_SUBJECT_EMAIL_REQUIRED)).

What It Actually Means

Think of certificate autoenrollment as an automated, background courier service operating inside every Windows client. Every few hours, the courier checks your computer’s wallet (the Local Computer Certificate Store), reviews company regulations (Active Directory Group Policy), checks the corporate directory for approved passport offices (Enterprise CAs in Active Directory), and submits paperwork over a private radio channel (DCOM/RPC) to obtain new identification before existing credentials expire.

If the courier discovers that the passport office listed in the directory was demolished two years ago, or the radio channel is blocked by a border gate (firewall), or the passport office denies entry because the security guard does not recognise your badge (DACL permissions), the courier drops the request and writes a failure slip into the event log.

Architecturally, autoenrollment is not a monolithic protocol. It is an orchestration pipeline coordinated across three distinct operating system components:

# Autoenrollment execution and verification pipeline
[Group Policy Engine]
       │
       ▼ (Configures registry triggers in HKLM\SOFTWARE\Policies\Microsoft\Cryptography\AutoEnrollment)
[Autoenrollment Client Task]
       │
       ├── 1. LDAP Query (TCP 389/636) ──────▶ [Active Directory Domain Controller]
       │      • Reads CN=Certificate Templates,CN=Public Key Services...
       │      • Reads CN=Enrollment Services,CN=Public Key Services...
       │
       ├── 2. Template DACL Evaluation ────────▶ Evaluates client Kerberos token against (Read, Enroll, Autoenroll)
       │
       ├── 3. DCOM / RPC Binding (TCP 135/Dynamic) ▶ [Enterprise Certification Authority]
       │      • Submits PKCS#10 / CMC Request via ICertRequestD2
       │      • CA validates template, signs certificate, returns X.509 payload
       │
       └── 4. CryptoAPI (CAPI2) Validation ──▶ Validates trust chain against AIA and CDP (HTTP/LDAP)
              • Installs certificate to Cert:\LocalMachine\My

When Event 13 occurs, one of these distinct four phases has broken:

1. Active Directory Discovery & Policy: The client queries LDAP for available Enterprise CAs published under CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=example,DC=com. If an administrator decommissioned an old CA by turning off the virtual machine without running certutil -dsDel, clients will continue attempting to contact the ghost CA, timing out with 0x800706ba.

2. Template Authorisation & Capability: Every template possesses a Discretionary Access Control List (DACL). For a machine to autoenroll, its security principal (e.g. Domain Computers) must possess three explicit rights: Read, Enroll, and Autoenroll. If Autoenroll is omitted, the engine silently skips the template. If Read or Enroll is denied, the client throws 0x80070005.

3. RPC/DCOM Transport Handshake: The client connects to the CA’s RPC Endpoint Mapper on TCP Port 135, negotiates an ephemeral dynamic port in the range 49152–65535, and initiates an authenticated DCOM session via the ICertRequestD2 interface. Any stateful firewall, NSX segment filter, or host-based firewall blocking dynamic RPC ports terminates the handshake with 0x800706ba (RPC_S_SERVER_UNAVAILABLE).

4. CAPI2 Trust Verification: Once the certificate payload is returned, the Windows CryptoAPI engine verifies that the issuing authority chains to a trusted root in Cert:\LocalMachine\Root and verifies revocation status via Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP). If the CRL distribution point (CDP) URL is unreachable or the CRL file on the web server has expired, CAPI2 flags the certificate as invalid and halts deployment.

How to Diagnose

Triage autoenrollment failures methodically from the local client outward to the directory service and the certification authority. Avoid restarting CAs or rebuilding templates until you isolate the exact failing layer.

# 1. Verify that Certificate Autoenrollment Group Policy is applied to the machine
gpresult /r /scope computer

# 2. Check the active autoenrollment policy registry keys
# The value "AEPolicy" should be 0x7 (enables autoenrollment, renewals, and template updates)
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\AutoEnrollment"

# 3. Test CA reachability and RPC endpoint responsiveness directly from the affected client
# Replace with your issuing CA's FQDN and CA common name
certutil -ping -config "ca01.corp.example.com\Corp-Issuing-CA"

# 4. Check TCP 135 (RPC Endpoint Mapper) connectivity via PowerShell
Test-NetConnection -ComputerName "ca01.corp.example.com" -Port 135

# 5. Query the list of templates actually published and issued by the target CA
certutil -config "ca01.corp.example.com\Corp-Issuing-CA" -CATemplates

# 6. Inspect the local certificate store to see if previous certificates expired or failed renewal
Get-ChildItem -Path "Cert:\LocalMachine\My" | Select-Object Subject, NotAfter, Thumbprint

# 7. Enable the CAPI2 Operational event log to capture deep cryptographic and revocation failures
wevtutil sl Microsoft-Windows-CAPI2/Operational /e:true

# 8. Force an immediate autoenrollment pulse cycle to reproduce the failure on demand
certutil -pulse

# 9. Query CAPI2 Operational events for errors logged during the pulse (Events 11, 30, and 53)
Get-WinEvent -LogName "Microsoft-Windows-CAPI2/Operational" -MaxEvents 30 | 
  Where-Object { $_.LevelDisplayName -eq "Error" } | 
  Format-Table TimeCreated, Id, Message -Wrap

# 10. Once diagnostic logs are gathered, disable CAPI2 Operational logging to conserve disk I/O
wevtutil sl Microsoft-Windows-CAPI2/Operational /e:false

If certutil -ping succeeds but certutil -pulse still fails with Event 13, query the local client’s cached Public Key Services container in Active Directory. Check whether the client is attempting to contact decommissioned or non-existent CAs:

# Query Active Directory Enrollment Services container for all registered Enterprise CAs
Get-ADObject -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=example,DC=com" `
  -Filter * -Properties cn, dNSHostName, certificateTemplates | 
  Format-Table cn, dNSHostName

Common Causes

The Fix: Resolving Orphaned CAs and Repairing Template Permissions

In enterprise environments that have undergone domain controller migrations or PKI consolidations, the two dominant causes of persistent Event 13 errors are orphaned CA records lingering in Active Directory and misconfigured template DACLs. Here is the step-by-step procedure to resolve both conditions.

Step 1: Identify and Remove Orphaned Enterprise CAs

When an enterprise client runs certutil -pulse, it queries Active Directory for all objects in the Enrollment Services container. If an old CA (for example, SUB-CA-01 decommissioned two years ago) is still present in AD, clients will alternate between the active CA and the dead CA. Every time the client attempts to contact the dead CA, it generates Event 13 with 0x800706ba.

Execute the following PowerShell command on an administrative workstation with Active Directory tools installed to list all registered enrollment services:

# Query all registered CA enrollment endpoints in the forest configuration partition
$configNC = (Get-ADRootDSE).configurationNamingContext
Get-ADObject -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,$configNC" `
  -Filter * -Properties cn, dNSHostName | 
  Select-Object cn, dNSHostName

If an old, offline server appears in the list, delete the orphaned registration from Active Directory using certutil:

# Remove the orphaned CA from the Active Directory Enrollment Services container
# Replace "DECOMMISSIONED-CA" with the CN of the obsolete CA
certutil -dsDel "CN=DECOMMISSIONED-CA,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=example,DC=com"

# Force Active Directory replication across all domain controllers to propagate the deletion
Get-ADDomainController -Filter * | ForEach-Object {
    repadmin /syncall $_.HostName (Get-ADRootDSE).configurationNamingContext /e /A
}

Step 2: Correct Template Permissions and Autoenrollment Flags

If the CA is reachable and active, the breakdown is almost always a missing Autoenroll ACE on the certificate template. By default, duplicating a template does not automatically grant Autoenroll permissions to Domain Computers or Domain Users.

Open the Certificate Templates console (certtmpl.msc) on a management server:

# Launch Certificate Templates Console
certtmpl.msc

Locate your target certificate template (for example, Workstation-Authentication-v2). Right-click the template and select Properties:

1. Select the Security tab.
2. Click Add and select Domain Computers (or your custom workstation security group).
3. In the Permissions list, check Read, Enroll, and Autoenroll. All three permissions must be checked.
4. Select the General tab. Confirm that Publish certificate in Active Directory is checked if you are issuing user certificates for S/MIME or encryption.
5. Select the Subject Name tab. If Supply in the request is selected, autoenrollment cannot function automatically because the client autoenrollment agent does not prompt the user for input. Ensure Build from this Active Directory information is selected, and verify that the Subject Name format is set to Common name and DNS name is included.

Step 3: Flush Local Client Caches and Validate Enrollment

Return to the affected client workstation or server. Purge the cached Kerberos tickets, clear cached LDAP PKI data, and initiate an immediate enrollment cycle:

# Purge local Kerberos tickets to ensure fresh group memberships and DACLs are evaluated
klist purge

# Delete all cached CRLs and AIA objects to force fresh network retrieval
certutil -urlcache * delete

# Trigger an immediate autoenrollment pulse
certutil -pulse

# Inspect the personal machine certificate store to verify that the certificate was issued
Get-ChildItem -Path "Cert:\LocalMachine\My" | 
  Format-Table Subject, Issuer, NotBefore, NotAfter, HasPrivateKey -AutoSize

How to Prevent It

Preventing certificate autoenrollment outages requires treating PKI as a core Active Directory directory dependency rather than an isolated server service.

1. Centralised Autoenrollment Telemetry: Forward Event ID 13 and Event ID 6 from the Application log to your SIEM (Splunk, Microsoft Sentinel, or Elastic). Set up an alert threshold: if more than five machines log Event 13 within one hour, trigger a high-severity alert. This gives your PKI team hours or days to repair network or template issues before certificates expire in bulk.

2. Formalised CA Decommissioning Checklist: Never shut down a Certificate Authority without running the formal Active Directory metadata cleanup steps. As detailed in our architectural guide on Active Directory Certificate Services (AD CS), always remove the CA from CN=Enrollment Services, CN=AIA, and the NTAuthStore before decommissioning the host operating system.

3. Automated CRL Expiration Monitoring: The most catastrophic PKI failures happen silently when a Certificate Revocation List reaches its expiration timestamp. Schedule a daily PowerShell synthetic monitor on your monitoring server to verify the validity of your CRL distribution endpoints:

# Synthetic check for CRL expiration on the public/internal distribution point
$crlUrl = "http://pki.corp.example.com/pki/Corp-Issuing-CA.crl"
$tempFile = Join-Path $env:TEMP "check.crl"

Invoke-WebRequest -Uri $crlUrl -OutFile $tempFile -UseBasicParsing
$crlData = certutil -dump $tempFile | Select-String "NextUpdate"
Write-Output "CRL Expiration: $crlData"

If you are designing or validating your certificate architecture in a test harness before pushing to production, review the hands-on setup steps in our Homelab Build – Part 7 – Certificate Authority guide.

Final Thoughts

Certificate autoenrollment is one of the most reliable background features in Windows enterprise environments when its foundations are respected. Because it runs quietly without user interaction, engineers often forget how many moving parts—Group Policy, LDAP directory partitions, RPC dynamic routing, DCOM permissions, and CryptoAPI trust verification—must align for a single certificate to land in the store.

When Event 13 appears in your logs, do not treat it as an inexplicable Windows quirk. Read the hex error code, verify your RPC endpoints, clean up obsolete directory records, and use CAPI2 operational logging to trace cryptographic chain validation. Methodical triage turns an alarming security failure into a predictable fifteen-minute fix.