How to use this checklist
This is a per-request review, run whenever somebody asks for a certificate that is not produced entirely by automation with a fixed profile. It has two halves and they happen at different moments. The first half runs before signing and answers whether this request should be granted at all. The second half runs after signing and before deployment, and answers whether the object that came back is the one that was approved.
Treat the two halves as separate sittings with separate timestamps. Automated issuance under a reviewed profile does not need this checklist every time; it needs it once, when the profile is established, and then again whenever the profile changes. What needs it every time is the manual request: the new service, the odd name, the wildcard, the certificate somebody wants in a hurry because something is already broken.
Where the numbers come from
Everything structural is read out of two files. The request supplies the names as asked and the public key as offered. The issued certificate supplies the names as granted, the extensions the authority chose, the validity window it actually applied, and the serial it assigned. The point of the review is the comparison between those two readings, so both are captured and both go into the record.
Four items cannot be measured. Whether the requester holds authority over the names, where the key was generated, whether a wildcard is justified, and whether the key has passed through a chat window are statements a person makes. They are also the four items that decide whether a technically flawless certificate is the right certificate to exist. Name the person who attests to each, and treat an anonymous attestation as a fail.
Access this needs
Read access to the signing request and, after issuance, to the certificate and the chain that will be deployed. Read access to the trust anchor and intermediates the clients use, so verification can be run against the intended path rather than against the local system store. Access to the domain or zone ownership record for the names involved. Nothing here requires access to the private key, and the review should be conducted so that it is never offered.
What the review produces
A dated record with two entries: the approval, naming the requester, the authorised names and the approver, and the verification, naming the serial and fingerprint of the issued certificate together with the results of the chain, hostname and purpose checks. Attach the readings themselves rather than describing them. The record ends with an inventory entry containing the expiry date and the renewal owner, and that entry is what turns a one-off approval into something the estate can maintain.
Sign-off
- Reviewer: ________________ Date: ___________
- Requesting owner: _________ Date: ___________
- Security owner: ___________ Date: ___________
Every critical item must pass. A failing critical item blocks issuance in the first half of the review and blocks deployment in the second; a certificate already signed that fails a post-issuance check is withdrawn and reissued rather than deployed with a note. Record the date, the reviewer, and the disposition of every item that did not pass.