cert-manager automates certificate issuance and renewal through Kubernetes resources. This guide installs it with Helm, creates a staging ACME ClusterIssuer, requests an Ingress certificate, and shows the safe path to production.
1. Prepare and execute
Confirm the active kubeconfig context and namespace before applying changes. Save commands and manifests in version control without credentials.
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm upgrade --install cert-manager jetstack/cert-manager
--namespace cert-manager --create-namespace
--set crds.enabled=true
kubectl -n cert-manager rollout status deployment/cert-manager --timeout=3m
2. Declarative configuration
Save the following example in a clearly named YAML file, review it, then use server-side dry-run when the API is available.
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata: {name: letsencrypt-staging}
spec:
acme:
email: admin@example.com
server: https://acme-staging-v02.api.letsencrypt.org/directory
privateKeySecretRef: {name: letsencrypt-staging-account}
solvers:
- http01: {ingress: {ingressClassName: nginx}}
3. Verify the result
A successful command is not enough. Inspect resource state, conditions, events, endpoints, logs, and an end-to-end request where applicable.
kubectl apply -f issuer.yaml
kubectl get clusterissuer letsencrypt-staging
kubectl -n APP_NAMESPACE get certificate,certificaterequest,order,challenge
kubectl -n APP_NAMESPACE describe certificate APP_TLS
kubectl -n cert-manager logs deployment/cert-manager --tail=100
4. Troubleshooting
HTTP-01 requires public DNS to point at the Ingress and Internet access to port 80. Start with the staging CA to avoid rate limits, then create a separate production issuer and update the annotation only after staging succeeds.
5. Rollback and cleanup
Review the exact target before deleting resources, especially namespaces, claims, Secrets, and cluster-wide add-ons.
kubectl delete clusterissuer letsencrypt-staging
helm uninstall cert-manager -n cert-manager
# Do not delete CRDs before reviewing all certificates and secrets.
Production checklist
- The active context, namespace, and target version were verified.
- Manifests passed client or server-side validation.
- Resource conditions and recent events show no unresolved error.
- Access, network exposure, resource limits, persistence, and rollback were reviewed.
- Commands and expected output were recorded for the operating team.
References: topic documentation and Kubernetes documentation.
