Windows Server 2025 / What AD CS Does and How to Plan an Internal PKI
Active Directory Certificate Services (AD CS) issues and manages organizational certificates. Before installing it, design the trust hierarchy, enrollment permissions, revocation, renewal, recovery, and operational ownership for the intended users, devices, and services.
Decide whether an internal CA is needed
AD CS can operate a certificate authority (CA) within a public key infrastructure (PKI). A CA signs certificates connecting an identity with a public key. Clients must trust that authority and validate the certificate for the intended purpose.
Repeated internal web certificate renewal or managed-device authentication can justify an organizational PKI. An internal CA is not automatically trusted by every browser. Publicly trusted certificates may better fit public services used by unmanaged clients.
Start with the AD CS overview and inventory existing organizational PKI or managed issuance services. One HTTPS site does not automatically require deploying a new CA.
Define the hierarchy and trust boundaries
| Decision | Question |
|---|---|
| Root and issuing CAs | Where is the top-level key held, and by whom? |
| Enterprise or standalone | Are AD integration, templates, and autoenrollment required? |
| Online or offline | Which tier issues continuously, and which remains separated? |
| Unmanaged clients | How will trust and revocation information reach them? |
An offline root and online issuing CA is one design to evaluate against scale, threats, and recovery capability. More tiers do not automatically improve security.
Use PKI design considerations to decide CA and server names, key protection, lifetimes, and publication URLs before installation. Do not treat renaming an installed CA server as a routine adjustment. Consider management separation and key protection before combining a CA with a domain controller.
Limit template and enrollment permissions
Certificate templates define purpose, key policy, validity, and enrollment conditions. Extended Key Usage (EKU) identifies uses such as server or client authentication. Unrestricted issuance of identity-capable certificates can enable impersonation.
- Separate requesters from approval and issuance administrators.
- Decide whether requesters may supply names and how those names are validated.
- Limit private-key access and decide whether export is actually required.
- Scope autoenrollment to approved purposes and groups, monitoring failures and results.
Review abuse potential before granting broad template permissions to groups such as Authenticated Users. Separate CA, certificate, and ordinary server administration as appropriate. Consult CA security, delegation, and auditing guidance.
Operate revocation and renewal paths
Plan certificate revocation for compromised keys, departing users, and retired servers. A certificate revocation list (CRL) publishes revoked certificates; Authority Information Access (AIA) identifies issuer information and related access locations. Required validation paths must be reachable by the actual clients.
Internal-only DNS or LDAP publication can be unsuitable for external clients. A stopped CA does not immediately invalidate every issued certificate, but issuance, renewal, and revocation-publication outages have distinct effects. Application and client policy also affects validation behavior.
Coordinate root, issuing CA, and service-certificate renewal. Requesting a long service lifetime does not override the issuer’s remaining validity and policy. Verify the certificate a service presents, not merely the presence of a new store entry.
Document key protection and recovery before deployment
A compromised CA private key can affect an entire trust scope. Consider a hardware security module (HSM), restricted administration paths, and separated responsibilities where appropriate. Plan supported backups of keys, database, configuration, policy, and publication information with restricted access and a tested recovery process.
- Inventory certificate consumers, purposes, and expected demand.
- Assign an owner and explain reuse of existing PKI or the need for a new one.
- Design CA structure, key protection, templates, permissions, and trust distribution.
- Define revocation publication, renewal alerts, backups, and isolated recovery.
- Validate issuance, names, renewal, revocation, and recovery in a separate test environment.
The deliverable here is a design and review checklist. Do not install a CA on course server DC1 or distribute a test root to real devices as part of this planning exercise. A deployment decision needs maintainable procedures and a trust-removal or service-transition plan.
