Mention "Kubernetes certificate management" to most engineers and they picture a solved problem: just install cert-manager. But in practice, certificate renewals turn into fires for reasons that are rarely technical. Writing the Terraform or Helm code to automate a renewal might take one or two days — getting permission to ship it to production can take one or two months.
Certificate-related incidents are still one of the most common categories of outage. According to a report from Gart Solutions, more than 70% of organizations have experienced at least one certificate-related outage in the past year. If you've ever chased down a mysterious production outage and found an expired TLS certificate at the bottom of it, you already know the pattern.
This article breaks down why certificate renewal so often becomes a process problem rather than a technical one, covers what cert-manager does and doesn't automate, and outlines how to design certificate operations so the debt never accumulates in the first place. Some of that debt can be avoided entirely by choosing a managed Kubernetes service like Kubo, which sidesteps the problem structurally.
1. The Real Reason Certificates Expire Isn't Technical — It's Procedural
In many organizations, the certificate renewal flow is surprisingly analog. Someone notices a certificate is nearing expiration, manually creates a CSR (certificate signing request), sends it to another team or an external CA contact, waits for the signed certificate to come back, and finally uploads it by hand. Multiple approval gates and cross-team handoffs are baked into this process, and a single renewal can easily take weeks.
The deeper problem is that ownership of this procedure is often left ambiguous. When no one clearly owns a certificate, no one notices the warning signs, and the failure only surfaces once production is already down. A roundup from Encryption Consulting describes how a 2018 certificate management failure at Ericsson knocked roughly 32 million people off 4G service in the UK alone, and how, in the 2017 Equifax breach, an expired certificate on a monitoring device went unnoticed for 19 months. In both cases, the technical root cause was simple — an expired certificate — but what turned it into a disaster was the absence of any mechanism to catch it.
What makes this worse is that the technical fix (say, writing Terraform code to automate renewal) is often finished in a short amount of time, while the explanation and consensus-building needed to convince stakeholders that "nothing will break" and "this fits our existing workflow" takes far longer than expected. Writing code has become one of the easier parts of the job. The hard part is designing the process for safely rolling out a change.
2. What cert-manager Automates — and What It Doesn't
The Kubernetes ecosystem has a standard tool for reducing this operational burden: cert-manager. According to the official cert-manager documentation, cert-manager ships with a subcomponent called "ingress-shim" that automatically generates a matching Certificate resource whenever you add specific annotations to an Ingress resource. Add a single annotation like cert-manager.io/cluster-issuer, and cert-manager takes over issuing, storing, and renewing the certificate.
Certificate issuers are managed through two resource types: Issuer and ClusterIssuer. Per the official cert-manager documentation on Issuers, an Issuer is namespace-scoped and can only be referenced by resources in that same namespace, while a ClusterIssuer is cluster-scoped and can be referenced by Ingress and Certificate resources across multiple namespaces. If you want a single, unified issuance policy across the whole organization, use a ClusterIssuer; if different teams need different CAs, use Issuers.
Let's Encrypt is the most common certificate issuer in this setup, but its production ACME endpoint has rate limits. According to Let's Encrypt's official rate limits documentation, a single account is capped at 300 new orders every 3 hours, and any one domain is capped at 50 certificates every 7 days. Hitting these limits during development — by repeatedly requesting certificates against the production endpoint — is common enough that Let's Encrypt strongly recommends using its staging environment instead. This is one reason cert-manager can't just be "installed and forgotten": you still need to understand these operational constraints well enough to design your Issuer setup and monitoring around them.
The Expiry Risk cert-manager Alone Can't Prevent
cert-manager handles automatic renewal, but it doesn't guarantee anyone notices when a renewal fails. Failed ACME challenges, DNS misconfigurations, permission issues that block a Secret update — failures happen even inside an automated pipeline. This "automated but unmonitored" state is exactly the gap the next section addresses.
3. Turning Certificate Renewal from a Ritual Into a Non-Event
Truly freeing certificate management from operational debt requires more than installing cert-manager — it requires designing the renewal process so it no longer depends on a human noticing anything. The most effective way to do that is to continuously monitor certificate expiry as a metric.
According to the official Prometheus documentation, Prometheus is an open-source monitoring tool that collects and stores numeric time-series data, evaluates rules against those metrics, and fires notifications through Alertmanager when conditions are met. By feeding cert-manager's metrics into Prometheus and alerting when a certificate's remaining validity drops below a threshold, you shift the operating assumption from "someone notices" to "the system tells you."
Certificate lifetimes themselves are also getting shorter, and that trend can't be ignored. According to a Sectigo blog post, the industry-standard maximum certificate validity period is scheduled to drop from 398 days to 200 days starting in March 2026, then to 100 days in 2027, and finally to 47 days by 2029. Shorter validity periods mean more frequent renewals, and the burden of manual operations scales up dramatically as a result. The same article warns that at that point, "manual certificate management becomes unsustainable." In other words, designing renewal automation and monitoring now is really about front-loading a cost that will only grow later.
Coverage of this topic is growing in Japanese-language media as well. An ITmedia article walks through introducing cert-manager to prevent the classic "forgot to renew" incident, but like most introductory guides, it focuses on installation rather than on clarifying process ownership or building in monitoring and alerting — the areas that actually reduce operational debt.
The same design principles apply in Rancher-based environments. A technical blog post on running cert-manager under Rancher walks through deploying cert-manager via Helm on K3s/Rancher and integrating it with Let's Encrypt or a Rancher CA. Even on a lightweight K3s cluster, the importance of automating and monitoring certificate management doesn't change.
4. With Managed Kubernetes, This Whole Process Never Has to Exist
As we've seen, turning certificate management into something you can trust to just work requires stacking up multiple layers: not just installing cert-manager, but designing your Issuer setup, testing against rate limits, and building out Prometheus-based monitoring and alerting. That's not a small amount of work, and many organizations get stuck at this stage and just resign themselves to "certificate renewal is a pain."
Kubo is a K3s-based managed Kubernetes service that ships with cert-manager and Let's Encrypt built in from the start. That means the Issuer design and monitoring setup this article describes is already done by the time you start using it. Compared to building, validating, and monitoring cert-manager yourself on EKS or AKS, this significantly cuts both the upfront build cost and the risk of the setup depending on one specific person's knowledge.
If the procedural complexity of certificate renewal is a recurring headache, it's worth considering an option that removes the procedure entirely. Kubo delivers full Kubernetes functionality without making you carry that operational debt from day one.
5. Summary
The core challenge in certificate management isn't whether you have cert-manager — it's whether anyone owns the renewal process and how it's monitored. Installing an automation tool and eliminating procedural debt are related but distinct problems. cert-manager itself is excellent, but without designing your Issuer/ClusterIssuer setup, operating within rate limits, and building in monitoring and alerting, you can still end up in the position of "we installed it, and it expired anyway without anyone noticing."
As certificate lifecycles keep shrinking, the cost of deferring this operational debt keeps rising every year. If you're tired of a meeting breaking out every time a certificate needs renewing, start by clarifying who owns your certificate operations and how they're monitored. From there, choosing a managed Kubernetes platform like Kubo that ships with certificate management built in is one solid option. If you'd like to talk through your certificate operations, feel free to reach out via our contact page.