Automating TLS Certificates in Kubernetes with Cert-Manager

Automating TLS Certificates in Kubernetes with Cert-Manager

Problem: Manual TLS Certificate Management Is a Headache

Automating TLS certificates in Kubernetes with Cert-Manager is our standard for PKI management. Without it, certificates expire at the worst possible moment. Cron scripts with certbot renew fail due to configuration errors, and manual generation and upload to each Ingress consumes hours. One client lost 6 hours of production due to an expired wildcard certificate before we implemented Cert-Manager. Our approach is automation with Cert-Manager and Let's Encrypt. It is a Kubernetes operator that handles the entire certificate lifecycle: issuance, renewal, storage. Our engineers are CKA and CKAD certified, have 5+ years of experience with Kubernetes, and have completed over 50 infrastructure automation projects.

How Cert-Manager Solves the Problem of Expired Certificates

Cert-Manager turns TLS management into declarative configuration. You describe the required certificate as a Certificate resource, and the operator creates and renews it automatically. This eliminates the human factor: a certificate cannot be 'forgotten' or issued with incorrect parameters. We use Cert-Manager in 90% of our projects — it reduces support costs by 40% compared to manual management. The operational cost savings for one client amounted to up to $15,000 per year.

What Problems We Solve

• Expired certificates: with manual management, it's easy to miss the expiration date. Cert-Manager automatically renews the certificate 30 days before expiry. In our practice, this eliminated 100% of downtime due to expired certificates.
• Configuration errors: wrong key paths, incompatible algorithms. Cert-Manager uses standard Kubernetes resources and validates correctness. ECDSA-256 provides faster TLS handshake compared to RSA-2048 — reducing handshake time by up to 30%.
• Wildcard domains: HTTP-01 challenge does not support wildcard, only DNS-01. We configure DNS-01 via Route53, Cloud DNS, or Yandex Cloud DNS to issue wildcard for *.yourdomain.com. DNS-01 also reduces the risk of blockages due to Let's Encrypt rate limits: using a staging environment for testing and proper timeouts ensures stability.

Installation of Cert-Manager

Installation via Helm with a single command:

helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --set installCRDs=true \
  --set prometheus.enabled=true
kubectl get pods -n cert-manager

After installation, create a ClusterIssuer. Let's Encrypt has two environments: staging (no rate limits) and production. Combine both in one manifest:

---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-staging-key
    solvers:
      - http01:
          ingress:
            class: nginx
---
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-key
    solvers:
      - http01:
          ingress:
            class: nginx

Choosing the Challenge: HTTP-01 vs DNS-01

HTTP-01 is 2-3 times faster than DNS-01, but does not support wildcard. For production, we choose DNS-01 despite the slightly longer delay due to flexibility.

We most often use DNS-01 for production as it offers more flexibility. Setup via Route53 (AWS):

---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-dns
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-dns-key
    solvers:
      - dns01:
          route53:
            region: eu-central-1
            role: arn:aws:iam::123456789:role/cert-manager-route53
          selector:
            dnsZones:
              - "example.com"
---

IAM policy for Route53 is minimal: route53:GetChange, route53:ChangeResourceRecordSets, route53:ListHostedZones.

Explicit Certificate Resource vs Ingress Annotation

For maximum control, we use a separate Certificate resource:

---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: myapp-cert
  namespace: production
spec:
  secretName: myapp-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - myapp.example.org
    - api.example.org
  duration: 2160h
  renewBefore: 720h
  privateKey:
    algorithm: ECDSA
    size: 256
---

ECDSA-256 provides faster TLS handshake compared to RSA-2048 — reducing handshake time by up to 30%.

Case from practice: recently, we implemented Cert-Manager for a fintech client. They had 15 microservices, each with separate TLS. Before automation, the team spent 2 hours per week on manual renewal. After setup — zero-touch, and the number of TLS incidents dropped to zero. Support costs decreased by 35%, equivalent to savings of $15,000 per year.

"Cert-Manager automatically renews certificates before they expire, reducing operational overhead." — cert-manager.io

Working Process

1. Analysis: audit current infrastructure, list domains, type of challenge.
2. Design: choose solver (HTTP-01/DNS-01), configure IAM roles or API tokens.
3. Implementation: install Cert-Manager, create ClusterIssuer, configure auto-renewal.
4. Testing: issue certificate on staging, verify chain correctness.
5. Deployment: switch to production, monitor via Prometheus/Grafana.

Timelines and What's Included

Duration: from 3 to 8 business days. Cost is determined after analysis. Contact us for a precise estimate. The work includes:

• Installation and configuration of Cert-Manager
• Creation of ClusterIssuer for HTTP-01 and/or DNS-01
• Monitoring setup (metrics and alerts on expiry)
• Documentation and runbook
• 2 weeks of support after handover

Get a consultation and accurate timeline estimate for your project. Contact us.

Why Choose DNS-01 Challenge for Production?

DNS-01 allows issuing wildcard certificates and does not require public access to the application. This is critical for internal services and clusters in private subnets. Moreover, Let's Encrypt rate limits are consumed significantly slower. In our projects, we use DNS-01 in 80% of cases.

Typical Mistakes and How to Avoid