Build a Two-Tier Microsoft PKI with an Offline Root CA

This guide builds a two-tier Microsoft Active Directory Certificate Services hierarchy with an offline standalone Root CA and a domain-joined Enterprise Issuing CA. The design keeps the highest-value signing key offline while allowing the issuing CA to use Active Directory certificate templates and autoenrollment.

Plan before installing: CA names, certificate lifetimes, key protection, AIA locations, CRL distribution points, publication procedures, and recovery processes are difficult to change later. Build and validate this design in a lab before using it in production.

Architecture

Offline Root CA: A standalone, non-domain-joined server used only to sign issuing-CA certificates and publish Root CA revocation information.
Enterprise Issuing CA: A domain-joined server that processes normal certificate requests and uses Active Directory certificate templates.
HTTP publication point: A stable web location, separate from the offline Root CA, where clients can retrieve CA certificates and certificate revocation lists.

A virtual or physical Root CA can be appropriate if its host, storage, backups, administrative access, and offline state are protected. The important requirement is not the form factor—it is protecting the Root CA private key and keeping the system isolated except during controlled maintenance.

Example Values Used in This Guide

Setting	Example
Root CA computer	`ROOTCA01`
Root CA common name	`Example Organization Root CA`
Issuing CA computer	`ISSUINGCA01`
Issuing CA common name	`Example Organization Issuing CA 01`
Publication hostname	`pki.example.org`
Publication path	`http://pki.example.org/pki/`

Replace every example with names governed by your organization’s naming standard. CA common names become part of the certificate hierarchy and should be treated as long-lived identifiers.

1. Complete the PKI Design

Document and approve these decisions before installing AD CS:

Root and issuing CA names
Root and issuing CA certificate lifetimes
Key algorithm, size, provider, and whether an HSM is required
Root CA activation, shutdown, and removable-media procedures
HTTP AIA and CDP names that can remain stable through server replacements
CRL validity, overlap, publication, monitoring, and emergency revocation procedures
CA administrator roles and approval requirements
Database, private-key, configuration, and system-state backups
Certificate templates and intended enrollment methods
CA renewal and decommission dates

Lifetime rule: A CA cannot issue a certificate that remains valid beyond the CA’s own certificate. Record renewal milestones as operational tasks rather than relying on someone to remember them years later.

2. Build the HTTP Publication Point

Create a stable HTTP location such as http://pki.example.org/pki/. It can be hosted on IIS or another highly available web service, but it should not depend on the Root CA being online. Allow anonymous read-only access to CA certificate and CRL files.

Use HTTP rather than a server-specific hostname so the publication service can move without changing certificates. Microsoft notes that CDP processing supports HTTP and that non-Windows clients commonly rely on HTTP locations.

HTTP is intentional: CRLs and CA certificates are digitally signed. Availability is the main purpose of the publication point. Microsoft’s CAPolicy.inf documentation does not support HTTPS URLs in CDP entries.

3. Prepare the Offline Root CA

Install a supported Windows Server release and current security updates.
Rename the server before installing AD CS.
Do not join it to Active Directory.
Disconnect it from normal production networks.
Use a unique local administrator credential stored through your privileged-access process.
Disable or remove unnecessary services, software, and remote-management paths.
Record the build configuration and establish an offline backup procedure.

4. Create the Root CA CAPolicy.inf

CAPolicy.inf must exist in C:\Windows before AD CS is installed. Create it with Notepad and save it as All Files so Windows does not append .txt.

[Version]
Signature="$Windows NT$"

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

[CRLDistributionPoint]

[AuthorityInformationAccess]

The empty CRL Distribution Point and Authority Information Access sections omit those extensions from the self-signed Root CA certificate. A root certificate has no higher issuer to locate, and Windows does not perform revocation checking on the Root CA certificate itself. Delta CRLs are disabled because an offline Root CA should issue and revoke certificates infrequently.

Compatibility: The example uses modern cryptography and an alternate signature algorithm. Validate compatibility with every critical device, application, and operating system in your environment. Organizations with legacy clients or hardware may need different settings.

5. Install the Standalone Root CA

From an elevated PowerShell session:

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

