Microsoft Active Directory Certificate Services (AD CS) has been the default enterprise PKI for two decades. It’s deeply integrated with Active Directory, supports auto-enrollment for domain-joined machines, and is “free” (included with Windows Server licenses).
But AD CS is showing its age. It doesn’t support ACME. It can’t issue certificates to non-Windows systems without workarounds. It requires Windows Server infrastructure that many organizations are trying to eliminate. It has no native cloud integration. And its management tools (certsrv, certutil) haven’t been meaningfully updated since Windows Server 2012.
Organizations are migrating — not because AD CS is broken, but because modern infrastructure demands a PKI that works across cloud, containers, Linux, and automated pipelines. Here’s how to do it without breaking the certificates that keep your enterprise running.
Why Organizations Leave AD CS
1. No ACME Support
AD CS has no native ACME protocol support. In a world moving to 47-day certificates with automated renewal, this is a critical gap. You can bolt on ACME via third-party tools (like Keyfactor’s ACME gateway), but it’s not native.
2. Windows-Only Infrastructure
AD CS requires Windows Server. The CA, the web enrollment pages, NDES (for SCEP), and the management tools all run on Windows. If your infrastructure strategy is “reduce Windows Server footprint,” AD CS is a blocker.
3. No Cloud-Native Integration
AD CS doesn’t integrate with Kubernetes, cloud load balancers, or container orchestrators. Issuing certificates to EKS pods, GKE workloads, or cloud-native services requires custom bridges that are fragile and hard to maintain.
4. Operational Complexity
A properly configured AD CS deployment requires:
- Offline Root CA (separate Windows Server, powered off most of the time)
- Online Issuing CA (Windows Server, AD-integrated)
- NDES server (for mobile/network device enrollment)
- Web enrollment (IIS-based, often broken)
- CRL/AIA publication points (IIS or file share)
- Regular CRL publication ceremonies (Root CA must be powered on)
That’s 3-5 Windows Servers just for PKI, plus ongoing ceremony and maintenance overhead.
5. Security Concerns (ESC Vulnerabilities)
The “Certified Pre-Owned” research (2021) and subsequent ESC1-ESC13 attack techniques demonstrated that misconfigured AD CS templates are a common path to domain compromise. While these are configuration issues (not AD CS bugs), the complexity of template security makes misconfigurations nearly inevitable.
6. No API-First Design
AD CS was designed for GUI management (certsrv MMC snap-in). Automation requires PowerShell scripts, COM interfaces, or third-party tools. There’s no REST API, no declarative configuration, no GitOps-friendly management.
Modern PKI Alternatives
| Solution | Type | Best For | ACME | Cloud-Native | Cost |
|---|---|---|---|---|---|
| EJBCA | Open-source CA | Full-featured enterprise PKI | ✅ | ✅ | Free (Enterprise: paid) |
| Smallstep | Open-source CA | DevOps/cloud-native PKI | ✅ | ✅ | Free (commercial: paid) |
| HashiCorp Vault PKI | Secrets engine | Short-lived certs, service mesh | ❌ (EST) | ✅ | Free (Enterprise: paid) |
| AWS Private CA | Managed service | AWS-centric organizations | ❌ | ✅ (AWS) | $400/mo + per-cert |
| Google CAS | Managed service | GCP-centric organizations | ❌ | ✅ (GCP) | Per-cert pricing |
| Keyfactor EJBCA SaaS | Managed service | Enterprise with compliance needs | ✅ | ✅ | Enterprise pricing |
| cert-manager + self-signed CA | K8s-native | Simple internal PKI for K8s | ✅ | ✅ | Free |
Migration Strategy: The Phased Approach
Phase 0: Assessment (2-4 Weeks)
Before migrating anything, understand what you have:
# Inventory all issued certificates
certutil -view -restrict "Disposition=20" -out "CommonName,NotAfter,CertificateTemplate" > all_certs.csv
# Count certificates by template
certutil -view -restrict "Disposition=20" | findstr "Certificate Template" | sort | uniq -c
# Identify auto-enrollment templates
Get-CATemplate | Where-Object { $_.AutoEnrollment -eq $true }
# Check what's using NDES/SCEP
# Review IIS logs on NDES server for enrollment requestsKey questions:
- How many active certificates exist? (typically 5,000-50,000 in mid-size enterprise)
- Which templates are in use? (usually 5-10 out of 50+ configured)
- What enrolls via auto-enrollment? (computers, users, servers)
- What uses NDES/SCEP? (mobile devices, network equipment)
- What’s the Root CA’s remaining validity?
- Are there cross-forest trust dependencies?
Phase 1: Parallel Deployment (1-2 Months)
Deploy the new CA alongside AD CS. Both issue certificates simultaneously.
Existing: AD CS Root → AD CS Issuing CA → existing certificates (unchanged)
New: AD CS Root → New Issuing CA (EJBCA/Vault/Cloud) → new certificates
# The new Issuing CA is signed by the EXISTING Root CA
# This means all existing trust stores already trust the new CA's certificates
# No trust distribution needed!Why sign the new CA with the existing Root? Because every domain-joined machine already trusts the AD CS Root CA. Certificates from the new Issuing CA are immediately trusted everywhere — no GPO changes, no trust store updates, no client-side changes.
Phase 2: Migrate New Workloads (2-4 Months)
All NEW certificate requests go to the new CA:
- New Kubernetes services → cert-manager with new CA issuer
- New cloud workloads → new CA via ACME or API
- New servers → new CA via automation (Ansible, Terraform)
Existing certificates continue to be managed by AD CS until they expire.
Phase 3: Migrate Existing Workloads (4-12 Months)
As existing certificates approach renewal, redirect them to the new CA:
- Server certificates → renew from new CA (ACME or automation)
- User certificates → new enrollment mechanism (if still needed)
- Computer certificates → new auto-enrollment equivalent (or eliminate if not needed)
- Network devices → new CA via SCEP/EST (if new CA supports it)
Phase 4: Decommission AD CS (After All Certs Migrated)
Once no active certificates are issued by the AD CS Issuing CA:
- Stop the CA service (don’t delete yet)
- Monitor for any failures (something still trying to enroll)
- After 30 days with no issues: decommission the Issuing CA server
- Keep the Root CA offline (it signed the new Issuing CA — still needed for chain validation)
- Eventually: if you create a new Root CA, plan a full trust migration
Handling Auto-Enrollment
AD CS auto-enrollment is the hardest thing to replace. Domain-joined Windows machines automatically request and receive certificates based on GPO templates. No other CA has this exact capability.
Options:
Option A: Keep AD CS for Windows Auto-Enrollment Only
AD CS Issuing CA → Windows computer/user certificates (auto-enrollment)
New CA → everything else (servers, K8s, cloud, Linux, network devices)This is the pragmatic approach for organizations with large Windows fleets. AD CS handles what it’s good at (Windows auto-enrollment). The new CA handles everything else.
Option B: Replace with Intune/MDM Certificate Profiles
For organizations moving to cloud-managed endpoints:
Intune → SCEP/PKCS profile → New CA (via NDES bridge or native connector)Intune pushes certificate profiles to managed devices. The CA issues certificates via SCEP or PKCS. No AD CS needed.
Option C: Replace with cert-manager + CSI Driver (Kubernetes)
For containerized Windows workloads:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: windows-service-cert
spec:
secretName: windows-service-tls
issuerRef:
name: internal-ca
# Mount into Windows container via CSI driverCommon Migration Pitfalls
Pitfall 1: Forgetting the CRL
AD CS publishes CRLs that existing certificates reference. If you decommission the AD CS server, the CRL endpoint goes down. Existing certificates (still valid, not yet renewed) fail validation because clients can’t check revocation.
Fix: Keep the CRL publication point alive (even a static web server serving the last CRL) until all AD CS-issued certificates have expired or been replaced.
Pitfall 2: Template-Specific Extensions
AD CS templates can include custom extensions, specific EKUs, and certificate policies that applications depend on. If the new CA doesn’t issue certificates with identical extensions, applications break.
Fix: Audit which extensions each template includes. Configure the new CA to match. Test with the actual consuming applications before migrating.
Pitfall 3: Cross-Forest Trust Dependencies
In multi-forest AD environments, CAs in one forest may issue certificates trusted by another forest (via cross-certification or NTAuth store). Migrating the CA without updating cross-forest trust breaks authentication.
Fix: Map all cross-forest certificate trust relationships before migration. Update NTAuth stores and trust configurations in all forests.
Pitfall 4: Smart Card Logon Certificates
If your organization uses smart card authentication (certificates on smart cards for Windows logon), these certificates have specific requirements (UPN in SAN, Smart Card Logon EKU, specific key usage). The new CA must issue certificates that meet these exact requirements, or smart card logon breaks.
Fix: Test smart card enrollment and logon with the new CA in a lab environment before migrating production users.
Timeline Expectations
| Organization Size | Assessment | Parallel Deploy | Migration | Decommission | Total |
|---|---|---|---|---|---|
| Small (< 1,000 certs) | 2 weeks | 2 weeks | 2 months | 1 month | ~4 months |
| Medium (1,000-10,000 certs) | 1 month | 1 month | 6 months | 2 months | ~10 months |
| Large (10,000+ certs) | 2 months | 2 months | 12 months | 3 months | ~18 months |
The migration timeline is dominated by the “wait for existing certificates to expire” phase. You can accelerate by proactively re-issuing certificates from the new CA before their natural expiry.
FAQ
Q: Can I keep my existing Root CA and just replace the Issuing CA? A: Yes — this is the recommended approach. Sign the new Issuing CA with your existing Root CA. All existing trust stores continue to work. No client-side changes needed.
Q: What about OCSP? AD CS has a built-in OCSP responder. A: Most modern CAs include OCSP responders (EJBCA, Smallstep, cloud CAs). Configure the new CA’s OCSP responder URL in issued certificates. For the transition period, keep the AD CS OCSP responder running for old certificates.
Q: Is this a good time to move to a new Root CA too? A: Only if your current Root CA is approaching expiry (< 5 years remaining) or uses deprecated algorithms (RSA 1024, SHA-1). Otherwise, keep the existing Root — it simplifies the migration enormously.
Q: What about NDES for mobile devices? A: If you use NDES for Intune/MDM enrollment, you can either: keep NDES pointing to the new CA (NDES is just a SCEP proxy), or switch to the new CA’s native SCEP/EST endpoint. Most modern CAs support SCEP directly.
Q: How do I handle the AD CS database (issued certificate history)?
A: Export the certificate database before decommissioning (certutil -backup). Keep the backup for compliance/audit purposes. You may need to prove what certificates were issued historically.