How to use this checklist
Run this once a month, on a fixed date, with the estate inventory open in front of you. The monthly cadence is not arbitrary: certificate lifetimes are shrinking, and a quarterly review now leaves a window longer than the runway some certificates have. The review is not about renewing anything. It is about establishing, before the month starts, that every certificate due in the next window has a path to renewal and somebody at the end of that path.
The items divide into three questions. What is due and who owns it. Will the mechanism work when it runs. Will the result reach the processes that serve traffic. Teams that only answer the first question produce accurate lists of certificates that then expire anyway, because a renewal that issues successfully and is never loaded looks identical to a renewal that never happened.
Where the numbers come from
Expiry comes from the certificates themselves, asked in seconds and answered by exit status, both from the files on disk and from a connection to the endpoint. The two readings are taken separately on purpose: a difference between them is a service holding a stale certificate in memory, which is a finding that no file-based inventory can produce. Rate limits and validity caps come from the issuer documentation, checked at review time rather than remembered, because both have moved recently and will move again.
Six items are attested. Ownership, change-freeze collisions, whether a manual purchase has been started, whether somebody has watched a reload hook actually work this cycle, whether the rehearsal actually followed the written procedure, and whether an unexplained certificate has been escalated are all statements people make. Write down who made each one, and make the ownership attestation specific enough that the alert has somewhere to go at two in the morning.
Access this needs
Read access to the certificate inventory and to the issuance records behind it. Network access to the endpoints from a path a customer would use, for the wire readings. Read access to the certificate files on the serving hosts and to the internal authority intermediates. Read access to the renewal client configuration and its logs, and the ability to run a dry run without issuing. Read access to the monitoring system, specifically to the last-success timestamps rather than only to the alert history.
What the review produces
A dated record listing every certificate due in the coming window with its owner, its mechanism, its measured days remaining, and a yes or no against each of the three questions above. Attach the dry-run output, the challenge-path probe result, the intermediate expiry test, and the last-success timestamps for the monitors. Anything unowned goes to the platform owner the same day, and anything unexplained goes to the security owner as well.
Sign-off
- Reviewer: ________________ Date: ___________
- Platform owner: ___________ Date: ___________
- Service owner: ____________ Date: ___________
Every critical item must pass. A failing critical item blocks the month rather than the individual certificate: an inventory that is not generated, a probe that is not alive, or a mechanism nobody can name means the rest of the readings cannot be trusted either. Record the date, the reviewer, and the disposition of every item that did not pass, with the deadline by which each will be re-checked.