Kubernetes Ingress and TLS with cert-manager

By Khimananda Oli | Last reviewed: August 2026

Exposing services securely in production requires more than just opening ports; you need automated certificate lifecycle management to prevent outages caused by expired SSL/TLS credentials. Configuring Kubernetes Ingress and TLS with cert-manager solves this by integrating directly with your ingress controller to request, validate, and renew certificates from authorities like Let’s Encrypt without manual intervention. If you are building on foundational cluster knowledge from our Kubernetes basics guide, this is the critical next step toward a resilient, audit-ready platform.

How do you install cert-manager and configure a ClusterIssuer?

Before any certificates can be issued, the cert-manager control plane must be running in your cluster. In 2026, Helm remains the standard installation method because it handles CRD (Custom Resource Definition) lifecycle management cleanly. Avoid static manifests for production environments; they make upgrades brittle and complicate RBAC configuration.

Install cert-manager via Helm

Add the official Jetstack repository and install the chart into a dedicated namespace. This isolates the controller from application workloads, which simplifies network policies and compliance scoping.

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.0 \
  --set crds.enabled=true

Verify the pods reach Ready status before proceeding. A common mistake is creating Issuer resources while the webhook pod is still initializing, leading to "connection refused" errors during validation.

Create a Production ClusterIssuer

A ClusterIssuer is scoped cluster-wide, unlike a namespaced Issuer. For most teams managing multiple applications, a single production ClusterIssuer reduces duplication. Use the ACME HTTP-01 solver for standard web workloads behind an ingress controller.

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

Always test against the Let’s Encrypt staging environment first (https://acme-staging-v02.api.letsencrypt.org/directory) to avoid hitting rate limits during debugging. Switch to production only after confirming successful issuance in staging.

How does Kubernetes Ingress and TLS with cert-manager automate certificate provisioning?

The automation magic happens through annotations on your Ingress resource. When cert-manager detects an Ingress with the correct annotation, it creates a CertificateRequest, performs domain validation, and stores the resulting TLS certificate in a Kubernetes Secret. The ingress controller then watches that Secret and reloads its configuration dynamically.

Annotate the Ingress Resource

Add the cert-manager.io/cluster-issuer annotation and specify a secretName under the TLS block. This tells cert-manager which issuer to use and where to store the certificate.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - app.example.com
    secretName: my-app-tls
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80

Monitor Certificate Readiness

Do not assume success. Check the Certificate and CertificateRequest resources explicitly. The kubectl get certificaterequest command reveals validation failures that are invisible at the Ingress level.

• kubectl get certificate -A — verify READY status is True
• kubectl describe certificaterequest <name> — inspect ACME challenge errors
• kubectl logs -n cert-manager deployment/cert-manager — controller-level diagnostics

What are the common troubleshooting steps when certificates fail to issue?

In practice, most failures stem from DNS misconfigurations, network policies blocking the ACME solver, or incorrect ingress class references. Before blaming cert-manager, systematically verify these layers.

1. DNS Resolution: Ensure the domain resolves to your ingress controller’s external IP. HTTP-01 validation fails silently if Let’s Encrypt cannot reach /.well-known/acme-challenge/.
2. Ingress Class Mismatch: The solver pod creates a temporary Ingress using the class specified in the ClusterIssuer. If your cluster uses a non-default class (e.g., nginx-internal), update the solver config accordingly.
3. Network Policies: Restrictive egress policies may block the cert-manager pod from reaching the ACME server. Allow outbound TCP 443 to acme-v02.api.letsencrypt.org.
4. Rate Limits: Let’s Encrypt enforces 50 certificates per registered domain per week. Use staging aggressively during development. For high-volume deployments, consider DNS-01 validation with Cloudflare or Route53, which supports wildcard certificates and avoids per-subdomain limits.

If you manage infrastructure declaratively, integrating cert-manager with ArgoCD for GitOps workflows ensures certificate configurations remain version-controlled and drift-free across environments.

How does cert-manager compare to manual TLS or external-dns approaches?

Understanding trade-offs prevents over-engineering. While cert-manager dominates for in-cluster automation, alternative patterns exist for specific compliance or architectural constraints.

For teams operating under SOC 2 or ISO 27001 frameworks, cert-manager’s event logging integrates naturally with centralized observability stacks. Pair it with Prometheus and Grafana monitoring to alert on certificate expiry windows and issuance failures as SLO violations rather than silent incidents.

How do you secure and maintain cert-manager in production?

Treating cert-manager as “install and forget” invites subtle failures. Production hardening requires proactive monitoring, backup awareness, and upgrade discipline.

• Backup etcd Regularly: Certificate private keys live in etcd via Secrets. Losing etcd means losing all active TLS credentials. Include etcd snapshots in your disaster recovery strategy.
• Set Expiry Alerts: Configure Prometheus alerts for certmanager_certificate_expiration_timestamp_seconds. Trigger warnings at 30 days and critical pages at 7 days. Never rely solely on auto-renewal without observability.
• Restrict RBAC: Limit who can modify ClusterIssuers. Unauthorized changes can redirect certificate issuance or expose private keys. Apply least-privilege principles consistent with IAM best practices.
• Upgrade During Maintenance Windows: Cert-manager upgrades occasionally change CRD schemas. Always review release notes and test in staging. Pin versions in Helm charts to prevent surprise updates.

Next Steps for Secure Kubernetes Traffic

Implementing Kubernetes Ingress and TLS with cert-manager transforms certificate management from a recurring operational tax into an invisible, reliable foundation. You now have automated issuance, built-in renewal, and audit-friendly event trails that satisfy both engineering velocity and compliance requirements. Validate your setup end-to-end using SSL Labs, confirm renewal behavior in staging, and integrate certificate metrics into your existing dashboards before promoting to production. If your team needs hands-on support designing compliant, scalable Kubernetes platforms tailored to your workload, reach out to discuss your infrastructure requirements.