How to use this checklist
An annual review is the right cadence for a certificate authority because almost nothing about one changes on a weekly basis, and the things that do change are slow, silent and expensive: an authority certificate ages, a custodian leaves, a trust anchor spreads into a new part of the estate, an issuance profile is loosened for one team and never tightened again.
Run it against every authority you operate, including the ones that were stood up for a single project and never formally adopted. Those are frequently the ones with the most permissive profile and the least custody, and they are certainly the ones whose anchor nobody has thought about removing. An authority nobody is willing to claim is still an authority the fleet trusts.
Where the numbers come from
Every claim about what an authority asserts is read from an issued certificate, never from the configuration intended to produce it. Those two disagree more often than teams expect, because a profile is edited and the running service is not restarted, or the requester supplied extensions and something in the path copied them through. The revocation list is fetched from the address the certificates advertise, resolved from a client position rather than from the authority host.
The custody items are attested. Whether the root key is where the record says, whether the quorum holders are still employed and whether a ceremony was witnessed are answered by people and by signed records, not by commands. So is the question of what actually enforces revocation, which is the single item most often answered optimistically and wrongly.
Access this needs
Read access to the authority certificates and to a sample of issued certificates, the ability to fetch the published revocation list from a client network position, read access to the issuance records for the period, and the custody records and ceremony logs. The review requires no access to any private key, and any item that seems to require one should be answered from the ceremony record instead.
What the review produces
A register naming each authority, its key custody and generation method, the constraints on its certificate, the profile it enforces, the current state of its published revocation list, the result of the restoration test, the inventory of places its anchor is installed, and the date its own certificate expires. The expiry dates and the anchor inventory are the two columns that a trust transition will be planned from, so they are worth being pedantic about.
Sign-off
- Reviewer: ________________ Date: ___________
- Platform owner: ___________ Date: ___________
- Security owner: ___________ Date: ___________
Every critical item must pass. A failing critical item is a standing risk to every certificate the authority has ever issued and must be resolved or formally accepted by a named owner before the review closes; it is not a note for later. Record the date, the reviewer, and the disposition of every item that did not pass.