Install-AdcsCertificationAuthority `
  -CAType StandaloneRootCA `
  -CACommonName "Example Organization Root CA" `
  -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
  -KeyLength 4096 `
  -HashAlgorithmName SHA256 `
  -ValidityPeriod Years `
  -ValidityPeriodUnits 20 `
  -Force

If you use an HSM or another key-storage provider, follow that vendor’s supported installation and backup procedure instead of selecting the Microsoft software provider shown above.

6. Configure Root CA Issuance and CRL Settings

The Root CA will issue the Enterprise Issuing CA certificate. Set an appropriate subordinate-CA validity period before processing that request. The example below uses ten years and a 26-week Root CA CRL with a 12-hour overlap:

certutil -setreg CA\ValidityPeriod "Years"
certutil -setreg CA\ValidityPeriodUnits 10
certutil -setreg CA\CRLPeriod "Weeks"
certutil -setreg CA\CRLPeriodUnits 26
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLOverlapPeriod "Hours"
certutil -setreg CA\CRLOverlapPeriodUnits 12

Restart-Service certsvc

Choose values that match your documented maintenance frequency and risk tolerance. The next Root CA CRL must be published before the current one expires.

7. Configure the Root CA AIA and CDP

Open Certification Authority, right-click the Root CA, select Properties, and open the Extensions tab. Configure locations that will be included in certificates issued by the Root CA.

Example HTTP CDP:

http://pki.example.org/pki/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

Example HTTP AIA:

http://pki.example.org/pki/<ServerDNSName>_<CaName><CertificateName>.crt

Select the options that include the CDP in issued certificates and include the AIA location in issued certificates. Remove publication locations you do not operate. Restart Certificate Services when prompted.

Do this before issuing the subordinate CA certificate. Changing AIA or CDP URLs later affects only newly issued certificates. Existing certificates keep their original URLs.

8. Publish the Root CA Certificate and CRL

Generate a new Root CA CRL:

certutil -crl
Get-ChildItem C:\Windows\System32\CertSrv\CertEnroll\*.cr*

Copy the Root CA certificate and CRL from C:\Windows\System32\CertSrv\CertEnroll to approved removable media. Do not connect to the Root CA using an administrative file share. Move the public files to the HTTP publication point through your documented transfer process.

From a domain-joined administrative system using an appropriately delegated account, publish the Root CA certificate to Active Directory and install the certificate and CRL locally:

certutil -dspublish -f "ExampleRootCA.crt" RootCA
certutil -addstore -f Root "ExampleRootCA.crt"
certutil -addstore -f Root "ExampleRootCA.crl"

Verify that domain clients receive the Root CA certificate and that the HTTP certificate and CRL URLs are reachable before continuing.

9. Prepare the Enterprise Issuing CA

Install and patch a supported Windows Server release.
Rename the server before installing AD CS.
Join it to the domain.
Assign a static address and confirm DNS and time synchronization.
Use separate database and log volumes if required by your capacity and recovery design.
Confirm the server trusts the Root CA certificate and can retrieve the Root CA CRL from HTTP.

Create C:\Windows\CAPolicy.inf before installation:

[Version]
Signature="$Windows NT$"

[Certsrv_Server]
RenewalKeyLength=3072
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=1

LoadDefaultTemplates=0 prevents the CA from automatically enabling default certificate templates before you have reviewed enrollment permissions and intended use.

10. Install the Enterprise Subordinate CA

Create a protected directory for the request, then install the role and generate a subordinate CA request:

New-Item -ItemType Directory -Path C:\CARequest

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

Install-AdcsCertificationAuthority `
  -CAType EnterpriseSubordinateCA `
  -CACommonName "Example Organization Issuing CA 01" `
  -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
  -KeyLength 3072 `
  -HashAlgorithmName SHA256 `
  -OutputCertRequestFile C:\CARequest\IssuingCA01.req `
  -Force

The CA service cannot start until the Root CA signs this request and the resulting subordinate CA certificate is installed.

11. Sign the Issuing CA Request Offline

Copy only IssuingCA01.req to approved removable media.
Follow your Root CA activation procedure and start the offline Root CA.
Open Certification Authority.
Right-click the CA and select All Tasks → Submit new request.
Select the request file.
Open Pending Requests, inspect the request, and verify its subject, key size, and intended CA role.
Right-click the approved request and select All Tasks → Issue.
Open Issued Certificates and export the issued subordinate CA certificate as a Base-64 certificate or a PKCS #7 file that includes the certification path.
Publish a fresh Root CA CRL.
Transfer the issued certificate, Root CA certificate, and current Root CA CRL using approved removable media.
Shut down and secure the Root CA according to the offline procedure.

Do not use the Root CA’s C$ share. An offline Root CA should not be placed on the production network for convenience. Use a controlled, logged transfer process and scan removable media before and after use.

12. Complete the Issuing CA Installation

On the issuing CA, confirm the current Root CA certificate and CRL are installed and available through the publication point. Then install the signed subordinate CA certificate:

certutil -installcert C:\CARequest\IssuingCA01.cer
Start-Service certsvc
Get-Service certsvc

If you exported a PKCS #7 file, use its actual filename. Do not continue if Certificate Services cannot validate the Root CA chain or current Root CA CRL.

13. Configure Issuing CA AIA and CDP

Before enabling templates or issuing certificates, configure the issuing CA’s Extensions tab. Use stable HTTP URLs for broad compatibility and LDAP locations where appropriate for domain clients.

Configure HTTP and, where required, LDAP CDP locations.
Configure HTTP and, where required, LDAP AIA locations.
Choose base and delta CRL periods that your operations team can reliably maintain.
Publish the issuing CA certificate and CRLs to every advertised location.
Restart Certificate Services.
Publish a fresh CRL.

Do not advertise a URL unless you operate and monitor it. Avoid embedding server names you expect to retire during the CA lifetime.

14. Enable Only Approved Certificate Templates

Review template security before publishing anything. Pay particular attention to who can enroll, who can modify the template, whether requesters can supply subject information, allowed EKUs, key exportability, validity, renewal, and issuance requirements.

Duplicate an appropriate built-in template instead of modifying the original.
Give the template a clear name and purpose.
Remove broad enrollment permissions.
Grant Enroll and Autoenroll only to the intended security groups.
Document the owner and renewal expectations.
On the issuing CA, select Certificate Templates → New → Certificate Template to Issue.
Enable only the reviewed templates.

15. Do Not Install Every Web Enrollment Role by Default

A normal domain-connected autoenrollment deployment does not automatically require Certification Authority Web Enrollment, Certificate Enrollment Web Service, or Certificate Enrollment Policy Web Service.

Certificate Enrollment Web Service and Policy Web Service: Useful for HTTPS-based enrollment across forest boundaries or for clients outside the internal network.
CA Web Enrollment: Provides browser-based interactive enrollment for specific legacy or manual use cases.
NDES/SCEP: Intended for devices and management systems that use SCEP.

Each additional role introduces IIS, authentication, delegation, firewall, certificate, and security-design requirements. Install only the components justified by an approved use case, and consider hosting enrollment web services separately from the issuing CA.

16. Validate the Hierarchy

Use pkiview.msc to review Enterprise PKI health.
Confirm Root and issuing CA certificates are trusted where expected.
Open every HTTP AIA and CDP URL from representative Windows and non-Windows networks.
Use certutil -url against an issued certificate to test retrieval.
Verify the issuing CA certificate chains to the intended Root CA.
Confirm all CRLs are current and have adequate overlap.
Enroll a low-risk test certificate using an approved template.
Verify revocation checking before deploying production workloads.

pkiview.msc
certutil -url C:\Temp\TestCertificate.cer
certutil -verify -urlfetch C:\Temp\TestCertificate.cer

17. Back Up and Operate the PKI

Back up each CA database, private key, certificate, registry configuration, CAPolicy.inf, and system state.
Protect backup passwords and media separately from the servers.
Test restoration in an isolated environment.
Monitor CRL expiration and HTTP availability.
Review issued certificates, failed requests, template changes, and privileged activity.
Patch the issuing CA through a controlled maintenance process.
Activate the Root CA only for documented signing, CRL, renewal, backup, or recovery tasks.
Record Root CA, issuing CA, and key-renewal dates well in advance.

Common Problems

Issuing CA service will not start: Verify the subordinate CA certificate is installed, the private key matches, the Root CA is trusted, and the Root CA CRL is current and reachable.
PKIView reports an expired or unavailable CRL: Publish a new CRL and copy it to every advertised location. Correct the operational process before issuing more certificates.
Clients cannot build the chain: Verify Root and issuing CA certificates are distributed and that AIA URLs return the correct files.
Revocation checking fails: Test every CDP URL, DNS resolution, firewall path, filename, MIME type, and CRL validity period.
New AIA/CDP URLs do not fix older certificates: Previously issued certificates retain their original extensions and may need to be reissued.
Unexpected enrollment access: Stop publishing the affected template and review template ACLs, CA permissions, manager approval, authorized signatures, and subject-name settings.

Conclusion

A two-tier PKI is not secure simply because it has two servers. Its reliability depends on protecting the Root CA key, designing publication locations before issuance, limiting templates and roles, keeping CRLs available, maintaining tested backups, and assigning clear operational ownership.

If you need help reviewing an existing PKI, planning a replacement, or building certificate lifecycle procedures, contact Anthony Ventura.