Skip to content
Guides

A certificate rotation checklist that reads what was served

Renewal jobs fail quietly and rotations install the wrong chain. A short checklist for checking the certificate a server actually serves, from outside.

Updated

Most certificate outages aren't a surprise on the calendar. A renewal job quietly stops running weeks before anything breaks, or a rotation finishes and installs the wrong chain, and neither shows up if the only thing being checked is a file sitting on the server. The certificate that matters is the one a client actually receives, so the check has to connect to the endpoint the way a browser would and read what comes back.

Check what's being served, not what's on disk

That one change catches most of what an internal check misses: a service that never reloaded after a renewal wrote a new file, a deploy step that copied the old certificate back over the new one, or a load balancer sitting in front that's still holding the previous chain.

What to read off the served certificate

Check these on every public hostname; hourly is a reasonable interval.

  • Days remaining, the obvious one. Alert on a threshold rather than the expiry date itself: thirty days still gives a renewal job two more chances to run, seven days is worth paging someone.
  • Chain completeness, which matters more than it looks. An incomplete chain can work in one browser and fail in another, because browsers cache intermediates differently, so only a check with an empty cache tells the truth.
  • Key type and size. A rotation built from an old template can quietly install a shorter key than the one it replaced.
  • Protocol versions accepted, easy to miss internally. Internal clients negotiate the newest version and never notice an old one is still being offered alongside it.
  • The issuer, worth watching for its own sake. A change is sometimes planned, and sometimes the first sign that a wildcard was issued somewhere it shouldn't have been.

Alert on the change, not only the deadline

An expiry alert only tells you about a date you already knew was coming. The more useful alert fires when the served configuration changes grade, which is how a rotation that installed the wrong chain or an undersized key shows up. It fires on the first check after the rotation, which at the default hourly interval is within the hour. Dependably StatusCheck grades each endpoint from A+ to F on its TLS configuration and alerts Slack, PagerDuty, or a webhook when the grade changes or the days-remaining count crosses a threshold you've set.

Let the checker keep its own inventory

Certificates get added by different people on different hosts over time, and a spreadsheet of expiry dates is accurate for exactly as long as someone keeps updating it. The inventory that stays current is the one the checker builds on its own: add a hostname once, and the checker keeps that host's certificate, chain, and grade current from then on.

Where this comes up in the products

The pages that describe how Dependably Packages and Dependably StatusCheck handle the problem this guide walks through.