How to use this checklist
Run this before the first service is allowed to depend on a certificate from an internal hierarchy, and again after any change to the CA key material, the issuance profiles, or the set of clients that trust the root. A private CA is easy to stand up in an afternoon and expensive to correct afterwards, because correcting it means touching the trust store on every machine that already trusts the old anchor.
Take the items in the order they are written. The early items settle what the hierarchy is; the middle items settle what it may issue and what happens when something must be withdrawn; the late items settle what happens when the CA host is destroyed. Reviewers who start at the revocation items tend to produce a detailed answer about CRL freshness for a hierarchy whose root key is sitting on the same host as the issuing service.
Where the numbers come from
Validity windows, path lengths, serials and extension flags are read out of the issued certificates themselves, never out of the configuration file or template that produced them. Those two disagree more often than reviewers expect, because a template change applies only to certificates issued after it, and the estate is full of certificates issued before it. The CRL dates come from the published file fetched over the network, not from the copy on the CA host.
Three items are attestations. Custody of the root key, the identity of the component that enforces revocation, and the existence of an approval step for privileged profiles are all claims a person makes. No command can distinguish a root key in a safe from a root key in a drawer, and no command can prove that the approval step is honoured when a release is late. Name the person who attests to each.
Access this needs
Read access to the CA certificates, the issued-certificate store and the CA configuration; read access to the CA host filesystem sufficient to check the permissions on the private key, though not to read the key itself. Network access to the CRL distribution point from a client network rather than from the CA. Read access to the issuance log and to the backup destination. The restore rehearsal needs a disposable host and somebody with the authority to create one.
What the review produces
A dated record naming the reviewer, the two CA certificates by fingerprint, and the disposition of every item. Attach the extension readings taken from a recently issued leaf, the intermediate expiry test, the CRL header fetched over the network, and the result of the restore rehearsal including how long it took. Anything concerning root key custody or the trust anchor distribution list goes to the security owner as well as the platform owner.
Sign-off
- Reviewer: ________________ Date: ___________
- Platform owner: ___________ Date: ___________
- Security owner: ___________ Date: ___________
Every critical item must pass. A failing critical item blocks the hierarchy from being trusted by production clients; it is not something to fix once the first service is already depending on it. Record the date, the reviewer, and the disposition of every item that did not pass, along with whoever accepted the residual risk and until when.