From asymmetric keys to AD CS, CSRs, RAs, templates and auto-enrollment - built up step by step with motion and diagrams. Basics to advanced.
A digital certificate is a small, signed file that binds an identity (a person, computer, service) to a public key. It's a notarized "ID card" for the digital world — signed by an authority both sides trust.
Who or what is this? The Subject — e.g. dc01.contoso.com, or Alice@contoso.com.
The key the world can use to encrypt for you, or to verify your signatures.
A trusted authority's stamp — binding the identity and key together so it can't be forged.
Certificates only make sense once you've internalized asymmetric cryptography. You have two keys that are mathematically linked. Anything one locks, only the other can unlock.
Shared with the world. Inside the certificate.
-----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0B... ...J0kVf5o4K7QIDAQAB -----END PUBLIC KEY-----
Stays on your machine, never shared. Often in TPM/HSM.
-----BEGIN PRIVATE KEY----- MIIEvgIBADANBgkqhkiG9w0... ...zT8wPVmM7rQIDAQAB -----END PRIVATE KEY-----
Certificates use both: the CA signs the cert with its private key, and you use the CA's public key (which lives in your trust store) to verify the cert is authentic.
A Public Key Infrastructure (PKI) is a small ecosystem of roles that together let strangers trust each other through certificates.
CAs are arranged in a tree. The Root CA sits at the top, signs Intermediate (Issuing) CAs, which sign your everyday end-entity certificates. As long as your machine trusts the root, it trusts the whole chain.
Self-signed. Offline.
Trust anchor.
Online. Day-to-day signing.
Domain-joined in AD.
User, computer,
web server, code-signing.
If the root is offline and only signs the issuing CAs, an attacker who breaches the issuing CA can't compromise the root. You can revoke the issuing CA and re-issue, without burning the entire trust store on every machine.
When a server hands you its certificate, your client walks upward: this cert is signed by Issuing CA → whose cert is signed by Root CA → which I already trust. If any link is missing, expired, or revoked, validation fails.
A CSR (PKCS#10) is the message a subscriber sends to a CA saying "please issue me a cert, here's my public key and the identity I'm claiming." It's signed with the matching private key to prove the requester actually holds it.
Subscriber generates a fresh private/public key pair locally. The private key never leaves the machine.
The CSR contains: the desired Subject (CN, SAN, etc.), the public key, and a self-signature using the private key.
CA verifies the self-signature (proof of possession), checks identity (often via the RA), and issues the certificate.
These fields are what tools like certreq, openssl, or AD's MMC snap-in collect.
-----BEGIN CERTIFICATE REQUEST----- Click "Generate CSR" to see the PEM output appear here... -----END CERTIFICATE REQUEST-----
The CSR carries the public key. The CA never sees the private key. This means a compromise of the CA leaks no subscriber private keys — only the CA's own signing key matters for the entire trust hierarchy.
An RA is the "front desk" for the CA. It does the human and process work of verifying that a request really should be honored, before passing the request to the CA for issuance. The CA is the signer; the RA is the vetter.
| Certificate Authority (CA) | Registration Authority (RA) | |
|---|---|---|
| Primary job | Cryptographically sign & issue the certificate. | Authenticate & authorize the request. |
| Holds private signing key? | Yes — the most sensitive key in the PKI. | No (but may have its own enrollment-agent key). |
| Touches end users? | Usually not. Often offline / hardened. | Yes — reviews requests, identity proofs. |
| In Microsoft AD CS | Enterprise CA / Standalone CA role. | Enrollment Agent, NDES, CES/CEP, manager approval. |
Depending on the certificate template's policy, the RA may:
Help-desk staff act as Enrollment Agents — an EA cert lets them sign smart-card requests on behalf of a user. The CA trusts the EA's signature because of the EA's certificate. That's classic RA behavior: the CA didn't meet the user, but the EA did.
When you install the Active Directory Certificate Services role on Windows Server, you get a full PKI integrated with AD. AD itself becomes the directory (LDAP) where root certificates and CRLs are published, so every domain-joined machine automatically trusts the enterprise CA.
The signing service. Two flavors:
Enterprise CA — integrated with AD, supports templates, auto-enrollment.
Standalone CA — works without AD, manual approval only.
An IIS site (/certsrv) where users submit CSRs and download certs from a browser. Old-school but still around.
Modern HTTPS-based enrollment for non-domain-joined or remote machines. CEP tells the client what templates exist; CES handles the actual issuance.
Implements the SCEP protocol so network devices (routers, switches, mobile devices via MDM) can enroll without AD credentials.
Answers real-time "is this cert revoked?" queries with a small signed response, instead of forcing clients to download the whole CRL.
Stored in AD. Each template defines: who can enroll, what extensions/EKUs the cert gets, validity period, key length, whether auto-enrollment is allowed, and if a manager must approve.
Because every domain-joined client already authenticates to AD with Kerberos, the CA can trust the requester's identity automatically. Combined with Group Policy — which can push the root CA into every trust store and turn on auto-enrollment — you get a network-wide PKI that "just works" for users without any manual cert handling.
Click each step to walk through what happens when an AD user or computer requests a certificate. This is the canonical flow for an Enterprise CA with auto-enrollment via Group Policy.
A certificate isn't a "set and forget" artifact. It's issued, used, renewed before expiry, and possibly revoked — with revocation status published so relying parties can check.
Each step is governed by template settings & policy.
A signed list of all revoked certificate serial numbers, published by the CA on a schedule (e.g., every 7 days). The CA publishes it to the location named in each cert's CRL Distribution Points extension — usually a URL on a web server and an LDAP path inside AD.
Instead of downloading a megabyte CRL, the client asks an Online Responder "is serial 4F8A21 still good?" and gets back a tiny signed answer. Faster, more current, easier to scale.
Once you have AD CS humming, certificates show up everywhere in a Windows estate. Here are the heavy hitters.
Users insert a smart card / YubiKey containing a cert; Kerberos PKINIT validates it against AD. Strong, phishing-resistant auth.
Computers and users authenticate to the network with their certs, no shared passwords needed.
DCs need certs for LDAPS, smart card logon, and modern authentication. Auto-enrolled via the Domain Controller Authentication template.
NTFS file encryption uses a per-user EFS certificate; the private key encrypts file keys at rest.
Outlook can sign & encrypt mail using a user cert from your enterprise CA.
Developers sign PowerShell scripts, MSI installers, and binaries so they're trusted (and not blocked) on managed endpoints.
Web Server template issues TLS certificates for internal sites — SharePoint, intranet apps, RDS gateways.
Intune or another MDM uses NDES + SCEP to push device-auth and Wi-Fi certs to phones automatically.
Always-On VPN and site-to-site IPsec tunnels authenticate the gateway and client with certificates.
Most shops run two tiers: an offline Root CA + an online Enterprise Issuing CA. Larger orgs add a middle Policy CA tier between them, useful when different business units need different policies but should still chain to a single root.
The CA's private signing key is the crown jewel. Storing it in a FIPS 140-2 / 140-3 HSM means the key can't be exported — the CA software calls the HSM to perform the signature, but the key itself never leaves hardened hardware.
For encryption certs (e.g., EFS, S/MIME), losing the private key means losing the data. AD CS can archive private keys at issuance time, encrypted to a Key Recovery Agent's cert. A KRA can later recover the key for the user.
Two organizations can cross-certify each other's roots so their users trust each other's certs without merging trust stores. Federal Bridge CAs are the classic example.
Modern TLS (and AD-issued web server certs) use SAN entries for hostnames, not the legacy CN field. A single cert can cover many hostnames via multiple DNS SANs.
Microsoft now requires the certificate to strongly map to an AD account (via SID extension), to prevent attackers from impersonating users by manipulating templates. Modern AD CS hardening is a topic of its own.
The same paradigm that drives Let's Encrypt (ACME) is now appearing inside enterprise PKIs. Some shops front AD CS with ACME or EST endpoints to support Linux, Kubernetes, and IoT workloads.
RSA and ECDSA are vulnerable to future quantum computers. PKI vendors and Microsoft are starting to add hybrid & PQ algorithms (ML-DSA / Dilithium, ML-KEM / Kyber) to certificate stacks. Long-lived roots are the first to migrate.
Terms you'll see in AD CS docs, KDC logs, and security audits.
-----BEGIN…----- blocks.alice@contoso.com) — how AD identifies users.