When a cert-manager-issued certificate stops renewing in a Kubernetes cluster, the specific reason is almost always recorded in cert-manager's own logs or in the status of the relevant Certificate resource — checking there directly is far more effective than guessing.
kubectl describe certificate yourcert-name -n yournamespace
kubectl logs -n cert-manager deploy/cert-managerCommon causes
- The ACME HTTP-01 or DNS-01 challenge failing due to an Ingress or DNS configuration change since the certificate was first issued
- A ClusterIssuer or Issuer resource referencing credentials (a DNS API token, for example) that have since expired or been revoked
- Rate limiting from the certificate authority if renewal attempts have been failing and retrying repeatedly without the underlying issue being fixed
What to check first when cert-manager isn't renewing as expected
Checking the specific Certificate resource's status conditions via kubectl, along with cert-manager's own controller logs, typically reveals the specific validation or configuration issue preventing renewal, rather than needing to guess based on the Ingress resource's behavior alone.
How RBAC permission issues can silently block cert-manager's renewal process
If cert-manager's service account lacks the specific Kubernetes RBAC permissions needed to update Certificate resources or access DNS provider credentials stored as secrets, renewal can fail silently without an obviously certificate-related error message — checking cert-manager's controller logs specifically for permission-denied messages catches this less obvious cause.
What specific kubectl commands help diagnose a stuck certificate renewal
Running `kubectl describe certificate
How to manually trigger a certificate renewal for testing purposes in cert-manager
Deleting the associated Kubernetes Secret resource (not the Certificate resource itself) prompts cert-manager to detect the missing secret and automatically attempt reissuance, a common technique for manually testing or forcing a renewal attempt outside the normal automatic schedule.
A final note on proactive monitoring
Setting up monitoring specifically on cert-manager's own health and certificate status, integrated with your cluster's broader observability tooling, catches a renewal problem proactively rather than only discovering it once a certificate has actually expired and started affecting live traffic.
What specific kubectl commands reveal the most diagnostic detail quickly
Running kubectl get certificate -A to see status across every namespace, then kubectl describe certificate
How cert-manager's webhook component can itself become a point of failure
cert-manager's webhook component, responsible for validating its own custom resources, can occasionally become unavailable or misconfigured independently of the rest of cert-manager — checking the webhook pod's own status and logs specifically, not just the main controller, is worth doing if certificate resources seem to be rejected or stuck unexpectedly.
A quick closing checklist
A quick closing checklist covers checking Certificate and CertificateRequest resource status directly, reviewing cert-manager's controller and webhook logs, and confirming RBAC permissions are correctly configured for cert-manager's service account.
Why cert-manager version upgrades deserve careful testing given the pace of the project's development
cert-manager is an actively developed project with periodic breaking changes between major versions — testing any cert-manager upgrade in a non-production cluster first, rather than upgrading directly in production, avoids an upgrade-related renewal disruption.