Your phone buzzes with a Slack alert on a Saturday morning. The production site is returning 503s. The cause: an expired TLS certificate. And this cluster had cert-manager installed months ago. "Wasn't the certificate supposed to renew automatically?"
Incidents like this are far from rare in K3s and Kubernetes environments. Installing cert-manager and having cert-manager actually keep renewing certificates are two completely different problems. The old manual process — generating a CSR, submitting it to a certificate authority, receiving the signed cert, and uploading it — used to break down every time the responsible engineer changed and the handoff got lost. Ironically, even after automation tools are introduced, the same tribal-knowledge risk lingers in a new form: misconfiguration and missing monitoring.
K3s bundles Traefik as its default Ingress controller, and TLS termination at the edge relies on the combination of Traefik and the Secret that cert-manager issues. That means if cert-manager's renewal stalls, TLS termination for the entire K3s cluster stops with it.
This post walks through four patterns where certificates silently expire even with cert-manager installed, and the design needed to turn TLS certificate auto-renewal from something you "installed" into something that's actually "running," in a K3s context.
Why "Installed" and "Working" Are Different Problems — Four Ways cert-manager Fails Silently
cert-manager is an open-source project hosted on GitHub and a CNCF Graduated project, used widely enough to see 500 million downloads a month — a genuinely trusted tool. Yet certificate renewal failures in production remain common. The typical causes fall into four categories.
1. Issuer / ClusterIssuer misreferences
cert-manager defines a certificate's issuing authority as either an Issuer (namespace-scoped) or a ClusterIssuer (cluster-wide). If a Certificate resource references the wrong one, or a cross-namespace reference is misconfigured, issuance simply never happens. This kind of misconfiguration is especially common in production clusters spanning multiple namespaces.
2. Failed DNS-01 validation
For wildcard certificates or multi-domain certificates, cert-manager verifies domain ownership using the DNS-01 challenge — writing a TXT record the ACME server requests, waiting for propagation, and then validating it. If you change an Ingress hostname and forget to update the corresponding DNS record, or if a DNS provider's API credentials expire, validation quietly keeps failing.
3. Let's Encrypt rate limit exhaustion
Let's Encrypt enforces rate limits to keep usage fair. According to its official documentation, a registered domain can have up to 50 certificates issued per 7 days, and a single account can create up to 300 new orders every 3 hours. If a misconfiguration causes the same certificate request to fail repeatedly, these limits get hit fast, blocking even legitimate renewal requests. Worse, more than 5 authorization failures per hour trigger a temporary account-level restriction that requires action through the self-service portal to recover from.
4. Secrets update, but Pods and Ingress don't reload
When cert-manager renews a certificate, it writes the new content into a Kubernetes Secret. Per the Kubernetes documentation, if a Secret is mounted as a volume, kubelet detects the change and eventually updates the file — but this doesn't apply when the Secret is mounted via subPath. On top of that, applications that read certificates from environment variables, or processes that load a certificate into memory only once at startup, will keep using the stale certificate until they're restarted, even after the Secret updates.
What all four patterns share is that none of them surface as a visible error. Even when renewal fails, the system looks like it's working normally right up until the certificate's actual expiration. It's the same "you don't notice until it's too late" structure that manual certificate management always had.
Many of these pitfalls stem from rebuilding Issuer configuration and DNS provider integration from scratch every time a new cluster is created. With a managed K3s platform like Kubo, where cert-manager installation and ClusterIssuer setup are templated in from the start, you begin from a state where reference errors and configuration gaps are structurally less likely to happen.
The Design That Turns "Should Be Working" Into "Is Working" — Monitoring, renewBefore, and Staging Validation
Keeping certificate auto-renewal actually functioning requires more than installing a tool — it takes a mechanism for detecting failure and a design with enough margin for error.
Build in monitoring that catches problems before expiration
cert-manager exposes renewal status through the Certificate resource, which can be scraped as Prometheus metrics. It's important to dashboard remaining certificate validity and fire alerts once it drops below a threshold — independently of monitoring cert-manager itself. The key is monitoring "whether the certificate is currently valid" directly, rather than "whether the last renewal succeeded." With a managed K3s platform like Kubo, which ships with Prometheus and Grafana out of the box, you don't need to build this monitoring stack from scratch.
Secure a buffer with renewBefore
According to cert-manager's official documentation, when no renewal timing is specified, a certificate renews automatically once two-thirds of its validity period has elapsed — roughly 30 days before expiry for a 90-day certificate. This default acts as a buffer that absorbs transient failures from DNS propagation delays or rate limits. If you set spec.renewBefore explicitly, be careful not to shrink that buffer too much.
Note that Let's Encrypt has publicly announced a phased plan to shorten default certificate lifetimes, moving from 90 days to 64 days and eventually to 45 days. As lifetimes shrink, the window between a failed renewal and real production impact shrinks too — making monitoring and buffer design even more important.
Validate in staging before applying to production
Issuer configuration changes or new DNS provider integrations should be validated against Let's Encrypt's staging environment before switching over the ClusterIssuer. Staging enforces the same rate-limiting mechanics as production, but failures there don't consume your production rate limit. Iterating on a misconfiguration directly against the production ClusterIssuer can burn through your rate limit all by itself.
A Managed K3s Platform Can Eliminate "Expired Without Anyone Noticing" Structurally
None of the four failure patterns covered here, or the monitoring and buffer design that prevents them, are technically difficult on their own. But keeping all of it "correctly configured and correctly monitored" continuously is itself an easily overlooked operational cost. Reviewing Issuer configuration, maintaining Prometheus alert rules, rotating DNS credentials — this kind of unglamorous, ongoing work becomes more prone to tribal knowledge as the number of K3s clusters grows, or as the people responsible for them change.
Kubo's managed K3s platform ships with certificate automation via cert-manager and Let's Encrypt built in. There's no need to build and maintain ClusterIssuer setup, DNS provider integration, or monitoring from scratch, and you still get the full feature set of standard Kubernetes on top of K3s's lightweight footprint. Running a container platform equivalent to EKS or AKS at roughly ¥48,000/month for a 4vCPU/8GB/40GB × 3-node configuration is possible in large part because this kind of operational work is standardized.
Certificate management is a deceptively unglamorous area with a specific property: the damage when it breaks is large, but it's hard to notice until it does. Handing this off structurally to a managed platform isn't just about convenience — it's a design decision that reduces the actual risk of production incidents.
Summary
Between installing cert-manager and having TLS certificate auto-renewal actually keep working lies a set of hard-to-see pitfalls: Issuer misreferences, failed DNS-01 validation, Let's Encrypt rate limit exhaustion, and Secrets that never get reloaded. Automation was supposed to eliminate the tribal-knowledge risk of manual renewal, but neglecting configuration and monitoring drags you right back into the same "you don't notice until it's too late" structure.
Monitoring expiration directly, securing a sufficient buffer with renewBefore, and validating changes in staging — only once these three practices are built into your operations does certificate management actually move from "installed" to "working." And if you want to eliminate this operational burden structurally, migrating to a managed K3s platform like Kubo, where cert-manager operations come standard, is a realistic option worth considering.