Active Directory Certificate Services (AD CS)

What Is AD CS?

Active Directory Certificate Services is a Windows Server role that implements a public key infrastructure (PKI) for an organisation. It lets you run your own Certificate Authority (CA) that issues X.509 certificates to users, computers, and services, the same kind of certificate a public CA like DigiCert issues for a website, except scoped to your own domain.

Think of AD CS as the passport office for your network. A public CA is like a national passport office: it issues documents that strangers around the world will trust. Your internal CA is more like a company badge office: it issues credentials that only your own organisation needs to trust, but it can issue as many as you want, for free, and revoke them the moment someone leaves.

The core role service is the Certification Authority, the component that actually signs certificate requests. Around it sit optional role services: Certificate Authority Web Enrollment (a browser-based request page for non-domain devices), Certificate Enrollment Web Service and Certificate Enrollment Policy Web Service (REST-style enrollment for devices that cannot use Group Policy autoenrollment), Network Device Enrollment Service (NDES) (issues certificates to non-Windows network devices like firewalls and printers via SCEP), and Online Responder (serves OCSP revocation checks instead of large CRL downloads).

Why Run Your Own CA Instead of a Public One?

Public CAs are the right choice for anything the internet needs to trust: your public website, a customer-facing API, a mail server’s TLS certificate. AD CS is for everything that only your own domain needs to trust.

The trade-off is trust scope. A certificate issued by your internal CA is only trusted by devices that trust that CA, which for a domain-joined machine happens automatically the moment the CA publishes its root certificate to AD. A non-domain device, a customer’s browser, or a phone that never joined the domain will not trust it unless you distribute the root certificate manually.

Why Active Directory (and Everything Else) Depends On It

Certificates are not a side feature in a Windows domain, they are load-bearing infrastructure for several things that look unrelated on the surface.

Smart card and PKINIT logon use a certificate on the smart card as the Kerberos pre-authentication credential instead of a password. LDAPS (LDAP over SSL/TLS on port 636) requires a domain controller to hold a valid server authentication certificate before it will accept the connection at all, and the LDAP channel binding and signing enforcement most domains now run makes this even more central than it used to be. Domain controller TLS more broadly, IIS sites bound to HTTPS, internal RD Gateway and RDP over TLS, and 802.1x wired or wireless authentication with EAP-TLS all consume certificates from the same internal CA. IPsec and EFS (Encrypting File System) can also use certificate-based authentication rather than pre-shared keys.

Designing the CA Hierarchy

A single CA works for a lab. For anything that will run for years and matter to production, the standard design is a two-tier hierarchy: an offline Root CA at the top, and one or more online Issuing (subordinate) CAs underneath it that actually hand out certificates day to day.

[Offline Root CA]  ──issues CA cert──▶  [Issuing/Subordinate CA]  ──issues certs──▶  [Users, Computers, Services]
      (powered off after setup)              (online, domain-joined)

The Root CA signs exactly one meaningful thing in its lifetime: the certificate of the subordinate CA(s) beneath it. Once that is done, it is shut down and kept offline, brought back online only to renew a subordinate’s certificate, sign a new CRL, or add another subordinate. Because the root’s private key is the trust anchor for the entire hierarchy, keeping it powered off and disconnected from the network is what actually protects it, not firewall rules on a running service.

The Issuing CA is the one that stays online, is domain-joined so it can act as an Enterprise CA, and is the one that answers real enrollment requests, publishes CRLs on a schedule, and gets backed up regularly. Larger environments split issuing CAs by purpose or by site, but the offline-root-plus-online-issuer pattern stays the same shape whether there is one issuing CA or ten.

Installing the CA Role

The role installs like any other Windows Server role, through Server Manager’s Add Roles and Features wizard, or from PowerShell. Installing the binaries and actually configuring the CA are two separate steps.

# Install the CA role service and its management console/snap-ins
Install-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

# Install the Certificate Templates and Certification Authority
# management snap-ins only, on a separate admin workstation
Install-WindowsFeature RSAT-ADCS

Installing the feature does not configure a working CA by itself, the role has to be configured afterwards with the ADCSDeployment PowerShell module or the post-install wizard in Server Manager.

# Configure this server as a new Enterprise Root CA
# (Enterprise CAs require the server be domain-joined and require
# an account in the Enterprise Admins group)
$params = @{
    CAType              = "EnterpriseRootCa"
    CryptoProviderName  = "RSA#Microsoft Software Key Storage Provider"
    KeyLength           = 2048
    HashAlgorithmName   = "SHA256"
    ValidityPeriod      = "Years"
    ValidityPeriodUnits = 20
}
Install-AdcsCertificationAuthority @params

# Configure a second server as an Enterprise Subordinate CA,
# certified by the root CA above
$params = @{
    CAType   = "EnterpriseSubordinateCa"
    ParentCA = "ROOTCA01.corp.example.com\Corp-Root-CA"
}
Install-AdcsCertificationAuthority @params

Certificate Templates

A certificate template is the rulebook an Enterprise CA reads before it issues anything: what the certificate can be used for (key usage, extended key usage), who is allowed to request one, how long it is valid, and whether autoenrollment is permitted. Templates live in Active Directory itself, which is why only Enterprise CAs, not Standalone CAs, can use them.

You never edit the built-in default templates directly. The standard pattern is to duplicate an existing template that is close to what you need, then adjust the copy.

A template being duplicated does not make it available, it still has to be explicitly published to each issuing CA that should hand it out. Removing a template from the CA (not deleting the template object itself) stops it being issued without affecting certificates already issued from it.

Certificate Autoenrollment

Autoenrollment is what makes an internal CA usable at scale, it lets domain-joined computers and users request, renew, and replace their own certificates automatically instead of an administrator manually approving every request. It is controlled by Group Policy, at Computer Configuration (or User Configuration) → Policies → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client – Auto-Enrollment, set to Enabled.

On the template side, autoenrollment also has to be permitted explicitly: the template’s security permissions need to grant the target group both Enroll and Autoenroll, not just Enroll. A template with Enroll but not Autoenroll still requires a manual request through certmgr.msc or the web enrollment page.

# Force a Group Policy refresh so the new autoenrollment
# policy takes effect immediately instead of waiting for
# the next background refresh cycle
gpupdate /force

# Trigger the autoenrollment task on the client without
# waiting for its normal timer/logon-triggered run
certutil -pulse

Commands and Verification

# Confirm the Certificate Services service is running on the CA
Get-Service -Name CertSvc

# Test that a client can reach the CA's request interface
certutil -ping

# Test connectivity to a specific named CA
certutil -config "ISSUINGCA01.corp.example.com\Corp-Issuing-CA" -ping

# Display the CA's own configuration and current CRL/cert status
certutil -CAInfo

# List certificate templates currently published on this CA
certutil -CATemplates

# Force publication of a new base CRL right now
certutil -CRL

# View a specific issued certificate's details from the local store
certutil -viewstore -user My

Troubleshooting Cheat Sheet

Final Thoughts

AD CS rarely gets attention until a certificate quietly expires and takes something else down with it, LDAPS, RD Gateway, or 802.1x, none of which announce “certificate problem” in their own error text. Treat the CA hierarchy itself as a piece of production infrastructure: keep the root offline and its CRL current, keep autoenrollment doing the renewal work automatically, and know which templates are actually published before you need to explain why one server has a certificate and its twin doesn’t.

Homelab Build — Part 7 — Certificate Authority applies this hierarchy decision to a real lab build, including the exact Install-AdcsCertificationAuthority parameters used and the trade-off of co-locating the CA role on a domain controller.