Your Very Own Certificate Authority: A Home Lab PKI with AD CS

Hi there! It's BOB.

Every home lab reaches the same moment. You've built a domain, a file server, a web server, maybe a little dashboard or two. You open one of them in your browser and…

"Your connection is not private."

Rude! You built this thing. You know it's private.

You could click Advanced → Continue anyway for the rest of your life. Or you could do what real networks do and run your own certificate authority. Today we're going to set one up with Active Directory Certificate Services (AD CS), and we're going to keep it simple. No four-tier hierarchy, no hardware security modules, no meetings. Just enough PKI to make your lab happy.

Let's go!

PKI in 60 Seconds

PKI (Public Key Infrastructure) is a fancy name for a simple idea: someone everybody trusts vouches for who's who.

• A certificate authority (CA) is the someone. It signs certificates.
• A certificate says "this public key belongs to web01.lab.contoso.com," and the CA's signature proves it.
• A root certificate is the CA's own certificate. If a computer has your root in its Trusted Root Certification Authorities store, it trusts everything your CA signs.

So the whole job comes down to three steps: build a CA, hand out certificates, and get the root onto every machine. That's it. That's the article.

One Tier or Two?

In a real company, Microsoft recommends a two-tier design: an offline root CA that's powered off and locked away, plus an enterprise subordinate CA that does the day-to-day issuing. If the issuing CA ever gets compromised, the root is safe in its drawer.

For a home lab, a single enterprise root CA is perfectly fine. That's what we're building.

💡 BOB's tip: Want to practice for your day job? Build the single tier first, get comfortable, then tear it down and try two tiers later. Labs are for breaking things on purpose!

Best Practices (Even in a Lab)

A few habits that save you a world of hurt:

• Don't install the CA on a domain controller. It works, but it makes both roles harder to fix, move or rebuild. Give the CA its own small member server (2 vCPU and 4 GB RAM is plenty).
• Set the computer name first, and never change it. Once AD CS is installed, the server's name and domain membership are locked in.
• Give the CA a nice name, not the hostname. Contoso Lab Root CA is friendlier than SRV-CA01-CA when you see it on every certificate for the next ten years.
• Use SHA-256 and a big key. RSA 4096 for the root, 2048 for the certificates it issues.
• Pick a sensible lifetime. Ten years for the root is a nice lab number. Long enough to forget about, short enough that you'll eventually practice renewing it.
• Back it up. If the CA's private key is lost, every certificate it issued becomes an orphan.

1. Prepare a CAPolicy.inf (optional, but nice)

Before installing the role, you can drop a file called CAPolicy.inf into C:\Windows on the CA server. Windows reads it during setup.

[Version]
Signature="$Windows NT$"

