How to Build and Sequester an Offline Root CA with Active Directory Certificate Services (Part 1 of 2)

This is Part 1 of a two-part guide. Part 1 builds the offline root of a two-tier Microsoft AD CS hierarchy and shows how to put it away properly. Part 2 uses the resulting certificates with on-premises Exchange Server, and explains what changes when you also run Exchange Online in a hybrid configuration.

Why an Offline Root CA

The practice goes by several names: an offline root CA, a standalone root CA, or an air-gapped root. They all mean the same design, a two-tier PKI hierarchy:

• Offline root CA. It sits at the top of the trust chain. Its only jobs are to sign the certificates of your issuing CAs and to publish a certificate revocation list (CRL) for them. After that, it is shut down and kept away from the network.
• Online issuing CA (subordinate). This is the domain-joined server that actually hands out certificates to servers, users, and devices every day.

The payoff is blast-radius control. If ransomware or an attacker destroys or compromises the issuing CA, the root is untouched. You build a new issuing CA, have the root sign it, revoke the old one, and re-enroll. If the root were online and domain-joined and it was destroyed, every certificate chain in the organization would have to be rebuilt and every client re-trusted.

Decide These Before You Install

Several choices cannot be changed after the CA exists, so settle them first.

Decision	Recommendation	Why
CA common name	Something neutral with a generation suffix, such as Contoso Root CA G1	The name is permanent. A suffix makes a future key rollover unambiguous
Key algorithm and size	RSA 4096	Long-lived trust anchor, so use the larger key. 2048 is the minimum
Hash	SHA-256	SHA-1 is deprecated and should not be used
Root certificate lifetime	15 to 20 years	The root outlives everything under it. Everything below must expire sooner
Issuing CA certificate lifetime	5 years	The root signs it for this long, so set the root's maximum issued lifetime to 5 years
Root CRL period	6 months, with a 2-week overlap	This sets how often the root must be powered on, and how long you have to do it
Delta CRLs on the root	Disabled	The root rarely revokes anything, so deltas add work for no benefit
Server role	Standalone, workgroup, never domain-joined	An offline CA cannot reach Active Directory, and a domain-joined root defeats the purpose
Where CRL and certificate files are published	An HTTP location such as http://pki.contoso.com/pki/	HTTP is reachable by every client. LDAP-only publication fails for non-domain devices

Step 1: Build the VM on an Isolated Host

1. Create a Windows Server 2022 or 2025 virtual machine. Name the computer something you will recognize on a label, such as ROOTCA01.
2. Leave it in a workgroup. Do not join it to the domain.
3. Remove the virtual network adapter after the OS is installed. Files move in and out on removable media only.
4. Create one local administrator account with a strong, unique password. Record it for the sealed envelope described later.
5. Do not install agents, antivirus consoles, backup agents, or monitoring tools that phone home. The machine should have no reason to talk to anything.
6. Avoid host-bound disk encryption such as a virtual TPM tied to one hypervisor, because it can stop the VM from starting anywhere else. Encrypt the removable media instead.

Run the build on a standalone host or laptop that is not part of your production hypervisor cluster, if you can. If you must use the production cluster, plan to export and delete the VM from it afterwards (see Step 7).

Step 2: Write CAPolicy.inf

Create C:\Windows\CAPolicy.inf before installing the role. It controls the parameters used when the CA renews its own certificate.

Step 3: Install the Standalone Root CA

The -CACommonName is permanent. Check the spelling before pressing Enter.

Step 4: Configure Lifetimes and Publication Points

A certificate carries the locations where clients can download the CA certificate (AIA) and the revocation list (CDP). Those URLs are baked into every certificate issued, so they must be correct, and they must point somewhere that will exist for years. Replace pki.contoso.com with your real PKI web host.

Two details trip people up. First, \n in these strings is a literal separator that certutil understands, so do not replace it with a line break. Second, if you leave the default LDAP entries in place on an offline root, clients will try to fetch the CRL from a directory the root can never publish to.

Step 5: Export the Root Certificate and CRL

The files you need are in C:\Windows\system32\CertSrv\CertEnroll:

• The root certificate (.crt), named like ROOTCA01_Contoso Root CA G1.crt
• The root CRL (.crl), named like Contoso Root CA G1.crl

Copy both to a clean USB drive. Rename them to something web-friendly, such as ContosoRootCAG1.crt and ContosoRootCAG1.crl, and make sure the file names match the URLs you configured in Step 4. Then, from a domain-joined server using an account that is a member of Enterprise Admins:

