How to Set Up Windows Server 2022 as a RADIUS Proxy

Introduction to Active Directory Certificate Services

Active Directory Certificate Services (AD CS) is a Windows Server role that provides customizable services for creating and managing public key infrastructure (PKI) certificates. Organizations use AD CS to issue digital certificates for authentication (smart cards, VPN, 802.1X), encrypting data in transit (SSL/TLS for internal websites), encrypting data at rest (EFS), and signing code or documents. When deployed properly, AD CS eliminates the cost of purchasing certificates from external certificate authorities for internal use cases while providing tight integration with Active Directory.

Windows Server 2022 includes AD CS as a built-in server role with full support for certificate templates, autoenrollment via Group Policy, web enrollment, online responders (OCSP), and network device enrollment (NDES). This guide covers installing and configuring a two-tier PKI hierarchy — a standalone offline root CA and an enterprise subordinate issuing CA — which is the recommended deployment model for production environments.

Standalone vs Enterprise CA and Root vs Subordinate CA

An Enterprise CA is integrated with Active Directory. It can use certificate templates, supports autoenrollment, publishes certificates and CRLs to AD, and is accessible by domain members for automated certificate requests. An enterprise CA requires domain membership and the Active Directory Domain Services infrastructure. A Standalone CA does not require AD integration, does not use certificate templates, and processes all requests manually or through custom policy modules. Standalone CAs are typically used for offline root CAs.

A Root CA is the trust anchor of the PKI hierarchy. Its certificate is self-signed and is distributed to all clients via Group Policy or manual installation. In a production environment, the root CA should be kept offline (disconnected from the network) after initial setup to protect the root private key. A Subordinate CA (also called an Issuing CA) receives its certificate from the root CA and handles day-to-day certificate issuance. Clients and servers interact with the subordinate CA for certificate enrollment.

Installing the Certification Authority Role

On the server designated as your issuing (subordinate) CA, install the AD CS role using PowerShell. This server must be domain-joined:

# Install AD CS role and management tools
Install-WindowsFeature -Name AD-Certificate -IncludeManagementTools

# Install additional AD CS components
Install-WindowsFeature -Name `
    ADCS-Cert-Authority, `
    ADCS-Online-Cert, `
    ADCS-Web-Enrollment, `
    ADCS-Enroll-Web-Pol `
    -IncludeManagementTools

After installation, configure the enterprise subordinate CA. You will need the root CA certificate request file (generated during root CA setup) to obtain the signed subordinate CA certificate before completing configuration:

# Configure the Enterprise Subordinate CA
Install-AdcsCertificationAuthority `
    -CAType EnterpriseSubordinateCA `
    -CACommonName "Corp-Issuing-CA" `
    -CADistinguishedNameSuffix "DC=corp,DC=local" `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA256 `
    -OutputCertRequestFile "C:CARequestSubCA-Request.req" `
    -Force

This command generates a certificate signing request (CSR) in the specified output file. Transfer this file to the offline root CA, sign it, then bring the signed certificate back and install it to complete the subordinate CA configuration.

For the standalone offline root CA, install on a non-domain-joined server:

Install-WindowsFeature -Name AD-Certificate -IncludeManagementTools

Install-AdcsCertificationAuthority `
    -CAType StandaloneRootCA `
    -CACommonName "Corp-Root-CA" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA256 `
    -ValidityPeriod Years `
    -ValidityPeriodUnits 20 `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -Force

Signing the Subordinate CA Request on the Root CA

On the offline root CA, submit the subordinate CA request and issue the certificate. Because this is a standalone CA, submission and issuance are separate steps:

# On the root CA — submit the subordinate request
certreq -Submit -attrib "CertificateTemplate:SubCA" C:SubCA-Request.req

# The command returns a Request ID. Issue it from an elevated prompt:
certutil -resubmit 

# Retrieve the issued certificate
certreq -Retrieve  C:SubCA-Cert.cer

Copy the signed SubCA-Cert.cer and the root CA certificate (export it with certutil -ca.cert C:RootCA.cer) back to the issuing CA server. Then install the root CA certificate in the enterprise trust store and complete the subordinate CA configuration:

# Install the root CA cert into the Local Machine Trusted Root store
certutil -addstore Root C:RootCA.cer

# Install the signed subordinate CA certificate
certutil -installcert C:SubCA-Cert.cer

# Start the CA service
Start-Service certsvc

Configuring CRL Distribution Points and AIA

Clients must be able to download Certificate Revocation Lists (CRLs) and access Authority Information Access (AIA) extension data to verify certificate validity. Configure these distribution points on the issuing CA using PowerShell:

# View current CDP and AIA settings
certutil -getreg CACRLPublicationURLs
certutil -getreg CACACertPublicationURLs

# Add an HTTP-based CRL Distribution Point
Add-CACRLDistributionPoint `
    -Uri "http://pki.corp.local/pki/.crl" `
    -AddToCertificateCDP `
    -AddToFreshestCrl `
    -Force

