AD CS Troubleshooting: Common Certificate Service Failures

Somebody just paged you about “certificates being broken.” Now you’re staring at a help desk queue full of VPN outages, smart card failures, and vague “can’t get a certificate” tickets. None of them mention AD CS by name. That’s the annoying part. The real problem is usually a stale CRL or a template change from three weeks ago, and it never shows up where you’d expect it.

This guide walks through the most common AD CS troubleshooting scenarios in diagnostic order. We start with the fast checks, then move into template permissions, CRL publishing, and post-migration SID mismatches. It assumes you already know basic PKI concepts (CA, CRL, templates). You just need the exact command or console path to confirm what’s broken.

Why AD CS Is Tier-0 Infrastructure in 2026

It’s tempting to treat the Certification Authority (CA) role like any other Windows Server service: patch it, back it up, move on. That’s a mistake. A certificate issued by your internal CA is a statement of identity. It says “this really is DC01,” or “this really is jsmith,” or “this really is the VPN concentrator.” Every system that trusts your CA inherits its trust decisions. That includes domain controllers doing PKINIT for smart card logon, RADIUS servers validating 802.1x, and VPN gateways doing mutual TLS.

That puts the CA at the same blast radius as a domain controller. Say an attacker compromises the CA’s private key, or abuses a poorly configured certificate template. They can mint a certificate that authenticates as a Domain Admin. No password spray, no Kerberoasting, just a legitimate-looking cert. Microsoft’s own Tier-0 guidance for Active Directory groups CAs with domain controllers, AD FS servers, and Azure AD Connect boxes for exactly this reason.

The operational takeaway is simple. AD CS needs the same change control, monitoring, and least-privilege discipline you’d apply to a DC. If your team has a domain controller health checklist, add your CA servers to it. If you’ve done a Tier-0 hardening pass on AD, certificate templates and CA permissions belong in that same review. Don’t push them to a separate, lower-priority project.

Quick Diagnosis

Before chasing a specific symptom, run through these steps in order. Most AD CS tickets resolve at step 1 or 2. That’s a little anticlimactic, but it saves you an afternoon.

• Is the CA service actually running? Don’t assume; verify (see below).
• Is this one client or everyone? A single failed enrollment points to a template or permissions issue. A domain-wide failure points to CRL, network, or CA-level problems.
• When did it start? Correlate against recent changes: template edits, GPO changes, certificate renewals, CA migrations, or Windows updates. KB5014754-related enforcement changes are a frequent culprit; more on that below.
• What’s the exact error code? “It doesn’t work” isn’t diagnosable. Get the hex error code from Event Viewer or the enrollment wizard before you do anything else.
• Check Event Viewer on both ends: the client’s Application log and CertificateServicesClient-Lifecycle-System log, and the CA server’s System log filtered to source CertSvc (Applications and Services Logs > Microsoft > Windows > CertificateServicesClient-Lifecycle-System).

First Check: Confirm the CA Service Is Running

Everyone skips this step because “obviously it’s running.” But it’s also the actual cause often enough that it deserves to go first, every single time.

Symptoms:

• Certification Authority MMC console shows the CA as unavailable or won’t connect
• Enrollment requests time out instead of failing with a specific error
• certutil -ping fails from a client

Cause: The CertSvc service is stopped or crashed. Or the CA’s private key/certificate store is unreachable, common after restoring a CA VM to different hardware or losing HSM connectivity. Or a dependency (RPC, AD DS) isn’t reachable.

Fix:

On the CA server, check the service state:

Get-Service -Name CertSvc

Status Name DisplayName
—— —- ———–
Stopped CertSvc Active Directory Certificate Services

If it’s stopped, restart it and watch for errors instead of assuming success:

certutil -restart

The Certification Authority service was restarted successfully.
CertUtil: -restart command completed successfully.

If it won’t stay running, check the System event log for the specific reason. The three most common causes are a locked private key, a missing certificate in the local machine store, or a database (CertLog) that failed to mount:

Get-WinEvent -LogName System -MaxEvents 25 | Where-Object { $_.ProviderName -eq 'CertSvc' } | Format-Table -AutoSize TimeCreated, Id, LevelDisplayName, Message

From a client, confirm reachability with certutil -ping. It tests the RPC/DCOM path used for enrollment:

certutil -ping -config "ca01.corp.example.com\Corp-Issuing-CA"

