DevOps / SRE / Platform · 28.08.2026, 18:03 UTC
Certificate Renewal Is a Deployment Workflow, Not a Cron Job
| Schweregrad | info |
|---|---|
| Kategorie | DevOps / SRE / Platform |
| Quelle | DevOps.com ↗ |
| Veröffentlicht | 28.08.2026 UTC |
Sicherheitsmeldung mit Schweregrad noch nicht bewertet. Technische Details im Tab „Originaltext“; empfohlene Schritte in der Checkliste.
Certificate renewal is often treated as a scheduled task: run an ACME client, obtain a new certificate, and move on. In practice, that view is too narrow for production systems. A certificate is not useful because it exists on disk. It is useful because the right service is presenting it to users. Between issuance and that final state, several operational steps can fail. The more useful way to think about renewal is as a deployment workflow: renew, deploy, reload, verify, and recover when something goes wrong. Renewal Success Is Not Production Success The first failure mode is simple: a certificate authority successfully issues a new certificate, but the service continues using the old one. The renewal job is green, yet the incident clock is still running. This happens because issuance and production state are different things. The certificate may need to be copied to a specific host, mounted into a container, written to a secret, synchronized to a load balancer, or placed behind an ingress controller. A successful ACME transaction proves only that the certificate was issued. It does not prove that the service users reach is presenting it. Deployment is Only One Step Even after the new certificate reaches the correct system, the running service may not pick it up automatically. NGINX, Apache, HAProxy, IIS, application servers, and custom services can all require a reload or restart depending on how they are configured. That creates another common failure pattern: the files are correct, but the process still has the previous certificate loaded in memory. File-level checks …