# Add an HTTP-based AIA
Add-CAAuthorityInformationAccess `
    -Uri "http://pki.corp.local/pki/_.crt" `
    -AddToCertificateAia `
    -Force

# Restart CA and publish a new CRL
Restart-Service certsvc
certutil -crl

Create a virtual directory on IIS at http://pki.corp.local/pki pointing to the CA’s CertEnroll share (C:WindowsSystem32CertSrvCertEnroll) so clients can download CRLs and CA certificates over HTTP.

Working with Certificate Templates

Certificate templates define the properties of certificates issued by an enterprise CA, including intended purpose (EKUs), subject name format, cryptographic requirements, and validity period. Templates are stored in Active Directory and are only available on enterprise CAs.

To list available certificate templates using PowerShell (requires RSAT-AD-PowerShell or PSPKI module):

# Using certutil to list templates available on the CA
certutil -catemplates

# Using Get-CertificateTemplate (requires PSPKI module)
Import-Module PSPKI
Get-CertificateTemplate | Select-Object Name, DisplayName, SchemaVersion | Format-Table -AutoSize

To duplicate an existing template and configure it for a specific use case (for example, creating a custom Web Server template with a longer validity period), use the Certification Authority MMC snap-in (certsrv.msc). Right-click the template under Certificate Templates, select Duplicate Template, configure the new template, and then enable it on your CA:

# Add a template to the CA's issuable list
Add-CATemplate -Name "CorpWebServer" -Force

Configuring Certificate Autoenrollment via Group Policy

Autoenrollment allows domain computers and users to automatically request, receive, and renew certificates without manual intervention, which is essential for large deployments such as machine authentication certificates for Wi-Fi (802.1X) or user certificates for smart card logon. Configure autoenrollment in Group Policy:

# Create a new GPO for PKI autoenrollment
New-GPO -Name "PKI-Autoenrollment" | New-GPLink -Target "DC=corp,DC=local"

In the Group Policy Editor (gpedit.msc or gpmc.msc), navigate to Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrollment and configure it to enable autoenrollment and renew expired certificates. For user autoenrollment, configure the same setting under User Configuration.

Ensure the certificate template has the correct permissions: the target security group (e.g., Domain Computers or Domain Users) needs Read, Enroll, and Autoenroll permissions on the template. Configure these in the template’s Security tab in the Certificate Templates Console (certtmpl.msc).

Manually Requesting Certificates with certreq

For manual certificate enrollment (useful for web servers, network devices, or testing), use certreq. First create a request INF file:

[Version]
Signature = "$Windows NT$"

[NewRequest]
Subject = "CN=webserver.corp.local, O=Corp, C=US"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
KeyUsage = 0xa0

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication

[RequestAttributes]
CertificateTemplate = CorpWebServer

Then submit the request:

# Generate the CSR from the INF file
certreq -new request.inf request.csr

# Submit to the CA
certreq -submit -config "CorpIssuingCACorp-Issuing-CA" request.csr certificate.cer

# Accept/install the issued certificate
certreq -accept certificate.cer

Configuring OCSP Online Responder

The Online Certificate Status Protocol (OCSP) provides real-time certificate revocation status without requiring clients to download full CRLs. Install and configure the Online Responder role service:

Install-WindowsFeature -Name ADCS-Online-Cert -IncludeManagementTools
Install-AdcsOnlineResponder -Force

After installation, open the Online Responder Management console (ocsp.msc), add a new revocation configuration, select the CA certificate from Active Directory, and configure signing certificate autoenrollment. Add the OCSP URL to the AIA extension on your CA so issued certificates point clients to the OCSP responder:

Add-CAAuthorityInformationAccess `
    -Uri "http://ocsp.corp.local/ocsp" `
    -AddToCertificateOcsp `
    -Force
Restart-Service certsvc

CA Database Backup and Restore

Back up the CA regularly to protect the CA database and private key. The certutil tool provides built-in backup functionality:

# Back up CA database and private key to a folder
certutil -backup C:CABackup

# Back up only the CA database (not the key)
certutil -backupDB C:CABackup

# Restore the CA from backup
net stop certsvc
certutil -restore C:CABackup
net start certsvc

For full recovery capability, also export the CA certificate and private key as a PFX file to secure offline storage:

# Export the CA certificate with private key (will prompt for password)
certutil -exportPFX -p "StrongPassword123!" My "Corp-Issuing-CA" C:CABackupCAWithKey.pfx

Store the PFX file and the backup folder in a secure, access-controlled location separate from the CA server. Test your restore procedure periodically on a test environment to confirm the backup is usable before you need it in an emergency.

Web Enrollment and certutil Diagnostic Commands

The AD CS Web Enrollment role service (certsrv) provides a browser-based interface for requesting certificates. After installing it, it is accessible at http://<IssuingCA>/certsrv. Users can submit pending requests, download CA certificates, and retrieve issued certificates through this interface.

Useful certutil commands for day-to-day CA administration include:

# View all pending requests on the CA
certutil -view -restrict "Disposition=9" -out "RequestId,CommonName,NotAfter"

# View all issued certificates
certutil -view -restrict "Disposition=20" -out "RequestId,CommonName,NotAfter,CertificateTemplate"

# Revoke a certificate by serial number
certutil -revoke  0   # 0 = unspecified reason

# Publish a new CRL after revoking certificates
certutil -crl

# Verify a certificate file against the CA chain
certutil -verify certificate.cer

# Check the CA configuration and health
certutil -ping
certutil -CAInfo