CertUtil: -ping command completed successfully.

Tip: If the CA was recently restored to new hardware or a new VM, verify the CA’s private key is still present with certutil -verifykeys before troubleshooting anything else. A missing key after a restore is the single most common cause of “the CA won’t start” tickets in virtualized environments.

Verification: Get-Service CertSvc shows Running, and certutil -ping succeeds from at least one domain-joined client.

Common Issues

Certificate Enrollment Failures

This is the highest-volume AD CS ticket category by a wide margin. A user or machine requests a certificate, and it fails, stalls in Pending, or silently never appears.

Symptoms:

• Manual enrollment via the Certificates MMC snap-in fails with an access-denied or “template not found” error
• Autoenrollment never issues a certificate, but no user-facing error appears
• Requests sit in the CA’s Pending Requests folder indefinitely (standalone CA, or Enterprise CA with manager approval enabled)
• Web Enrollment (https://ca01/certsrv) returns an error before the request is even submitted

Cause: In order of frequency: the requesting account or computer lacks Enroll (or Autoenroll) permission on the template; the template requires manager approval and nobody approved it; RPC (TCP 135) and the dynamic RPC port range are blocked between client and CA; the template’s subject or key requirements don’t match what the client supplies (for example, a template expecting a SAN the client doesn’t populate); or the CA itself has been taken offline for a specific template via certutil -SetCAtemplates.

Fix:

Reproduce the failure and capture the real error instead of relying on the vague MMC message. For autoenrollment, force a pulse and check the result:

certutil -pulse

Then check the client’s CertificateServicesClient-Lifecycle-System event log for the actual result code and error text rather than a specific event ID number (lifecycle event IDs in this log track certificate state changes, not pass/fail codes). A 0x80070005 (Access is denied) almost always means a permissions problem. A 0x800706ba (RPC server unavailable) means a network or firewall problem, not a template problem.

Confirm the requesting principal has rights on the template. Open the Certificate Templates console and check the Security tab:

certtmpl.msc

Verify the account, group, or computer object has both Read and Enroll checked. Add Autoenroll too if this template is meant to autoenroll:

If permissions look right, check the network path. AD CS enrollment over RPC/DCOM needs TCP 135 plus a dynamic high port (or a statically configured RPC port range) open between client and CA:

Test-NetConnection -ComputerName ca01.corp.example.com -Port 135

ComputerName : ca01.corp.example.com
RemotePort : 135
TcpTestSucceeded : True

If you’re using Web Enrollment or Certificate Enrollment Web Service (CES) instead, check the IIS logs on the CA/CES server (C:\inetpub\logs\LogFiles) for the HTTP status code on the failed request. A 403 usually means an IIS authentication mismatch, not a certificate problem.

Verification: Re-run certutil -pulse (or the manual enrollment wizard) and confirm the certificate appears in the user/computer’s personal store:

Get-ChildItem -Path Cert:\LocalMachine\My

CRL Distribution Failures Breaking Authentication

This issue causes the most confusion, because the symptom shows up somewhere that looks unrelated to PKI: a VPN that suddenly rejects everyone, or smart card logons failing domain-wide.

Symptoms:

• VPN, 802.1x Wi-Fi, or smart card/Windows Hello for Business logons fail with generic “certificate could not be verified” or “trust” errors
• Schannel/TLS mutual-auth connections between internal services start failing
• pkiview.msc shows a CDP (CRL Distribution Point) or AIA (Authority Information Access) entry flagged in red or yellow

Cause: Most relying-party services (Kerberos PKINIT, IPsec, Schannel/TLS, smart card logon) fail closed when they can’t retrieve or validate a Certificate Revocation List. If the CRL is unreachable or expired, even perfectly valid certificates get rejected. It’s a frustrating design if you’re the one on call, but it’s the correct security default. The usual causes: a CRL that wasn’t republished before its scheduled expiration, an IIS site hosting the HTTP CDP that’s down or has a stale binding, or a firewall/DNS change that broke the path to the CDP location.

Fix:

Start with the Enterprise PKI console. It evaluates every published CDP and AIA location in the forest and flags problems visually:

pkiview.msc

For a command-line check on a specific certificate, pull its CDP URL and validity directly:

certutil -URL "C:\certs\example.cer"

Or check the current CRL’s validity window straight from the CA:

certutil -CRL

CertUtil: -CRL command completed successfully.

That regenerates and republishes the base and delta CRL immediately. It’s useful for confirming the CA itself can publish, but it won’t fix a broken distribution point on its own. If the CDP is HTTP-based (recommended for non-domain-joined and internet-facing clients), confirm the IIS site hosting it is actually up and the file is current:

Invoke-WebRequest -Uri "http://pki.corp.example.com/CertEnroll/Corp-Issuing-CA.crl" -Method Head

StatusCode : 200
StatusDescription : OK

A 404 means the CRL file wasn’t published to that path. A connection failure means IIS, DNS, or firewall, so check those in that order.

Tip: Set a monitoring alert for CRL expiration well before the “Next CRL Publish” date, not the “Next Update” (hard expiration) date. Waiting for the hard expiration means you’re already in an outage by the time the alert fires.

Verification: pkiview.msc shows all CDP/AIA entries as OK, and a client that was previously failing VPN or smart card logon authenticates successfully.

Certificate Template Vulnerabilities (ESC1–ESC16)

Symptoms:

• A security assessment, penetration test, or tool like Certipy/Certify/Locksmith flags your CA or templates as vulnerable
• Unexplained certificates issued to accounts that shouldn’t have needed them
• You’ve never audited template permissions since they were created (a symptom in itself, and a common one)

Cause: ESC1 through ESC16 is the community-adopted naming (from SpecterOps’ “Certified Pre-Owned” research) for a family of AD CS misconfigurations. They let a low-privileged account obtain a certificate that lets them authenticate as someone else, up to and including a Domain Admin or the domain itself. In plain terms, these fall into a few buckets:

Category	What it means in practice
Client can specify their own identity (ESC1)	A template lets the requester supply an arbitrary Subject Alternative Name, so a low-priv user requests a cert claiming to be an admin
CA-wide flag overrides template restrictions (ESC6)	The EDITF_ATTRIBUTESUBJECTALTNAME2 flag lets any requester set a SAN regardless of template settings
Overly broad enrollment rights (ESC4)	“Authenticated Users” or similar broad groups have Enroll or even Write rights on a sensitive template
Weak access control on the CA itself (ESC7)	Excessive rights over the CA object let an attacker approve their own pending requests or install a malicious CA extension
Missing strong mapping / SID extension (ESC9/ESC10)	Certificates issued without the SID security extension can be abused to impersonate accounts once weak certificate mapping is exploited
Topology/trust-chain abuse (ESC11–ESC16, evolving)	Newer additions covering NTLM relay to CA endpoints, cross-forest enrollment trust issues, and certificate mapping downgrade scenarios

This article deliberately skips exploitation steps. That’s well documented elsewhere and isn’t the goal here. What matters operationally is finding and closing these paths in your own environment.

Fix:

Audit first. Use a purpose-built auditing tool rather than eyeballing dozens of templates by hand: PSPKIAudit, Locksmith (PowerShell, open-source, read-only by default), or Certipy (audit mode) will enumerate risky templates and CA ACLs and tell you exactly which ESC category applies.

Then harden systematically:

• Disable the SAN override flag unless you have a documented reason to keep it:

certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc && net start certsvc

• Tighten Enroll/Autoenroll permissions on every template to the minimum group that actually needs it; never leave sensitive templates (anything with client authentication + user-suppliable subject data) open to Authenticated Users or Domain Users.
• Require manager approval on templates that issue high-privilege certificate types.
• Retire unused or legacy templates. Every duplicate-of-a-duplicate template from a decade-old migration is attack surface with no offsetting benefit.
• Enforce strong (SID-based) certificate mapping so issued certificates carry the security identifier needed for modern authentication checks (see the SID mismatch section below, which ties directly into KB5014754 enforcement).
• Restrict the CA server’s local admin group and DCOM/RPC permissions the same way you’d restrict a domain controller’s.

Verification: Re-run your audit tool and confirm previously flagged templates no longer show as vulnerable. Treat this as a recurring quarterly task, not a one-time cleanup; new templates get created, and permissions drift.

CA Migration/Renewal SID Mismatch Issues

Symptoms:

• Certificate-based logons (smart card, Windows Hello for Business, mutual TLS) start failing shortly after a CA migration, restore, or CA certificate renewal
• Domain controllers log Schannel or Kerberos errors referencing certificate mapping
• The certificate “looks fine” in the Certificates snap-in but authentication still fails, which is the most maddening version of this problem

Cause: Two related things tend to get lumped together as “SID mismatch.” First, after migrating a CA to new hardware or restoring from backup, clients and domain controllers may still trust a chain tied to the old CA’s certificate or thumbprint. That chain was never republished to the NTAuthCertificates object. Second, and more common in 2026, Microsoft’s stronger certificate-mapping enforcement (rolled out via KB5014754) requires domain controllers to validate a SID security extension embedded in the certificate. Certificates issued before this enforcement, or from templates that don’t populate the SID extension, get rejected once a DC moves into Full Enforcement mode, even though nothing about the certificate itself changed.

Fix:

After any CA migration, restore, or CA certificate renewal, republish the CA certificate to the NTAuthCertificates store so clients and DCs trust the current chain:

certutil -dspublish -f Corp-Issuing-CA.crt NTAuthCA

CertUtil: -dspublish command completed successfully.

Force policy and enrollment refresh across affected clients rather than waiting for the normal replication/refresh cycle:

gpupdate /force
certutil -pulse

Check which KB5014754 enforcement mode your domain controllers are currently running. This is a registry value, and it matters because “Compatibility” mode is far more forgiving than “Full Enforcement”:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Kdc" -Name StrongCertificateBindingEnforcement -ErrorAction SilentlyContinue

StrongCertificateBindingEnforcement : 1

A value of 2 means Full Enforcement: any certificate missing the SID extension gets rejected for certificate-based logon. If failures correlate with this setting, the real fix is re-issuing affected certificates from a template/CA configuration that populates the SID extension. Don’t just roll enforcement back; that’s a stopgap, not a fix. Microsoft’s enforcement timeline has already been extended multiple times and won’t extend indefinitely.

Verification: A previously failing smart card or certificate-based VPN logon succeeds, and DC security event logs no longer show certificate-mapping rejection errors for that account.

Error Messages Quick Reference

Error / Code	Where you’ll see it	Meaning	Fix
0x80070005 (Access is denied)	Enrollment, certutil -pulse	Requester lacks Enroll/Autoenroll permission on the template	Grant Enroll/Autoenroll on the template’s Security tab
0x800706ba (RPC server unavailable)	Manual/auto enrollment	Client can’t reach the CA over RPC/DCOM	Open TCP 135 + dynamic RPC range; check certutil -ping
0x80092013 (The revocation function was unable to check revocation)	TLS/Schannel, VPN, smart card logon	CRL unreachable or expired	Check pkiview.msc; republish CRL with certutil -CRL
CertUtil: -dspublish command FAILED: 0x8007052e	certutil -dspublish	Insufficient rights (needs Enterprise Admin-equivalent AD write)	Run as an account with rights to NTAuthCertificates
KDC_ERR_CLIENT_NOT_TRUSTED / Schannel event 36885-36888	DC Security/System log during cert-based logon	Certificate fails strong mapping requirements (KB5014754)	Re-issue cert with SID extension; check enforcement mode
HTTP 403 on /certsrv	Web Enrollment	IIS authentication mismatch on the CertSrv virtual directory	Verify Windows Authentication is enabled in IIS
“Certification Authority is not accessible”	Certification Authority MMC	CertSvc stopped, or RPC blocked to CA	Get-Service CertSvc; check firewall/RPC path
CA listed as unavailable, no icon detail	pkiview.msc	CDP/AIA location unreachable or CA cert expired	Confirm IIS/LDAP path is reachable; check CA cert validity

Platform-Specific Notes

AD CS itself is a Windows Server-only role. There’s no macOS or Linux equivalent you can stand up in its place. But mixed environments are the norm, so a few cross-platform notes matter:

• macOS and Linux clients can still enroll for and use AD CS-issued certificates, typically via SCEP against Network Device Enrollment Service (NDES) or by manually importing a PKCS#12 bundle. If a Mac can’t get a certificate through NDES, check the NDES server’s IIS logs and confirm the SCEP challenge password hasn’t expired. NDES challenge passwords are short-lived by default and are a common source of “it worked yesterday” tickets.
• Windows Server 2016 through 2025 are all still commonly seen in production AD CS deployments. The enrollment and CRL diagnostics above apply the same way across that range, though exact certutil output formatting can vary slightly by build.
• If you’re troubleshooting from a Mac administering a Windows environment (RDP or a Windows admin VM), the certutil/PowerShell commands above still need to run on Windows. There’s no native macOS equivalent for CA-side diagnostics.

Configuration Issues to Watch For

A few misconfigurations show up repeatedly. They’re worth checking proactively rather than waiting for a ticket:

Editing default templates instead of duplicating them. Always duplicate a template before modifying it. Editing built-in templates directly makes rollback harder and complicates future CA upgrades.

Autoenrollment GPO not linked correctly. Confirm the policy path and scope:

Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client – Auto-Enrollment

Verify the GPO is actually applied where you expect:

gpresult /r

CDP/AIA only published to LDAP, not HTTP. LDAP-only publishing works fine for domain-joined clients. But it breaks non-domain-joined devices, extranet clients, and anything doing revocation checks outside AD reach. Add an HTTP CDP location for anything that needs to validate certificates outside the domain.

Leaving EDITF_ATTRIBUTESUBJECTALTNAME2 enabled “temporarily.” This flag has a way of staying enabled long after whatever one-time need justified it. Audit CA registry flags during every quarterly review:

certutil -getreg policy\EditFlags

Getting Help

Log locations:

• CA server: Applications and Services Logs > Microsoft > Windows > CertificateServicesClient-Lifecycle-System (client-side) and the System log filtered to source CertSvc (server-side)

• IIS logs for Web Enrollment/CES/NDES: C:\inetpub\logs\LogFiles
• CA database and transaction logs: %SystemRoot%\System32\CertLog

Community and official resources:

• AD CS documentation on Microsoft Learn: the canonical reference for role services and configuration
• AD CS overview
• KB5014754: Certificate-based authentication changes on Windows domain controllers: essential reading before you touch enforcement mode settings
• certutil command reference

Escalate to Microsoft support (or your PKI vendor, if you’ve layered Keyfactor/EJBCA/Vault on top) when a CA won’t start after you’ve exhausted the service/key checks above, when you suspect private key compromise, or when pkiview.msc reports chain-building errors you can’t resolve through CDP/AIA republishing.

Prevention Tips

• Monitor CRL expiration continuously, not just when someone complains. Alert well before “Next CRL Publish,” not the hard expiration date.
• Run a template/CA permission audit quarterly using Locksmith, Certipy, or PSPKIAudit; treat it as recurring hygiene, the same cadence you’d use for a Tier-0 AD access review.
• Monitor CertSvc service health on every CA with the same alerting rigor as a domain controller’s core services: service state, disk space on the CA database volume, and event log errors from source CertSvc.
• Track certificate expiration for the CA’s own certificate, not just end-entity certs. A CA certificate that expires unexpectedly takes down everything it issued.
• Document and version-control template changes. A template edit is a Tier-0 change; treat it with the same change-control rigor as a GPO change to a Domain Admins-linked OU.
• Test the KB5014754 enforcement mode change in a lab before flipping it in production; verify affected templates emit the SID extension first.
• Keep a two-tier hierarchy (offline root + issuing subordinate CA) in production so a compromised or failed issuing CA doesn’t take down your entire trust root.

Wrapping Up

Most AD CS fire drills come down to one of five things: the service isn’t running, a template’s permissions are wrong, a CRL went stale, a template is too permissive, or a migration left a trust reference pointing at the old CA. Work through them in that order. You’ll usually find the root cause in minutes instead of burning hours chasing symptoms that look unrelated.

If you only have 30 minutes to spend on AD CS this quarter, spend it auditing template permissions. That’s where risk quietly piles up, because nobody revisits templates once they’re working. It’s the single highest-leverage thing on this list.

Step	Action	Applies To
1	Confirm CertSvc is running and reachable via certutil -ping	All AD CS issues
2	Check template Enroll/Autoenroll permissions	Enrollment failures
3	Validate CDP/AIA health in pkiview.msc	Auth/VPN/smart card failures
4	Audit templates for ESC1-ESC16 exposure	Security hardening
5	Republish to NTAuthCertificates and check SID extension	Post-migration/renewal issues
6	Set up continuous CRL and CertSvc monitoring	Ongoing prevention

Last updated: 2026-07-22 | Applies to Active Directory Certificate Services on Windows Server 2016 through 2025

For more information on Linux Privilege Escalation Hardening, Docker Networking Troubleshooting, and Dell iDRAC 9 Network Configuration, visit The Back Room Tech.

To learn more about Active Directory Certificate Services and AD CS overview, visit Microsoft Learn.