Copy the .crt and .crl files to the /pki folder on your PKI web host (for example http://pki.contoso.com/pki/). Distribute the root certificate to the Trusted Root Certification Authorities store on domain machines with Group Policy. Devices outside the domain need it pushed by MDM or installed by hand (Part 2 covers this).

Record the root certificate's thumbprint and write it down in the CA's runbook. You will compare it later on any device you configure by hand.

Step 6: Sign the Issuing CA

The issuing CA is an enterprise subordinate CA on a domain-joined server. Build it first up to the point where it produces a certificate request.

1. On the issuing CA server, install the AD CS role and configure it as an Enterprise Subordinate CA, choosing "Save a certificate request to a file". It writes Contoso-Issuing-CA-01.req. Use RSA 2048 or 4096 and SHA-256.
2. Carry the request file to the root CA on the USB drive.
3. On the root, submit and issue it:

4. Carry the signed .crt back, along with the root certificate and root CRL. On the issuing CA, trust the root first, then install the signed certificate:

If the install complains that revocation cannot be checked, the root CRL has not been published at the URL in the certificate yet. Publish it (Step 5) and retry.

Also give the issuing CA its own publication settings: HTTP AIA and CDP pointing at the same PKI web host, a CRL that refreshes more often (for example weekly, with daily deltas), and a backup of its own (certutil -backup). The issuing CA is online, so it will be the one attackers go after.

Step 7: Back Up the CA Before You Put It Away

On the root CA, take a backup that includes the private key and the CA database, and protect it with a strong password:

Store the backup password and the VM's local administrator password separately, and never together with the media. The backup lets you rebuild the root on a new machine if the VM is ever damaged.

Step 8: Sequester It Properly

1. Shut the VM down cleanly and confirm the virtual NIC is gone.
2. Export the VM (its disks and configuration) to removable media that is encrypted, such as a hardware-encrypted drive or one protected with BitLocker To Go.
3. Make at least two copies, on separate media. Keep one in a fire-resistant safe on site and one at a different physical location.
4. Put the CA backup (Step 7) on the same media or alongside it.
5. Delete the VM from the production hypervisor and its datastore. This is the step that makes the root offline in practice. Ransomware that gains hypervisor or storage access encrypts VM disks whether they are powered on or not.
6. Seal the passwords in separate envelopes, stored separately from each other and from the media, with at least two people needed to retrieve them.
7. Write a one-page runbook: where the media and envelopes are, who can access them, the root thumbprint, and the date the CRL expires.

For higher assurance, keep the root private key in a hardware security module or a smart card rather than in a software key store. It adds cost and procedure, but it means the key cannot be copied by copying a disk image.

Step 9: The Maintenance Calendar

An offline root is not "set and forget." Its CRL expires, and when it does, certificate validation fails for everything in the hierarchy. That is the most common way a working PKI turns into an outage.

• Every CRL cycle (about every 5 months for a 6-month CRL with a 2-week overlap): retrieve the media, attach the VM to an isolated host, and boot it. Check the clock first, because an offline VM drifts and a CRL signed with a wrong date is wrong for everyone. Run certutil -crl, copy the new CRL to a clean USB drive, publish it to the web host, shut down, and return everything to storage. Log who did it and when.
• Monitor the published CRL. Alert at least 30 days before its Next Update. A simple check is certutil -dump ContosoRootCAG1.crl | Select-String "NextUpdate", or a web check on the CRL URL that reads the date.
• Patch at wake-up. Download updates on a clean machine and apply them while the VM is booted in isolation, then shut down. Do not connect it to the network to patch.
• Test the restore once a year. Prove that the media boots on a fresh host and the CA starts. A backup you have never restored is a hope, not a backup.
• Plan the root's end of life. If the root lasts 20 years, add a calendar entry to start the successor (G2) well before the end of the term.

If the Issuing CA Is Hit by Ransomware

This is the situation the whole design exists for.

1. Isolate and rebuild. Do not trust the old issuing CA server.
2. Wake the root (Step 9), revoke the old issuing CA certificate, and publish a fresh root CRL so clients stop trusting anything the compromised CA issued.
3. Build a new issuing CA with a new key, sign it with the root, and publish its certificate and CRL.
4. Re-enroll the certificates that matter: Exchange servers, domain controllers, RDP, wireless, and so on. If you have a current certutil -backup of the issuing CA, you can restore its database to keep issuance history.

The root, and therefore the trust configuration on every client, does not change.

Common Mistakes

Mistake	What happens
Powering the VM off but leaving it on the production datastore	Ransomware that reaches storage encrypts the VM disks. The root is lost with everything else
Joining the root CA to the domain	The key is exposed to every domain admin and attacker who gets domain admin
Letting the root CRL expire	Certificate validation fails across the hierarchy. Outages start on the day the CRL ends
Leaving default LDAP publication points on an offline root	Clients try to retrieve the CRL from a location nobody updates
Only one copy of the media, or passwords stored with it	A single fire, theft, or failed drive ends the PKI
Choosing a short root lifetime	The root expires while the hierarchy is still in use, forcing an emergency rebuild
Never testing the restore	You find out the backup is bad on the worst day

What Comes Next

You now have a root that signs the issuing CA and is otherwise out of reach. Part 2 puts the issuing CA to work: certificates for on-premises Exchange Server, how to distribute trust, and the important limits when you also run Exchange Online in a hybrid configuration.