How to Automate TLS Certificate Issuance with cert‑manager in Kubernetes

With the rise of cloud‑native applications, securing data transmission is crucial. Using cert‑manager together with free CAs like Let’s Encrypt enables automated certificate management, simplifying operations. After installing cert‑manager and configuring a ClusterIssuer, you can request TLS certificates.

Request Certificate

The following use cases are available:

Certificate resource : the simplest and most common way to request a signed certificate.

Protect Ingress resource : secure Ingress objects in your cluster.

Protect Istio gateway : use cert‑manager to secure an Istio gateway.

Protect Istio service mesh : enable mTLS for each pod via cert‑manager‑managed certificates.

Scenario 1: Direct certificate request

<code>$ cat <<'EOF' | kubectl apply -f -
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: test-dns-cert
  namespace: default
spec:
  # secret name
  secretName: test-dns-cert
  # X509v3 subject name
  commonName: test.jiaxzeng.com
  subject:
    countries:
    - CN
    provinces:
    - GuangDong
    localities:
    - GuangZhou
    organizations:
    - k8s
  # private key configuration
  privateKey:
    rotationPolicy: Always
    algorithm: ECDSA
    encoding: PKCS8
    size: 256
  usages:
    - server auth
    - client auth
  # certificate validity (default 90 days)
  duration: 8760h # 365d
  renewBefore: 744h # 31d
  # subject alternative names
  dnsNames:
  - "test.jiaxzeng.com"
  - "jiaxzeng.com"
  ipAddresses:
  - "127.0.0.1"
  # issuer reference
  issuerRef:
    name: ca-cluster-issuer
    kind: ClusterIssuer
EOF</code>

Tip: .spec.commonName and .spec.subject map to the certificate Subject field; .spec.duration maps to Validity; .spec.usages maps to X509v3 Extended Key Usage; .spec.dnsNames and .spec.ipAddresses map to Subject Alternative Name; .spec.issuerRef configures the issuer information.

Scenario 2: View the certificate

<code>$ kubectl get cert test-dns-cert
NAME            READY   SECRET          AGE
test-dns-cert   True    test-dns-cert   8s

$ kubectl get secret test-dns-cert -ojsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -text -noout</code>

Tip: Observe the Issuer, Validity, Subject, and X509v3 Subject Alternative Name fields.

Scenario 3: Clean up

<code>$ kubectl delete cert test-dns-cert
certificate.cert-manager.io "test-dns-cert" deleted

$ kubectl delete secret test-dns-cert
secret "test-dns-cert" deleted</code>

Ingress Certificate Request

Step 1: Create a self‑signed issuer

<code>$ cat <<'EOF' | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: ca-cluster-issuer
    cert-manager.io/common-name: simple.jiaxzeng.com
    cert-manager.io/duration: 8760h
    cert-manager.io/renew-before: 744h
  name: simple
  namespace: default
spec:
  ingressClassName: nginx
  rules:
  - host: simple.jiaxzeng.com
    http:
      paths:
      - backend:
          service:
            name: simple
            port:
              number: 80
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - simple.jiaxzeng.com
    secretName: simple.jiaxzeng.com
EOF</code>

Step 2: View the certificate

<code>$ kubectl get cert simple.jiaxzeng.com
NAME                 READY   SECRET               AGE
simple.jiaxzeng.com  True    simple.jiaxzeng.com  13s

$ kubectl get secret simple.jiaxzeng.com -ojsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -text -noout</code>

Step 3: Clean up

<code>$ kubectl delete ingress simple
ingress.networking.k8s.io "simple" deleted

$ kubectl delete secret simple.jiaxzeng.com
secret "simple.jiaxzeng.com" deleted</code>

Reference Documentation

https://cert-manager.io/docs/usage/certificate/

https://cert-manager.io/docs/usage/ingress/

https://cert-manager.io/docs/usage/ingress/#supported-annotations

Conclusion

This guide shows how to request and apply TLS certificates with cert‑manager after installing it and configuring a ClusterIssuer, enhancing application security and simplifying operations in cloud‑native environments.