TLS certificate expiry is one of the few outages with a known date in advance. It still catches organisations regularly, because the certificate that expires is rarely the main website — it is an internal API, a load balancer health check, a client certificate on an integration, or a mail server.
Automation solves the common case. ACME clients renew automatically, and for public-facing web services this is close to a solved problem. The gap is everything that automation does not cover: certificates on appliances, certificates issued by a private authority, certificates embedded in mobile applications, certificates a partner issued to you.
So the first task is an inventory, and the reliable way to build one is to scan rather than to ask. Tools that walk your address space and record what certificate each endpoint presents find the ones nobody remembered. Asking teams what certificates they have finds the ones they remember, which is a different and smaller set.
Monitor expiry as a metric, not a calendar reminder. An automated check that alerts at thirty, fourteen and seven days, based on the certificate actually being served rather than on a spreadsheet, catches both forgotten renewals and renewals that were performed but never deployed. The second case is more common than it should be.
Certificate lifetimes have been shortening industry-wide, which makes manual renewal progressively less viable. Any process that depends on a person remembering something annually will fail when the interval becomes quarterly.
Certificate pinning in mobile applications deserves particular caution. An app that pins a certificate stops working when that certificate rotates, and the fix requires an app store release that users must install. Pin to a longer-lived intermediate or root rather than a leaf certificate, or accept that you have coupled your certificate rotation to your release cycle.
