Homelab Build — Part 7 — Certificate Authority

What This Part Covers

Part 6 made sure every machine in the lab agrees on the time, which matters here because certificate validity is a time window — a client with a clock five hours off will reject a perfectly good certificate as not-yet-valid or expired. This part builds on that by giving the lab its own certificate authority (CA), so later parts can issue certificates for LDAPS, RDP, internal web services, and anything else that benefits from TLS instead of relying on self-signed certificates or a public CA that has no reason to trust an internal hostname.

The Root-Versus-Subordinate Decision

Think of a two-tier PKI hierarchy the way a company handles its master keys: the root CA is the master key, kept in a safe and touched as rarely as possible, while one or more subordinate CAs are the keys office staff actually use every day. A production PKI usually follows exactly that shape — a standalone root CA that’s built, used once to certify a subordinate, and then shut down or air-gapped, with an Enterprise Subordinate CA handling every real certificate request while domain-joined and always reachable.

That two-tier design exists to limit the blast radius of a compromise: if the root’s private key is only ever online for the few minutes it takes to sign a subordinate’s certificate, there’s a vanishingly small window for an attacker to steal it. Losing an issuing subordinate CA is bad but recoverable — revoke its certificate and issue a new one from the still-secure root. Losing the root CA’s key means rebuilding the entire trust hierarchy from scratch.

Running the CA role on a domain controller specifically is also worth calling out on its own: it works, because both roles ultimately depend on the same domain, but it means the CA’s private key material now lives on a Tier-0 asset that already has to be protected to the highest standard anyway. For this lab, that’s an acceptable simplification. It’s not one to carry into a production deployment without deciding that trade-off deliberately.

Installing the Root CA on dc01

Installing AD CS is a two-step process: add the Windows feature, then run the cmdlet that actually creates the CA and its self-signed root certificate. Because dc01 is already domain-joined and the account running this is a Domain Admin (a superset of what Enterprise Admin requires), no additional domain prep is needed first.

# On dc01: install the Certification Authority role and its management tools
Install-WindowsFeature -Name ADCS-Cert-Authority -IncludeManagementTools

# Configure it as an Enterprise Root CA — RSA 2048-bit key, SHA256, 10-year root validity
$params = @{
    CAType                    = "EnterpriseRootCa"
    CACommonName              = "LAB-Root-CA"
    CADistinguishedNameSuffix = "DC=lab,DC=example,DC=com"
    CryptoProviderName        = "RSA#Microsoft Software Key Storage Provider"
    KeyLength                 = 2048
    HashAlgorithmName         = "SHA256"
    ValidityPeriod            = "Years"
    ValidityPeriodUnits       = 10
}
Install-AdcsCertificationAuthority @params -Force

Because this is an Enterprise CA, there’s no manual root-certificate distribution step the way there would be with a standalone root — that automatic AD publication is the main practical advantage of accepting the DC co-location trade-off in a lab this size.

Publishing a Certificate Template

A fresh CA doesn’t publish every available template by default — it has to be told which ones it’s allowed to issue. To let dc02 request a web-server-style certificate later in this part, publish the built-in WebServer template explicitly.

# On dc01: list templates the CA currently offers
certutil -CATemplates

# Publish the WebServer template so clients can request it
certutil -SetCATemplates +WebServer

# Confirm it now appears in the CA's published list
certutil -CATemplates

Autoenrollment — letting domain members request and renew certificates on their own, without an administrator approving each request — is out of scope for this part beyond a pointer: it’s configured through Group Policy at Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client – Auto-Enrollment, and the target template’s permissions need both Enroll and Autoenroll granted, not just Enroll. The AD CS conceptual post covers that end to end; this part sticks to a manual, on-demand request so the CA can be verified working before layering GPO-driven automation on top of it.

Issuing the Lab’s First Certificate

dc02 is the only other domain-joined machine standing in the lab so far, which makes it the natural first client. Because dc02 is domain-joined, it can request a certificate directly from the CA over LDAP using Windows integrated authentication — no web enrollment page needed.

# On dc02: request a certificate using the WebServer template,
# authenticating to the CA directly rather than through a web front end
Set-Location -Path Cert:\LocalMachine\My
Get-Certificate -Template WebServer -Url ldap: -CertStoreLocation Cert:\LocalMachine\My

# Confirm the certificate landed in dc02's local machine store
Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*dc02*" }

Verifying the CA

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

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

# Display the CA's own configuration, including its current certificate and CRL status
certutil -CAInfo

# List templates currently published on the CA
certutil -CATemplates

Certificate Authority Setup Issues

Final Thoughts

The lab now has an internal PKI, even in the simplified single-tier shape this part chose deliberately. dc01 can issue certificates, dc02 has proven it can request and receive one, and every later part of this series that wants LDAPS, an internal web service, or any other TLS-backed component has somewhere to get a trusted certificate from.

What’s still missing on purpose: autoenrollment isn’t configured, so every certificate beyond this part’s manual test has to be requested by hand, and the CA is still co-located on a domain controller rather than split into the offline-root-plus-subordinate shape a production PKI would use. Both are reasonable next steps if this lab ever needs to behave more like the real infrastructure it’s modeled on.