AD CS to Modern PKI Migration Playbook: Phase-by-Phase Enterprise Guide

AD CS has been the default enterprise PKI for two decades. It works — until you need certificates for Kubernetes pods, cloud workloads, IoT devices, or anything outside the Windows domain. The 47-day certificate lifetime mandate makes manual AD CS enrollment workflows operationally impossible at scale.

This playbook gives you a phase-by-phase migration path that doesn’t require a forklift replacement. You’ll run AD CS and modern PKI in parallel, migrate workloads incrementally, and keep a rollback path open at every stage.

Why Migrate Now

Three forces are converging:

1. 47-day certificate lifetimes — Manual enrollment through AD CS web portals or autoenrollment GPOs can’t handle 8x more renewals per year
2. Cloud and container workloads — AD CS has no native integration with Kubernetes, AWS, GCP, or Azure PaaS services
3. Post-quantum readiness — AD CS templates are hardcoded to RSA/ECC; migrating algorithms requires modern CA infrastructure

The goal isn’t to eliminate AD CS entirely. Domain controllers, NPS/RADIUS, and Windows device certificates may stay on AD CS indefinitely. The goal is to move everything else to infrastructure that supports automation natively.

Migration Architecture Overview

Phase 1: Assessment (Weeks 1-4)

Certificate Inventory

Before migrating anything, you need a complete picture of what AD CS is issuing today.

Automated discovery using certutil:

# Export all issued certificates from AD CS
certutil -view -restrict "Disposition=20" -out "RequestID,CommonName,NotAfter,CertificateTemplate,RequesterName" > issued_certs.csv

# Count certificates by template
certutil -view -restrict "Disposition=20" -out "CertificateTemplate" | 
  Sort-Object | Group-Object | Sort-Object Count -Descending

Query AD CS database for template usage:

# Get certificate counts per template
$templates = certutil -catemplates
foreach ($t in $templates) {
    $count = (certutil -view -restrict "CertificateTemplate=$($t.Split(':')[0]),Disposition=20" -out RequestID).Count
    Write-Output "$($t.Split(':')[0]): $count active certificates"
}

Network-based discovery for certificates AD CS doesn’t know about:

# Scan network for TLS certificates (nmap)
nmap -p 443,8443,636,993,995 --script ssl-cert 10.0.0.0/16 -oX tls_scan.xml

# Parse results for issuer information
xmlstarlet sel -t -m "//script[@id='ssl-cert']" \
  -v "../@addr" -o "," -v "table/table[@key='issuer']/elem[@key='commonName']" -n tls_scan.xml

Workload Classification

Categorize every certificate into one of four migration buckets:

Dependency Mapping

For each certificate template, document:

• What systems consume the certificate
• How the certificate is requested (autoenrollment, manual, NDES, CEP/CES)
• What trusts the issuing CA (trust store locations)
• Renewal frequency and current automation level

Phase 2: Parallel Infrastructure (Weeks 5-10)

Deploy the Modern CA Stack

The target architecture depends on your environment:

Example: Deploy Vault PKI as an intermediate CA:

# Enable PKI secrets engine
vault secrets enable -path=pki_int pki

# Set max TTL
vault secrets tune -max-lease-ttl=43800h pki_int

# Generate intermediate CSR
vault write -format=json pki_int/intermediate/generate/internal \
  common_name="Enterprise Intermediate CA v2" \
  issuer_name="enterprise-int-v2" \
  key_type="ec" \
  key_bits=384 | jq -r '.data.csr' > vault_int.csr

Sign the intermediate with your existing AD CS root (or a new offline root):

# Submit CSR to AD CS root CA for signing
certreq -submit -attrib "CertificateTemplate:SubCA" vault_int.csr vault_int.cer

# Or use certutil for offline root
certutil -sign vault_int.csr vault_int.cer

Establish Trust

The critical step: both old and new certificates must be trusted by all relying parties during migration.

Option A: Cross-sign the new intermediate under the existing AD CS root

• Simplest approach — all existing trust stores already trust the root
• New certificates chain to the same root CA
• No trust store changes needed on clients

Option B: New root with bridge trust

• Deploy new root CA certificate to all trust stores via GPO/MDM
• More work upfront, cleaner long-term separation

# Distribute new root via GPO (if using Option B)
# Copy root cert to SYSVOL
Copy-Item "new_root_ca.cer" "\\domain.local\SYSVOL\domain.local\Policies\Certificates\"

# Or push via Intune for hybrid-joined devices
# Upload to Intune > Devices > Configuration profiles > Trusted certificate

Pilot Migration

Select 5-10 non-critical workloads for the pilot:

• Internal development web servers
• CI/CD pipeline certificates
• Non-production API endpoints
• Internal tool TLS (Grafana, Jenkins, GitLab)

# cert-manager Certificate resource for pilot workload
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: grafana-tls
  namespace: monitoring
spec:
  secretName: grafana-tls-secret
  duration: 720h      # 30 days
  renewBefore: 168h   # Renew 7 days before expiry
  issuerRef:
    name: vault-issuer
    kind: ClusterIssuer
  dnsNames:
    - grafana.internal.company.com
    - monitoring.internal.company.com

Phase 3: Workload-by-Workload Migration (Weeks 11-30)

# Install step-ca ACME server (if not using public CA)
step ca init --deployment-type=standalone \
  --name="Enterprise ACME CA" \
  --provisioner="acme" \
  --address=":443"

# Configure Certbot to use internal ACME
certbot certonly --server https://acme.internal.company.com/acme/directory \
  --standalone -d webserver.company.com \
  --preferred-challenges http-01

# /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
#!/bin/bash
systemctl reload nginx
logger "Certificate renewed and Nginx reloaded for $RENEWED_DOMAINS"

# Istio integration with cert-manager
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: istio-ca
  namespace: istio-system
spec:
  isCA: true
  duration: 8760h
  secretName: istio-ca-secret
  issuerRef:
    name: vault-cluster-issuer
    kind: ClusterIssuer
  commonName: istio-ca.company.com

# 1. Re-issue certificate from AD CS template
certreq -submit -attrib "CertificateTemplate:WebServer" request.csr

# 2. Deploy AD CS certificate back to the workload
# 3. Update DNS/load balancer if needed
# 4. Verify with openssl
openssl s_client -connect server:443 -servername server.company.com < /dev/null 2>/dev/null | \
  openssl x509 -noout -issuer -dates