How to Set Up a PKI Infrastructure with AD CS on Windows Server 2022

Understanding PKI and Why It Matters

Public Key Infrastructure (PKI) is the combination of hardware, software, policies, and procedures required to create, manage, distribute, use, store, and revoke digital certificates. Certificates are used throughout modern Windows environments for TLS/HTTPS encryption, code signing, email signing and encryption (S/MIME), smart card logon, IPsec, Wi-Fi (802.1X), and many other purposes. Rather than purchasing every certificate from a commercial Certificate Authority (CA), organizations with Windows Server 2022 can deploy their own internal CA using Active Directory Certificate Services (AD CS) — issuing certificates for internal use at no per-certificate cost with full integration into Active Directory.

A sound PKI design follows a two-tier hierarchy: an offline Root CA at the top, and one or more Subordinate (Issuing) CAs below it. The Root CA is the ultimate trust anchor. Because it signs the Subordinate CA’s certificate, it only needs to be online briefly to perform that signing operation — after that, it is shut down and kept off the network. All day-to-day certificate issuance is handled by the online Subordinate CA. This design limits the blast radius if an online CA is ever compromised: attackers cannot forge certificates trusted by your organization because the Root CA’s private key is stored offline.

Prerequisites and Planning

Before deploying AD CS on Windows Server 2022, plan the following: CA hostnames (must not be changed after deployment), CRL Distribution Points (CDP) URLs, Authority Information Access (AIA) URLs, and whether the Root CA will be standalone or enterprise. The Subordinate/Issuing CA should be an Enterprise CA (domain-joined) to leverage AD integration — auto-enrollment, certificate templates, and group policy publication. The Root CA should be a Standalone CA and should not be domain-joined, as joining it to AD creates an unnecessary dependency and exposure.

Choose hostnames and CDP/AIA URLs that will remain valid for the lifetime of your PKI — typically 10–20 years for a Root CA. The CRL and CA certificate must be downloadable by clients from the URLs embedded in issued certificates. A common pattern is to publish them at a simple HTTP URL like http://pki.contoso.com/crl/ and http://pki.contoso.com/certs/ hosted by IIS on a dedicated server.

Installing AD CS on Windows Server 2022

Install the Active Directory Certificate Services role. On both the Root CA and Subordinate CA, use the following command (adjust which sub-features you include based on the role):

For the Root CA (Standalone CA — offline machine, not domain-joined):

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

For the Subordinate/Issuing CA (Enterprise CA — domain-joined, online):

Install-WindowsFeature ADCS-Cert-Authority, ADCS-Web-Enrollment, ADCS-Enroll-Web-Pol, ADCS-Enroll-Web-Svc -IncludeManagementTools

If you plan to deploy an OCSP Responder (recommended for fast revocation checking), install that role on a separate server:

Install-WindowsFeature ADCS-Online-Cert -IncludeManagementTools

Configuring the Offline Root CA

On the offline Root CA (Standalone, not domain-joined), configure AD CS using Install-AdcsCertificationAuthority. Choose a meaningful CA name — this name will be embedded in every certificate issued by CAs in your hierarchy and cannot be changed:

Install-AdcsCertificationAuthority `
    -CAType StandaloneRootCA `
    -CACommonName "Contoso Root CA" `
    -CADistinguishedNameSuffix "O=Contoso,C=US" `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA256 `
    -ValidityPeriod Years `
    -ValidityPeriodUnits 20 `
    -DatabaseDirectory "C:WindowsSystem32CertLog" `
    -LogDirectory "C:WindowsSystem32CertLog" `
    -Force

Configure CDP and AIA extensions on the Root CA to point to your PKI distribution server. Remove the default LDAP and file-based URLs, keeping only the HTTP URL that clients outside the domain can reach:

# Remove all existing CDP paths
$crlList = Get-CACrlDistributionPoint
foreach ($entry in $crlList) { Remove-CACrlDistributionPoint $entry.URI -Force }

# Add HTTP CDP
Add-CACrlDistributionPoint -Uri "http://pki.contoso.com/crl/.crl" -AddToCertificateCDP -Force

# Remove all existing AIA paths
$aiaList = Get-CAAuthorityInformationAccess
foreach ($entry in $aiaList) { Remove-CAAuthorityInformationAccess $entry.Uri -Force }

# Add HTTP AIA for CA cert
Add-CAAuthorityInformationAccess -Uri "http://pki.contoso.com/certs/_.crt" -AddToCertificateAia -Force

Set the CRL validity period. Root CA CRLs can have a long validity since the Root CA rarely revokes certificates:

certutil -setreg CACRLPeriodUnits 52
certutil -setreg CACRLPeriod Weeks
certutil -setreg CACRLDeltaPeriodUnits 0
certutil -setreg CACRLDeltaPeriod Days

Publish the CRL and export the Root CA certificate for distribution:

Restart-Service certsvc

# Publish the CRL to C:WindowsSystem32CertSrvCertEnroll
certutil -crl

# Export Root CA certificate
certutil -ca.cert "C:RootCAContosoRootCA.cer"

Publishing Root CA Certificate to Active Directory

The Root CA certificate must be placed in Active Directory’s NTAuthCertificates store and the Trusted Root Certification Authorities container so all domain machines trust it automatically. Copy the Root CA certificate to a domain-joined machine and run the following from an elevated command prompt:

# Publish Root CA cert to AD Trusted Root store (propagates via GPO to all domain computers)
certutil -dsPublish -f ContosoRootCA.cer RootCA

# Publish to NTAuth (required for smart card logon and other AD-integrated cert uses)
certutil -dsPublish -f ContosoRootCA.cer NTAuthCA

# Copy the CRL to the distribution share
# (assuming you've set up an IIS site at pki.contoso.com pointing to C:PKIcrl)
Copy-Item "C:WindowsSystem32CertSrvCertEnroll*.crl" "\pki.contoso.comCRLShare"
Copy-Item ContosoRootCA.cer "\pki.contoso.comCertsShare"

Configuring the Enterprise Subordinate CA

On the online, domain-joined Subordinate CA server, install the role and generate a certificate request to be signed by the Root CA:

Install-AdcsCertificationAuthority `
    -CAType EnterpriseSubordinateCA `
    -CACommonName "Contoso Issuing CA 01" `
    -CADistinguishedNameSuffix "O=Contoso,C=US" `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -KeyLength 2048 `
    -HashAlgorithmName SHA256 `
    -OutputCertRequestFile "C:SubCASubCARequest.req" `
    -Force

