cert-manager: Automate Kubernetes TLS Setup Guide 2026

By Khimananda Oli | Last reviewed: August 2026

Managing TLS certificates manually in production clusters is a reliability risk and an audit failure waiting to happen. You need cert-manager: Automate Kubernetes TLS to eliminate expired certificate outages and ensure continuous compliance without operational toil. This guide walks you through the exact configuration patterns I use to manage thousands of certificates across multi-cloud environments securely.

Quick answer: cert-manager automates Kubernetes TLS by deploying as a cluster operator that watches Certificate custom resources, requests certificates from issuers like Let's Encrypt or AWS PCA, stores them in Secrets, and handles renewal automatically before expiry.

cert-manager architecture: the controller watches Certificate resources, requests from configured issuers, and injects TLS secrets into ingress controllers automatically.

How do you install and configure cert-manager for Kubernetes TLS automation?

The most reliable installation method in 2026 is Helm with explicit namespace isolation and resource quotas. Before installing, ensure your cluster meets the prerequisites: Kubernetes 1.28+, RBAC enabled, and network policies allowing outbound HTTPS to your chosen issuer endpoints. For teams managing ingress controllers, cert-manager integrates directly via annotations or Gateway API references.

Install cert-manager with Helm

helm repo add jetstack https://charts.jetstack.io --force-update
helm repo update

helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.17.2 \
  --set crds.enabled=true \
  --set prometheus.enabled=true \
  --set webhook.timeoutSeconds=30

Always set crds.enabled=true in production. Separating CRD management from the main chart prevents accidental deletion during upgrades. The webhook timeout is critical; default values cause failures on slow API servers or when network latency exists between control plane components.

Create a ClusterIssuer for Let's Encrypt

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
    - http01:
        ingress:
          class: nginx
    - dns01:
        cloudflare:
          apiTokenSecretRef:
            name: cloudflare-api-token
            key: api-token
      selector:
        dnsZones:
        - "internal.example.com"

This dual-solver configuration handles public domains via HTTP-01 validation while routing internal zones through DNS-01. Store the Cloudflare API token in a sealed secret or external secrets operator — never commit it to Git. For SOC 2 compliance, restrict the token to Zone.DNS edit permissions only.

How does cert-manager handle certificate renewal and prevent outages?

Certificate renewal failures are the #1 cause of cert-manager-related incidents. Understanding the renewal window mechanics prevents 3 AM pages. cert-manager defaults to renewing at 2/3 of the certificate lifetime (typically 30 days before expiry for 90-day Let's Encrypt certs). This buffer accounts for transient ACME failures, rate limits, and network issues.

Frequently Asked Questions

Cert-manager is a native Kubernetes certificate controller that automates TLS issuance and renewal using ACME, Vault, or Venafi. It integrates with Ingress resources to eliminate manual certificate management and prevent expiration outages in production clusters.

Add the jetstack chart repository and run helm install cert-manager jetstack/cert-manager with namespace cert-manager and createCustomResources enabled. This deploys the controller, webhook, and CRDs required for automated TLS provisioning on current Kubernetes versions.

Yes, configure a ClusterIssuer with the Let's Encrypt production ACME server URL and HTTP01 or DNS01 solver. Ensure your domain validation method matches your infrastructure before switching from staging to avoid rate limit issues during testing.

Wildcard certificates require DNS01 validation since HTTP01 cannot prove ownership of subdomains. Configure an Issuer with a DNS provider webhook like Cloudflare or Route53 to automatically create TXT records for ACME challenges.

Yes, cert-manager is open source under Apache 2.0 license. Costs only arise from paid CA services, DNS providers, or enterprise support contracts, not from the software itself running in your cluster.

Cert-manager issues and renews TLS certificates while external-dns manages DNS record creation. They complement each other but serve distinct purposes; you often need both for fully automated ingress TLS with dynamic hostnames.

Check kubectl describe certificate for event details. Common causes include failed ACME challenges, missing secret references, incorrect issuer configuration, or network policies blocking webhook traffic between cert-manager components and the API server.

Yes, cert-manager v1.14+ supports Gateway API through the gateway-shim annotation or direct integration. Configure HTTPRoute annotations to trigger certificate requests automatically when routes reference hosts requiring TLS termination at the gateway level.

Default renewal occurs at two-thirds of certificate lifetime, typically thirty days before expiry for ninety-day Let's Encrypt certs. Adjust renewBefore in Certificate specs to control timing and avoid renewal storms across large fleets.

Yes, configure Issuers pointing to HashiCorp Vault, AWS PCA, or custom CA endpoints. This enables internal mTLS and zero-trust architectures without exposing services to public ACME providers or internet-facing validation challenges.

Minimal RBAC includes secrets, certificates, certificaterequests, orders, and challenges in target namespaces. Avoid cluster-wide secrets access; use namespace-scoped Issuers and role bindings to follow least privilege principles in multi-tenant clusters.

Inspect Order and Challenge resources with kubectl get challenges -o wide. Verify DNS propagation for DNS01 or ingress routing for HTTP01. Check cert-manager logs for HTTP errors, timeout messages, or provider authentication failures causing validation blocks.

Yes, define multiple Issuer resources and reference them explicitly in Certificate specs via issuerRef. This allows mixing Let's Encrypt, Vault, and self-signed CAs within the same namespace based on workload requirements and trust boundaries.

Automatically stores issued TLS data in specified Secret resources referenced by Ingress or Gateway configurations. Use additionalOutputFormats to generate JKS or PKCS12 bundles for Java applications requiring non-PEM certificate formats.

Cert-manager persists state in Custom Resources, not memory. On restart, it reconciles pending Orders and Challenges automatically. No certificates are lost, though active ACME transactions may retry after exponential backoff delays resume.