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 are not caused by forgetting the expiry date. They are caused by a renewal job that stopped working weeks earlier and told no one, or by a rotation that completed and installed something wrong. Both are invisible from inside the network, which is where every internal check runs.

Check from outside, not from the host

The certificate that matters is the one a client receives. A check that runs on the server reads the file on disk, which is not always the file the listener loaded. The check has to open its own TLS connection from outside, the way a browser does, and read what comes back.

That single change catches the common failures:

  • The renewal wrote a new file and the service never reloaded it.
  • The deploy step copied the old certificate over the new one.
  • A load balancer in front still holds the previous certificate.

The checklist

For each public hostname, once an hour is enough. Read these from the served certificate and its chain:

  1. Days remaining. Alert on a threshold, not on expiry. Thirty days gives a renewal job two more attempts; seven days is a page.
  2. Chain completeness. An incomplete chain works in one browser and fails in another, because browsers differ in the intermediates they cache. Only a client with an empty cache tells the truth.
  3. Key type and size. A rotation that reused an old template can install a key shorter than the one it replaced.
  4. Accepted protocol versions. A server that still accepts an old TLS version passes every internal check, because internal clients negotiate the newest version and never notice.
  5. Issuer. A change of issuer is sometimes planned and sometimes the sign that a wildcard was issued somewhere it should not have been.

Alert on change, not only on failure

An expiry alert fires once. A change alert fires when the certificate that is served differs from the one served an hour ago, which is the moment a rotation happened, and the only moment its result can be caught before a user does. Dependably StatusCheck does this by grading each endpoint from A+ to F on its TLS configuration and alerting when the grade changes or the days remaining cross a threshold, to Slack, PagerDuty, or a webhook.

Keep the inventory in the tool that checks it

Certificates are added by different teams on different hosts, and a spreadsheet of expiry dates is accurate on the day it was written. The inventory that stays accurate is the one the checker maintains: a hostname is added once, and every certificate it has ever served is on record from then on. The certificate expiry solution page has the full picture; the uptime and posture page covers the DNS and email-authentication checks that belong on the same schedule.