This generates a certificate signing request (CSR) at the specified path. Copy SubCARequest.req to the offline Root CA. On the Root CA, submit and approve the request:

# Submit the request to the Root CA
certreq -submit -config "ContosoRootCAContoso Root CA" SubCARequest.req SubCACert.cer

# Or use certutil if the CA is local
certutil -submit -config ".Contoso Root CA" SubCARequest.req

Approve the pending request in the Root CA’s certification authority console, then retrieve the signed certificate. Copy SubCACert.cer back to the Subordinate CA and complete the installation:

Install-AdcsCertificationAuthority -CAType EnterpriseSubordinateCA -CertFile "C:SubCASubCACert.cer" -Force

Configure CDP and AIA on the Subordinate CA similarly to the Root CA, then restart the service:

Restart-Service certsvc

Certificate Templates

Enterprise CAs use certificate templates to define the properties of issued certificates. Templates are stored in Active Directory and can be customized for specific use cases. Duplicate the built-in templates rather than modifying them directly:

# List available templates
Get-CATemplate | Select-Object Name, OID

# Add a template to the issuing CA (after creating it in the Certificate Templates console)
Add-CATemplate -Name "ContosoWebServer" -Force

Common templates to configure for internal use include: Web Server (for IIS/HTTPS certificates), Computer (for IPsec and general machine authentication), User (for email signing and smart card logon), and Code Signing (for internal software development).

Auto-Enrollment via Group Policy

One of the most powerful features of an Enterprise CA is auto-enrollment: domain computers and users automatically request and renew certificates without administrator intervention. Configure auto-enrollment through Group Policy:

Open the Group Policy Management Console. Create or edit a GPO linked to your domain. Navigate to: Computer Configuration > Windows Settings > Security Settings > Public Key Policies. Double-click Certificate Services Client – Auto-Enrollment and configure:

# Verify auto-enrollment is working on a client machine
certutil -pulse

# Check the event log for auto-enrollment events
Get-WinEvent -LogName "Microsoft-Windows-CertificateServicesClient-AutoEnrollment/Operational" -MaxEvents 20 | Select-Object TimeCreated, LevelDisplayName, Message

In the GPO, set the Configuration Model to “Enabled”, check “Renew expired certificates, update pending certificates, and remove revoked certificates”, and check “Update certificates that use certificate templates”.

Installing and Configuring the OCSP Responder

Online Certificate Status Protocol (OCSP) provides real-time certificate revocation checking as an alternative to downloading full CRL files. The OCSP Responder is installed as part of AD CS:

Install-AdcsOnlineResponder -Force

After installation, configure the OCSP Responder in the Online Responder management console. Create a Revocation Configuration that points to the Issuing CA, uses the OCSP Response Signing template, and specifies the CA’s CRL as the revocation data source. Add the OCSP URL to the Subordinate CA’s AIA extension:

Add-CAAuthorityInformationAccess -Uri "http://pki.contoso.com/ocsp" -AddToCertificateOcsp -Force
Restart-Service certsvc

CA Key Archival

Key archival allows the CA to store a copy of certificate private keys (for encryption certificates only — not signing certificates) so they can be recovered if a user loses their key. Enable key archival on the Issuing CA:

# Enable archival on the CA
certutil -setreg CAUseDefinedCACertInRequest 0
certutil -setreg policyEditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

Configure the Key Recovery Agent (KRA) certificate template and assign it to a designated recovery agent account. The KRA certificate allows the designated administrator to decrypt and recover archived private keys when a user needs their encryption key restored. Store the KRA certificate and private key on a smart card or hardware security module for maximum security.

Back up the CA database and private key regularly. The CA database backup is critical for recovery:

# Backup the CA database and private key
Backup-CARoleService -Path "C:CABackup" -Password (ConvertTo-SecureString "BackupP@ss!" -AsPlainText -Force) -Force

# Schedule this as a recurring task via Task Scheduler
$action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-NonInteractive -Command `"Backup-CARoleService -Path 'E:CABackups$(Get-Date -f yyyyMMdd)' -Password (ConvertTo-SecureString 'BackupP@ss!' -AsPlainText -Force) -Force`""
$trigger = New-ScheduledTaskTrigger -Weekly -DaysOfWeek Sunday -At 2am
Register-ScheduledTask -TaskName "CA Weekly Backup" -Action $action -Trigger $trigger -RunLevel Highest