Chapter 8 of 8

Operations, backup and retirement

Backups, monitoring, decommissioning, and a lab you can build in an afternoon.

About 12 minutes of reading

By the end of this chapter you can

  • Describe what must be backed up for a CA
  • List the operational signals worth monitoring
  • Plan a CA retirement without breaking clients
  • Build a small ADCS lab to practise on

01Backup that actually restores

A CA backup has three parts: the CA database (what was issued), the CA certificate, and the CA private key. Losing the database loses history; losing the key means you cannot issue or publish revocation data under the same identity.

  • Use the CA backup facility, not a file copy of a running database
  • Store key backups under tier-0 controls, with export evidence and named custodians
  • Rehearse a restore in a lab, including publishing a CRL afterwards
  • Keep backups for the lifetime of the certificates issued, not for a standard retention period

02What to monitor

SignalWhy
CRL age and publication successStale revocation data silently weakens validation
AIA and CDP reachability from client networksBroken chains for remote and cloud clients
Issuance volume by template and requesterDetects template abuse and automation errors
Template and CA configuration changesShould be rare; every change deserves review
Certificates issued per subject, unusual subjectsSigns of impersonation attempts
CA service health and disk spaceThe database growth surprises teams during an incident

03Retirement

  1. 1

    Stop issuing

    Unpublish templates and remove enrolment permissions.

  2. 2

    Keep revocation alive

    Continue publishing CRLs and OCSP data until the last issued certificate expires.

  3. 3

    Migrate clients

    Reissue certificates from the replacement CA and confirm every client validates.

  4. 4

    Archive records

    Keep the database, ceremony documents and CRLs for audit.

  5. 5

    Decommission hardware

    Destroy keys under documented control, and keep the evidence.

The step teams skip is the second one. Switching off a CA while certificates it issued are still in use causes validation failures for anyone who checks revocation.

04A lab you can build this week

  • Two Windows Server virtual machines: one offline root, one enterprise issuing CA
  • A domain controller and a client workstation
  • Publish a duplicate of the User template, then deliberately enable supply-in-request and observe what changes
  • Use PKI Trust Auditor to scan the lab before and after the change
  • Fix the template, re-scan, and compare the findings
  • Practise revoking a certificate and confirming the CRL updates
Why keep a CA's CRLs after the CA is retired?

Clients still validating certificates issued by that CA need current revocation data until those certificates expire.

What must accompany a CA key backup?

Documented custody, dual control, export evidence, and a rehearsed restore procedure.

Why scan before and after a lab change?

It teaches you what each finding looks like and proves the control actually closed it.

What to remember

  • Back up the database, certificate and key, and rehearse the restore
  • Monitor revocation availability and configuration drift, not just service uptime
  • Retirement means keeping revocation data alive until the last certificate expires
  • A small lab makes ESC conditions and their fixes concrete