[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10
LoadDefaultTemplates=0

The important line is LoadDefaultTemplates=0. Without it, your new CA immediately starts offering a big pile of default templates. With it, the CA starts with a clean slate and issues only what you publish.

2. Install the CA

On your CA server, open PowerShell as an account that's a member of Enterprise Admins (an enterprise CA writes to Active Directory, so it needs the big keys):

# Add the role
Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

# Configure it as an enterprise root CA
Install-AdcsCertificationAuthority `
    -CAType EnterpriseRootCa `
    -CACommonName "Contoso Lab Root CA" `
    -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
    -KeyLength 4096 `
    -HashAlgorithmName SHA256 `
    -ValidityPeriod Years `
    -ValidityPeriodUnits 10

Prefer clicking? Server Manager → Add Roles and Features → Active Directory Certificate Services → Certification Authority, then the yellow flag to configure it. Same answers.

Two quick settings while you're here:

# Let issued certificates live up to 2 years (the CA caps whatever the template asks for)
certutil -setreg CA\ValidityPeriodUnits 2
certutil -setreg CA\ValidityPeriod "Years"

# Keep the revocation list fresh for a month, since lab servers get turned off a lot
certutil -setreg CA\CRLPeriodUnits 4
certutil -setreg CA\CRLPeriod "Weeks"

Restart-Service certsvc
certutil -crl                # publish a fresh revocation list now

⚠️ Heads up: That CRL setting matters more than it looks. The CA publishes a certificate revocation list (CRL) that says "these certificates are no longer good." If your CA VM is powered off longer than the CRL is valid, clients can't check revocation and some apps start refusing perfectly good certificates. A longer CRL period is a lab-friendly kindness.

3. Templates: The Cookie Cutters

A certificate template is a recipe: what the certificate is for, how long it lasts, whose name goes in it, and who's allowed to ask for one. You never edit the built-in templates. You duplicate them and edit the copy.

Open Certification Authority (certsrv.msc), right-click Certificate Templates → Manage.

A template for web servers

1. Right-click Web Server → Duplicate Template.
2. Compatibility tab: set both boxes to the oldest Windows version in your lab (Windows Server 2016 / Windows 10 is a safe pick).
3. General tab: name it Lab Web Server. Set the validity period to 1 year or 2 years.
4. Request Handling tab: check Allow private key to be exported. Handy in a lab when you want the same certificate on an appliance or a Linux box.
5. Subject Name tab: leave Supply in the request selected. Web servers often have extra names, so the requester provides them.
6. Security tab: add a group (for example Lab Web Servers, or just your admin account) and give it Read and Enroll.

A template for every server

For "every domain-joined server gets a certificate automatically," duplicate the Computer template instead:

1. Right-click Computer → Duplicate Template, name it Lab Server.
2. Subject Name tab: leave Build from this Active Directory information with DNS name checked. Windows fills in the server's own name for you.
3. Security tab: add Domain Computers (or a "Lab Servers" group) with Read, Enroll and Autoenroll.

Publish them

Back in Certification Authority, right-click Certificate Templates → New → Certificate Template to Issue, and pick your two new templates. A template the CA hasn't published might as well not exist.

4. Turn On Autoenrollment

Let Group Policy hand out the server certificates for you. In Group Policy Management, edit a GPO linked to your servers (or the whole domain):

Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client – Auto-Enrollment

Set it to Enabled and check both Renew expired certificates… and Update certificates that use certificate templates.

On a server, nudge it along:

gpupdate /force
certutil -pulse              # trigger autoenrollment right now

Open certlm.msc → Personal → Certificates. A shiny new certificate from your CA should be waiting. 🎉

💡 BOB's tip: Bonus round! In the same GPO, go to Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security → Server authentication certificate template and enter LabServer (the template's name, without spaces, not its display name). Now Remote Desktop uses your CA's certificate instead of a self-signed one, and those RDP warnings go away.

5. Get a Web Server Certificate

On a Windows web server:

Get-Certificate -Template LabWebServer `
    -SubjectName "CN=web01.lab.contoso.com" `
    -DnsName web01.lab.contoso.com, web01, intranet.lab.contoso.com `
    -CertStoreLocation Cert:\LocalMachine\My

The -DnsName list becomes the Subject Alternative Name (SAN). Every name people type into a browser must be on that list. Then bind the certificate to the site in IIS Manager → Site → Bindings → https.

For a Linux box or an appliance, make a request (CSR) there, copy it to a Windows machine, and submit it:

certreq -submit -attrib "CertificateTemplate:LabWebServer" web01.csr web01.cer

6. Get the Root Certificate Everywhere

Here's the good news: domain-joined Windows machines already trust your root. An enterprise CA publishes its certificate into Active Directory, and every domain member picks it up during Group Policy refresh. Check on any member:

Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like "*Contoso Lab Root CA*"

For everything else, export the root first:

certutil -ca.cert C:\Temp\ContosoLabRootCA.cer

Then:

7. Back Up Your CA

Last step, and the one everyone skips:

Backup-CARoleService -Path C:\CABackup -Password (Read-Host -AsSecureString "Backup password")

That saves the CA's private key and its database. Copy the folder somewhere that isn't the CA server, and store the password somewhere safe (a password manager, not a sticky note on the monitor. I've seen the sticky notes.)

Wrapping Up

So there you have it:

• A single enterprise root CA on its own member server is plenty for a home lab.
• Use SHA-256, a 4096-bit root key, a nice CA name, and don't put it on a domain controller.
• Duplicate the Web Server and Computer templates, set permissions, and publish them.
• Autoenrollment hands out server certificates for you.
• Domain members trust the root automatically. Everything else gets the exported .cer.
• Back up the CA. Future you says thanks.

And when something does go wrong (it will, it's a lab!), check out my next article on troubleshooting certificates in the home lab.

See you next time!

— BOB

Sources

• Microsoft Learn: Install-AdcsCertificationAuthority
• Microsoft Learn: Install the Certification Authority
• Microsoft Learn: CAPolicy.inf syntax
• Microsoft Learn: Configure certificate autoenrollment
• Microsoft Learn: Get-Certificate
• Microsoft Learn: Backup-CARoleService
• Microsoft Learn: Distribute certificates to client computers by using Group Policy
• Ubuntu Server docs: Install a root CA certificate in the trust store