AD CS / PKI - Skills - Bill Gernert

What it is & why I use it

The lab runs its own internal certificate authority (AD CS) as the root of trust for private services. Certificates it issues let internal systems prove who they are and encrypt traffic without leaning on a public CA for names that never leave the lab. It is the machine-identity counterpart to the human-identity work in the directory.

I run my own PKI because trust has to come from somewhere, and for internal names that somewhere should be under my control and understood end to end - not a black box. Owning the CA means owning what a certificate from it actually attests to.

How I use it in the lab

A root of trust for internal names. The CA anchors trust for services that are only ever reached inside the lab, so those can be properly TLS-protected without a public certificate.
Templates define what can be issued. Certificate templates control what kinds of certs exist and who may enroll for them - they are the policy layer of the CA, not just a convenience.
Scoped enrollment. Enrollment permissions are kept tight, so the ability to obtain a given class of certificate is a deliberately granted privilege.
Revocation as a real path. A compromised or retired certificate can be revoked, and clients are expected to check revocation - which only works if the revocation information is actually reachable (see the gotcha).

Architecture

Diagram coming Root of trust -> templates (what may be issued, and to whom) -> issued certs -> revocation distribution that clients check. Scrubbed of the CA name, host, and addresses.

In action

Screenshot coming A template's enrollment permissions and an issued certificate chaining to the internal root. Captured per the publishing checklist - CA name, hostnames, and addresses redacted.

Lessons learned & gotchas

Gotcha - a certificate template is a privilege escalation path The dangerous misconfiguration in a PKI is not a weak key - it is an over-permissive template. If a template that issues an authentication-capable certificate lets a low-privilege user both enroll and supply their own identity, that user can effectively mint a credential that impersonates someone more privileged. The CA was configured to do exactly what it was told; the mistake was telling it that a broad group could enroll for a powerful certificate. Templates have to be treated as authorization policy: who may enroll, for what, and whether they can influence the subject - reviewed as carefully as any other grant of privilege.

Revocation fails closed - so its endpoint is critical. If clients are checking revocation and the distribution point is unreachable or the revocation list is stale and expired, strict clients reject valid certificates. The revocation path is infrastructure you have to keep healthy, not a set-and-forget detail - a dead CRL endpoint is an outage of everything that trusts the CA.
Protect the root above all. The root's private key is the whole ballgame - anything it signs is trusted. It gets the most protection and the least routine exposure, because a compromised root is not a certificate problem, it is a start-over.
Short-lived beats never-expiring. A certificate you must remember to revoke is a liability; one that expires on its own limits the damage window when revocation is missed. Lean on lifetime as a backstop to revocation, not a replacement for it.

Impact

1

internal root of trust

Templates

as a privilege boundary

Checked

revocation, kept reachable

The internal CA is what lets private services have real, verifiable identity instead of self-signed guesswork. The lasting lesson is that a PKI's risk lives in its policy, not its cryptography: an over-broad template hands out privilege, and a neglected revocation endpoint takes trust down with it. Treat the boring parts - templates and revocation - as the security surface they actually are.

Code & further reading

PKI notes (link coming) AD CS overview

Any published PKI notes are scrubbed of the CA name, issuing hosts, addresses, and template detail before they go public.