Designing a two-tier AD CS PKI: offline root, Tier 0 issuing CAs and controlled templates

Why two tiers

A single-tier PKI places the root CA key on an online, domain-joined server that handles requests day to day. If that server is compromised, the whole hierarchy is too, with no clean way to revoke the authority. A two-tier architecture separates the roles:

• a standalone root CA, offline and not domain-joined, used only to sign issuing CA certificates and publish its revocation list;
• one or more enterprise issuing CAs, domain-joined, which issue certificates to users, computers and services.

If an issuing CA is compromised, the root can revoke it and certify a new one without redistributing root trust across the estate. A third tier usually only adds complexity, unless there are specific organisational needs.

The offline root

The root stays powered off and isolated most of the time. It is only switched on to sign an issuing CA certificate or republish its CRL. Design points:

• a long validity period for the root certificate and a suitable CRL publication period, often several months, to limit ceremonies;
• a CRL republishing schedule, with an alert well before expiry: an expired root CRL can break validation of every certificate;
• protected physical storage, key backups and a documented procedure carried out with several people present;
• a CAPolicy.inf file prepared before installation to set the base parameters.

Issuing CAs are Tier 0

An enterprise CA is published in the forest's NTAuth store: the certificates it issues can be used for smart card or PKINIT authentication against domain controllers. Whoever controls that CA, or can obtain a certificate from it in an administrator's name, controls the domain. It must therefore be administered exclusively from Tier 0: dedicated accounts, privileged access workstations, protected backups, and no agent or management tool belonging to a lower tier.

Template hygiene

Most known escalation paths in AD CS stem from certificate templates and their permissions. Design rules:

1. Publish only what is needed: remove unused templates from the CAs.
2. Do not let the requester supply the subject on templates that allow authentication, or require manager approval.
3. Restrict enrolment rights to the groups that genuinely need them, and avoid "Authenticated Users" or "Domain Computers" on sensitive templates.
4. Limit extended key usages (EKUs) to the actual need; ban "any purpose" templates or templates with no EKU.
5. Control write permissions on templates and on the CA itself.
6. Disable or protect HTTP web enrolment, which is exposed to NTLM relay attacks.

CRL and AIA publishing, and HSM use

Each certificate states where to find the revocation list (CDP) and the issuer's certificate (AIA). Favour highly available HTTP publication points, reachable by all clients including those outside the domain; LDAP locations cause problems for non-joined systems. Monitor the expiry of base and delta CRLs, because an unavailable or expired CRL causes authentication failures that are hard to diagnose.

A hardware security module (HSM) protects private keys against extraction, even by a server administrator. It is strongly recommended for the most sensitive issuing CAs, and its value for the root depends on context. It brings constraints: cost, key backup through vendor-specific mechanisms, administration quorum, compatibility with the Windows version. These points must be settled before installation, as migrating an existing key into an HSM is tricky.

What an audit checks

• The hierarchy in place and whether the root is genuinely offline.
• The CRL publishing schedule and its monitoring.
• Classification of issuing CAs as Tier 0 and the identity of their administrators.
• Published templates, their enrolment rights, the supply-in-request option and EKUs.
• Exposure of web enrolment and its protection against NTLM relay.
• Protection of private keys and their backups.