By the end of this article the hierarchy is trusted by everything that needs to trust it, both authorities are backed up in a way that would actually survive losing them, and there is a one-page calendar that somebody who has never met this PKI can act on.
The last of those is the deliverable that matters most and the one most builds omit entirely.
Prerequisites. The hierarchy from [P 2.1] through [P 5.1], validating clean. Rights to create and link a group policy object. A network location for backups that is independent of both the certificate authority and its hypervisor. Access to the offline root, since part of this is rehearsing the procedure that keeps it relevant.
Step 1. Distribute trust to domain members
Publishing the root to the forest in [P 4.1] already causes domain members to trust it. This step is belt and braces, and it is worth doing because it makes the trust explicit and auditable rather than inherited from a directory container nobody looks at.
Create a group policy object named for its purpose, linked at the domain root. Under Computer Configuration, Policies, Windows Settings, Security Settings, Public Key Policies, import the root certificate into Trusted Root Certification Authorities and the issuing authority’s certificate into Intermediate Certification Authorities.
# on a client, after the policy has applied
gpupdate /force
Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like "*CatSnackJack*"
Get-ChildItem Cert:\LocalMachine\CA | Where-Object Subject -like "*CatSnackJack*"Expected result: the root in the machine’s trusted root store and the issuing authority in the intermediate store. Failure mode worth knowing: there is a documented condition where root certificates delivered by policy land in the policy store and are intermittently treated as untrusted. If you meet it, the workaround is to place the certificate in the registry root store instead. It is rare, and it looks like a client problem rather than a distribution problem, which is why it is worth having heard of.
Domain controllers are worth checking separately rather than assuming, because they are the machines whose certificates everything else depends on.
Step 2. Write down how everything else gets the root
This is documentation rather than configuration, and it is the step most likely to be skipped and most likely to be missed later.
Publish the root certificate somewhere permanently retrievable. You already have exactly the right place: the distribution web servers from [P 3.1] serve it over HTTP at a stable URL that will outlive several generations of infrastructure. That URL is what you give to anyone who needs to establish trust manually.
Then enumerate the populations that will not receive it by policy, and record the mechanism for each: Linux and Unix hosts and their trust bundle, macOS and its keychain, mobile devices and the management platform’s trusted certificate profile, network appliances and their individual certificate stores, container base images and the build pipeline that produces them, any monitoring system that validates internal endpoints, and any partner or contractor equipment. For each, name the mechanism and the owner. You are not solving these here. You are making sure that when a new class of device arrives, somebody knows the question exists.
Add one rule to the same document: trust arrives before certificates that depend on it. A service certificate issued to a population that does not yet trust the issuer is an outage you scheduled yourself.
Step 3. Back up the issuing authority, all three layers
$pw = Read-Host -Prompt "Backup password" -AsSecureString
Backup-CARoleService -Path "C:\CA-Backup" -Password $pw
reg export "HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration" `
"C:\CA-Backup\CertSvc-Configuration.reg" /y
Get-ChildItem C:\CA-Backup -Recurse | Select-Object FullName, LengthExpected result: a .p12 file holding the certificate and private key, a Database folder containing the certificate database and its logs, and the registry export. Three artefacts, and the third is the one that is not in the certificate services backup.
Prompt for the password interactively as above, or verify afterwards that the file is actually protected. The defect is that if the expression producing the password fails, the backup proceeds unprotected and does not report an error, which produces a file you will store as though it were encrypted. Microsoft does not document this behaviour, but the mechanism is visible in the cmdlet’s own signature: -Password is an optional parameter, so a call that arrives with nothing in it is a valid call rather than a failed one.
Copy-Item C:\CA-Backup\* "\\backup-target\pki$\SUBCA\$(Get-Date -Format yyyy-MM-dd)\" -Recurse
Get-ChildItem "\\backup-target\pki$\SUBCA\" | Sort-Object LastWriteTime -Descending | Select-Object -First 3Write locally first because it is fast and verifiable, then copy somewhere independent of both this server and its hypervisor. A hypervisor snapshot is a useful supplement here and is not a substitute, because it shares its fate with the storage holding the machine.
Schedule this monthly during a pilot and weekly in production, and put a reminder in the same calendar as everything else to confirm the offsite copy is current. A backup nobody has looked at since it was configured is a belief rather than a control.
Step 4. Back up the root, which happens only twice a year at most
The root is backed up when it is built and after each annual revocation list renewal, because those are the only occasions it is running and the only occasions its state changes. The same three layers apply, with the transfer going out through the hypervisor shared folder since the machine has no network.
# on ROOTCA
$pw = Read-Host -Prompt "Backup password" -AsSecureString
Backup-CARoleService -Path "D:\RootCA\Backup" -Password $pw
reg export "HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration" `
"D:\RootCA\Backup\CertSvc-Configuration.reg" /yFor this machine the virtual machine export is the primary protection rather than a supplement, because the root is a sealed artefact rather than a running service and restoring the whole machine is the fastest path back. Export it from the hypervisor, store it on encrypted removable media, and keep it somewhere physically separate from the running estate.
Store the local administrator password for this machine somewhere that does not depend on this hierarchy. If it lives in a system that authenticates with a certificate issued by this PKI, you have built a circular dependency that will be discovered on the one day it must not exist.
Step 5. The annual root revocation procedure, rehearsed now
Do not write this procedure and file it. Perform it now, while the build is fresh and nothing depends on it succeeding, so that the first time it runs for real is the second time it has been run.
Five stages, in order, without leaving the root powered on between them.
# Stage 1: power on ROOTCA. No network adapter. Log in locally.
# Stage 2: correct the clock before anything else.
Get-Date
Set-Date "..." # only if wrong
# Stage 3: publish a new revocation list
certutil -crl
certutil -dump D:\RootCA\CDP\*.crl # read ThisUpdate and NextUpdate
# Stage 4: copy the new list out through the shared folder, then shut down
Copy-Item D:\RootCA\CDP\*.crl E:\Transfer\# Stage 5: from an admin workstation, place it on both web servers and in the directory
Copy-Item "E:\Transfer\*.crl" "\\PKI-WEB01\PKI\"
Copy-Item "E:\Transfer\*.crl" "\\PKI-WEB02\PKI\"
certutil -f -dspublish "E:\Transfer\CatSnackJack Root CA.crl"
# then confirm it is actually being served, from outside the network
certutil -URL "http://pki.catsnackjack.com/pki/CatSnackJack%20Root%20CA.crl"The clock stage is not optional and is the one people skip. A machine that has been powered off for a year has no idea what the date is, and every date on the list it produces comes from that clock. A list issued with a start date in the future is rejected by every client.
The verification stage is the one that actually proves the procedure worked. Publishing a new list on the root and leaving it there achieves nothing, because no client can reach that machine. The work is only done when the file is being served from the distribution URL, and that is what the final command checks.
Step 6. The monthly check, and the revocation procedure
pkiview.msc
# both nodes independently, not through the shared name
Invoke-WebRequest "http://PKI-WEB01/pki/" -UseBasicParsing | Select StatusCode
Invoke-WebRequest "http://PKI-WEB02/pki/" -UseBasicParsing | Select StatusCode
(Get-FileHash "\\PKI-WEB01\PKI\CatSnackJack Issuing CA.crl").Hash
(Get-FileHash "\\PKI-WEB02\PKI\CatSnackJack Issuing CA.crl").HashEvery location in the enterprise PKI view should read OK. The two hashes should match. That hash comparison is the specific check this architecture needs, because a node serving a stale list returns a perfectly healthy response and looks correct through the shared name roughly half the time.
Revoking a certificate is the one reactive task, and it is worth rehearsing because it has a second half people forget.
certutil -revoke <serial number> 1 # 1 = key compromise
certutil -crl # republish immediately, do not wait for the weekly cycle
Get-ChildItem "\\PKI-WEB01\PKI\", "\\PKI-WEB02\PKI\"Revocation is not effective when you revoke. It is effective when relying parties have fetched a list that says so, which means republishing at once and accepting that clients holding a cached list will not know until it expires. If the revocation is urgent, that cache window is your actual exposure, and it is a good argument for a revocation list lifetime measured in a week rather than a month on the issuing authority.
The end-to-end test
The test for this article is a restore, because a backup that has never been restored is an assumption.
Build a scratch virtual machine, domain joined, install the certificate services role without configuring it, then restore the issuing authority’s backup and its registry export onto it. Start the service. It should come up as the same authority, with the same certificate, the same database, and the same distribution point configuration, and certutil -getreg CA\CRLPublicationURLs should show the two web server paths rather than installation defaults. Publish a revocation list from it and confirm it writes to both shares.
Then destroy the scratch machine. What you have proved is that the three artefacts are sufficient, that the registry export was the piece that made the difference, and that you can execute the procedure. Do this once at build time and once a year thereafter, and the difference between having backups and being able to recover stops being a matter of faith.
A worked example: the calendar, with real dates
Take a hierarchy built on the first of August 2026, with a root revocation list running fifty-two weeks with a six week overlap, and an issuing authority holding a five-year certificate.
| Obligation | Do it | Hard date | If missed |
|---|---|---|---|
| Root revocation list renewal | Mid July 2027, then annually | Around 10 September 2027 | All certificate validation in the domain fails simultaneously. |
| Issuing authority renewal | August 2028, at half life | 1 August 2031 | Issued certificates silently shorten from early 2031, then issuance stops. |
| Issuing authority backup | Weekly | none | Recovery loses every certificate issued since the last good backup. |
| Root backup | After every power-on | none | Loss of the root means rebuilding the hierarchy and redistributing trust. |
| PKI health check | Monthly | none | Problems surface as user-visible failures instead of as findings. |
| Restore rehearsal | Annually, with the root renewal | none | You discover the gap in the backup during the incident. |
| Web server certificate renewals | As they approach expiry | per certificate | Browser and client warnings on internal services. |
Two properties of that table matter more than its contents. Every row has a consequence written in plain language, so a person who has never seen this hierarchy can tell which entries are urgent. And the two rows with hard dates are the only two that can cause an outage, which is the single most useful thing to hand over. The procedure for the second of them is [P 6.2] Build Sheet: Renewing the Issuing CA, and the Root. Assign each row to a role rather than a person, and put the hard dates in the description rather than relying on the reminder date to convey urgency.
Completion checklist
A policy object distributes the root and the issuing authority certificates, verified on a client and on a domain controller. The non-domain trust populations are enumerated in writing with a mechanism and an owner for each, and the root certificate has a permanent retrieval URL. The issuing authority is backed up in three layers, with the registry export present, stored somewhere independent of the server and its hypervisor, and the backup file is genuinely password protected. The root is backed up and exported to removable media, and its local administrator password is stored outside anything this PKI authenticates. The annual revocation procedure has been performed once as a rehearsal, including the clock correction and the verification that the file is served from the distribution URL. Both web servers have been compared by hash. A restore has been proved on a scratch machine and the restored authority carried its distribution point configuration. The calendar exists, each row names a role and a consequence, and the two rows with hard dates are marked as the ones that cause outages.
The hierarchy is now built, issuing, and maintainable. One article remains, and it is the one that answers the question every organisation is now asking: what happens to all of this when the certificates your endpoints need start coming from the cloud instead.
On-Prem PKI
‹ Previous: [P 6] Operating a PKI: Trust, Backup, and the Calendar
Next: [P 6.2] Build Sheet: Renewing the Issuing CA, and the Root ›
