Notifications
Clear all
Topic starter
22/08/2026 12:01 pm
TL;DR: Certificate expiry keeps causing outages because renewal is only one step in the lifecycle, and Infisical’s analysis shows the real failure is usually deployment, reload, and monitoring, not issuance. As public TLS lifetimes shrink toward 200, 100, and 47 days, manual certificate handling stops being reliable unless lifecycle automation is end to end.
NHIMG editorial — based on content published by Infisical: certificate expiry keeps causing outages when renewal is not matched by deployment and verification
By the numbers:
- 72% of organisations had at least one certificate outage in the previous 12 months.
- Only 38% have automated certificate lifecycle management in place.
Questions worth separating out
Q: What breaks when certificate renewal does not trigger a service reload?
A: The service keeps serving the certificate it loaded into memory, even if a new file exists on disk.
Q: Why do short-lived certificates matter for machine identity governance?
A: Short-lived certificates matter because they are time-bound non-human credentials that define how systems prove identity to each other.
Q: What do teams get wrong about certificate automation?
A: They often treat it as a convenience upgrade instead of a resilience control.
Practitioner guidance
- Verify the served certificate, not just the renewed file Probe the live endpoint from outside the host and compare the certificate clients receive with the one written to disk after every renewal cycle.
- Attach a reload hook to every renewal path Make service reload part of the same workflow that renews the certificate, whether you use certbot hooks, a controller, or a deployment agent.
- Inventory certificate ownership and validation method Record which team owns each certificate, whether it uses HTTP-01, DNS-01, or another validation path, and which credential can complete that validation.
What's in the full article
Infisical's full article covers the operational detail this post intentionally leaves for the source:
- The ACME and cert-manager configuration patterns used to automate issuance across Linux, Kubernetes, and private CA environments.
- The practical differences between HTTP-01, DNS-01, and TLS-ALPN-01 validation when infrastructure constraints change.
- The exact renewal hook patterns that reload nginx, HAProxy, or Apache after certificate replacement.
- The end-to-end workflow for centralising certificate profiles, inventory, and expiry alerting across a fleet.
👉 Read Infisical's analysis of certificate automation and expiry outages →
Certificate expiry and reload failures: are your controls keeping up?
Explore further
22/08/2026 12:02 pm
Certificate expiry is not a renewal problem, it is a lifecycle governance problem. Renewal can succeed while deployment, reload, and external verification fail, which means the identity control plane and the runtime service plane are no longer aligned. That gap is exactly why mature teams still suffer outages, and it is the point where ownership must extend beyond the CA interaction.
A few things that frame the scale:
- Only 38% have automated certificate lifecycle management in place, according to The Critical Gaps in Machine Identity Management report.
- 57% of organisations lack a complete inventory of their machine identities, which means many certificate estates remain partially invisible.
A question worth separating out:
Q: How should organisations decide when to centralise certificate operations?
A: Centralise when certificate ownership is fragmented, validation credentials are spread across many hosts, or no one can confidently inventory what exists and when it expires. At that point, distributed manual handling is already the risk. A central lifecycle control plane gives you a single place to enforce policy and detect failure.
👉 Read our full editorial: Certificate expiry is becoming a zero-touch identity problem
