Active Directory Certificate Services: build your own CA

Start DC01, SRV01 and CL01. Take a snapshot of SRV01 first (“Before PKI”). Work on SRV01 as SAATLAB\adm.rahul (an Enterprise Admin is needed to install an enterprise CA; in the lab use SAATLAB\Administrator if adm.rahul isn’t one).

1Install the enterprise root CA

On SRV01, in PowerShell as administrator:

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools | Out-Null
Install-AdcsCertificationAuthority -CAType EnterpriseRootCA -CACommonName 'SaatLab Root CA' -KeyLength 4096 -HashAlgorithmName SHA256 -ValidityPeriod Years -ValidityPeriodUnits 10 -Force
certutil -ping

You should see something like this:

ErrorId ErrorString
------- -----------
      0

Connecting to SRV01.saatlab.internal\SaatLab Root CA ...
Server "SaatLab Root CA" ICertRequest2 interface is alive (16ms)
CertUtil: -ping command completed successfully.

On CL01 (as administrator), refresh policy and look for the new root:

gpupdate /force | Out-Null
Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like '*SaatLab*' | Select-Object Subject, NotAfter

You should see something like this:

Subject                                     NotAfter
-------                                     --------
CN=SaatLab Root CA, DC=saatlab, DC=internal 19/10/2036 23:58:12

✅ Checkpoint: certutil -ping succeeds on SRV01 and CL01 trusts SaatLab Root CA without any manual import.

2Create and publish a web server template

On SRV01, run certtmpl.msc. Right-click Web Server and choose Duplicate Template. On General, set the display name to SaatLab Web Server (the template name becomes SaatLabWebServer) and validity to 1 year.

On Request Handling, tick Allow private key to be exported (useful for web farms). On Security, add SRV01$ (object type Computers) with Read and Enroll. Click OK.

Then publish it on the CA:

Add-CATemplate -Name SaatLabWebServer -Force
Get-CATemplate | Select-Object Name, Oid | Format-Table -AutoSize

You should see something like this (shortened):

Name                Oid
----                ---
SaatLabWebServer    1.3.6.1.4.1.311.21.8.4782311.10930412.1239881.2273614.8811102.42.1188392.9113401
DirectoryEmailReplication ...
DomainController    ...
WebServer           ...

✅ Checkpoint: SaatLabWebServer is in the CA’s list of published templates.

3Replace the intranet certificate

On SRV01, request a certificate and swap it into the IIS binding:

$req = Get-Certificate -Template SaatLabWebServer -SubjectName 'CN=intranet.saatlab.internal' -DnsName intranet.saatlab.internal -CertStoreLocation Cert:\LocalMachine\My
$req | Select-Object Status
$new = $req.Certificate
$b = Get-WebBinding -Name Intranet -Protocol https
$b.RemoveSslCertificate()
$b.AddSslCertificate($new.Thumbprint, 'My')
$new | Select-Object Subject, Issuer, NotAfter

You should see something like this:

Status
------
Issued

Subject                       Issuer                                         NotAfter
-------                       ------                                         --------
CN=intranet.saatlab.internal  CN=SaatLab Root CA, DC=saatlab, DC=internal    19/10/2027 23:12:40

On CL01, remove the self-signed certificate you trusted by hand in Lesson 25, then test:

Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -eq 'CN=intranet.saatlab.internal' | Remove-Item
Invoke-WebRequest -Uri https://intranet.saatlab.internal -UseDefaultCredentials -UseBasicParsing | Select-Object StatusCode

You should see this:

StatusCode
----------
       200

The page still loads with no warning, and this time the trust comes from your CA, not a hand-imported file. Do the same for the RD Web Access and RD Gateway certificates from Lesson 26 with Set-RDCertificate.

✅ Checkpoint: The intranet binding uses a certificate issued by SaatLab Root CA, and CL01 gets status 200 without the old manual trust.

4Turn on autoenrollment for workstations

In certtmpl.msc, duplicate Workstation Authentication as SaatLab Workstation. On Security, give Domain Computers Read, Enroll and Autoenroll. Then publish it with Add-CATemplate -Name SaatLabWorkstation -Force.

On DC01, create a GPO that turns on autoenrollment and link it to Workstations:

New-GPO -Name 'C-Cert-Autoenroll' | New-GPLink -Target 'OU=Workstations,OU=SAATLAB,DC=saatlab,DC=internal' | Out-Null
Set-GPRegistryValue -Name 'C-Cert-Autoenroll' -Key 'HKLM\Software\Policies\Microsoft\Cryptography\AutoEnrollment' -ValueName AEPolicy -Type DWord -Value 7 | Out-Null

AEPolicy 7 equals the GPO setting Certificate Services Client – Auto-Enrollment: Enabled, with “Renew expired certificates” and “Update certificates that use certificate templates” ticked.

On CL01 (as administrator):

gpupdate /force | Out-Null
certutil -pulse
Get-ChildItem Cert:\LocalMachine\My | Where-Object Issuer -like '*SaatLab*' | Select-Object Subject, NotAfter, @{n='Template';e={($_.Extensions | Where-Object {$_.Oid.FriendlyName -eq 'Certificate Template Information'}).Format(0).Split('(')[0]}}

You should see something like this:

CertUtil: -pulse command completed successfully.

Subject                      NotAfter            Template
-------                      --------            --------
CN=CL01.saatlab.internal     19/10/2027 23:20:05 Template=SaatLab Workstation

CL01 enrolled itself and will renew automatically before the year is up. The same method gives every workstation a certificate for Wi-Fi (802.1X), VPN or IPsec without a single manual request.

✅ Checkpoint: CL01 has a certificate from SaatLab Root CA based on the SaatLab Workstation template.

5Look at the revocation information

On CL01 (as an administrator), copy the intranet certificate from SRV01 and check its chain and revocation:

New-Item -ItemType Directory C:\Temp -Force | Out-Null
Invoke-Command -ComputerName SRV01 -ScriptBlock { Get-ChildItem Cert:\LocalMachine\My | Where-Object Subject -eq 'CN=intranet.saatlab.internal' | Sort-Object NotBefore | Select-Object -Last 1 | Export-Certificate -FilePath C:\Scripts\intranet.cer | Out-Null }
Copy-Item \\SRV01\C$\Scripts\intranet.cer C:\Temp\intranet.cer
certutil -verify -urlfetch C:\Temp\intranet.cer | Select-String 'CDP|Verified|Leaf certificate revocation|CertUtil'

You should see something like this:

  ----------------  Certificate CDP  ----------------
    Verified "Base CRL (02)" Time: 0 4c8d...
      [0.0] ldap:///CN=SaatLab%20Root%20CA,CN=SRV01,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=saatlab,DC=internal?certificateRevocationList?base?objectClass=cRLDistributionPoint
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.

The CDP tells clients where to get the revocation list: here, an LDAP path in AD, which domain members can read. Devices outside the domain need an HTTP CDP, which you’d add on the CA before issuing certificates widely.

✅ Checkpoint: certutil -verify shows a reachable CDP and “Leaf certificate revocation check passed”.