Hierarchy and installation

Almost every production ADCS deployment is two tiers: an offline root that signs one or more issuing CAs, and issuing CAs that sign the certificates used daily. Trust flows downwards; policy and control flow upwards.

1. 1

   Install the offline root

   Standalone CA, not domain joined, often on a hardened host that is then disconnected.

2. 2

   Configure and sign the root certificate

   Define validity, key length and policy in CAPolicy.inf before the CA is created.

3. 3

   Publish the root

   Distribute it to clients by Group Policy or your management platform — never by email link.

4. 4

   Install issuing CAs

   Enterprise CAs, domain joined, with their own keys protected.

5. 5

   Submit the issuing CA request to the root

   Take the request file to the offline root, sign it, and install the resulting certificate.

6. 6

   Publish CRLs and AIA

   Make revocation data reachable from every client that will validate these certificates.

CAPolicy.inf is a configuration file read when a CA is installed or its certificate is renewed. It is where long-lived decisions are recorded, which matters because a CA outlives the team that built it.

[Version]
Signature="$Windows NT$"

[PolicyStatementExtension]
Policies=InternalPolicy

[InternalPolicy]
OID=1.3.6.1.4.1.99999.1.1
Notice="For internal use only"

[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
CRLPeriod=Weeks
CRLPeriodUnits=1
CRLDeltaPeriod=Days
CRLDeltaPeriodUnits=1

Two of these settings deserve attention: CRL publication cadence, which decides how stale revocation data can get, and renewal key length, which decides whether you must re-key within the CA's lifetime.

• CA name and distinguished name — changing these later is effectively impossible
• Validity period of the CA certificate, and whether issuing CA lifetimes fit under it
• Key algorithm and length, chosen for the estate's lifetime, not today's convenience
• CRL and AIA URLs, reachable from every client including remote and non-domain devices
• Crypto API providers and whether an HSM is required by policy
• Backup, restore and disaster recovery plan, rehearsed before the CA issues anything