Cert-Manager: Automated Certificate Management For Kubernetes – Free Your Engineers

An introduction to Cert-Manager for Kubernetes and step-by-step set-up guide

CloudUPDATED ON December 7, 2021

John Adam K&C head of marketing


Kubernetes 1.15

What is Cert-Manager for Kubernetes?

In this post, we’ll address the utility offered by the cert-manager automated certificate management tool for Kubernetes, what it does, the output of that functionality. And we document a step-by-step guide to cert-manager set-up and configuration.

Cert-manager, an open-source jetstack.io project, is an ISA x509 certificate management controller native to Kubernetes. As an automation tool, cert-manager reduces the ‘routine work’ load on engineers, allowing highly paid experts to focus on where they can add the most value. It simplifies management, issuance and the renewal of certificates, securing application traffic – a critical function in the contemporary web. Automating the certification process saves engineers time as well as improving security by negating the risk of human error.

Cert-manager follows on from kube-lego,  jetstack.io’s original Let’s Encrypt certificate provisioning tool for Kubernetes Ingress resources. Kube-lego simplifies the securing of traffic between your users and your cluster ingress point. But limitations of building a controller only around Kubernetes Ingresses have become clear.

Cert-manager has been built around Kubernetes CustomResourceDefinitions, which has led to significantly more flexibility around configuration. Debugging capabilities are also improved upon and now support a broader range of CAs than Let’s Encrypt as a stand-alone tool.

Agile & DevOps teams and consultants

Supercharge your next cloud development project!

When should you use cert-manager certificate automation?

A good example of the strengths of employing cert-manager certificate automation would be a web-based application whose user-facing interface, API, admin front and admin API are all hosted under separate domain names. This means each service requires its own individual certificate. The Cert Manager monitors the timing of these certificates and renews them if and when necessary.

When dynamical environments are used in the development process (a feature is written, the next dev environment created, tested and the environment deleted) SSL certification need to be constantly generated. As a manual process, that’s a lot of expensive work-hours. But if a ‘heart manager’ is set up, it will generate all necessary certificates automatically without any engineer involvement. This is particularly beneficial in the case of larger web-based applications. In the case of an example of 20 services, automating certification using cert-manager could potentially save a very significant amount of manual engineer work.

Cert-Manager Components

  • Issuers represent a certificate authority from which signed x509 certificates can be obtained, such as Let’s Encrypt– jetstack.io’s certificate provisioning tool for Kubernetes Ingress resources.
  • ClusterIssueris a resource type similar to Issuers. It is specified in exactly the same way, but it doesn’t belong to a single namespace and can be referenced by Certificate resources from multiple different namespaces.
  • Certificate is a namespaced resource that references an Issuer or ClusterIssuerfor information on how to obtain the certificate.

Setting Up Cert-Manager: a step-by-step tutorial

The first step to setting up cert-manager is to install custom CRDs – ClusterIssuer, Certificate, Order and Challenge. Cert-manager is then installed via Helm.

Helm helps manage the required state of multiple Kubernetes objects. Its effectiveness is optimised when paired with Reckoner, which uses a YAML syntax to install multiple Helm releases at once, and facilitates the installation of charts from a git repository.

A new object Certificate is then created and Cert-manager subsequently creates Order with CSR and Сhallenge, using Order to obtain new a certificate.

To obtain new certificates Cert-manager creates a separate Ingress with a URL like the following example:

http://main.domain.com/.well-known/acme-challenge/SFAHjkfhkj2hjkn23kbk32nknkfn3ktk3j4gkj3b .

This Ingress points to a custom Service and returns a hash for certificate validating. In parallel, cert-manager creates a self-signed certificate until the main certificate is obtained.

All of these certificates (temporary and main) are stored in Secret and used in Ingress config.

After obtaining a valid certificate, cert-manager places this certificate in Secret in place of the temporary certificate, deleting also the temporary Ingress and Service.

When does IT Outsourcing work?

(And when doesn’t it?)

How To Install Cert-Manager

Create a custom CRD

kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.9/deploy/manifests/00-crds.yaml

Create and label namespace for cert-manager

kubectl create namespace cert-manager
kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true

Add helm repository for using latest helm-chart

helm repo add jetstackhttps://charts.jetstack.io
helm repo update

Install Cert-manager helm-chart

helm install –name cert-manager –namespace cert-manager –version v0.9.1 jetstack/cert-manager

Create ClusterIssuer

Cert-manager could obtain certificates in a different CA. For example, let’s see how it works with Let’s Encrypt:

kubectlapply -f letsencrypt-clusterissuer.yaml


apiVersion: certmanager.k8s.io/v1alpha1

kind: ClusterIssuer


name: letsencrypt-cluster-issuer



# The ACME server URL

server: https://acme-v02.api.letsencrypt.org/directory

# Email address used for ACME registration

email: [email protected]

# Name of a secret used to store the ACME account private key


name: letsencrypt-prod

# Enable the HTTP-01 challenge provider

http01: {}


privateKeySecretRef.name – Secret which contains the  Private Key for Cluster Issuer and it will be created automatically.

And that’s it, your Kubernetes cluster ready for obtaining Let’s Encrypt certificates. For creating certificates manually we should use the next config:


apiVersion: certmanager.k8s.io/v1alpha1

kind: Certificate


name: test-cm.krusche.cloud

namespace: default


secretName: prod-cert-nginx


name: letsencrypt-cluster-issuer

kind: ClusterIssuer

commonName: test-cm.krusche.cloud


- test-cm.krusche.cloud



- http01:

ingressClass: traefik


- test-cm.krusche.cloud


secretName – this Secret contains a certificate that should be used in Ingress. It will be created automatically.
commonName- main domain name
dnsNames- alternative domain name ( SAN )

For automated certificate generation, you should add the next annotation to Ingress config:


apiVersion: extensions/v1beta1

kind: Ingress


name: nginx


kubernetes.io/ingress.class: "traefik"

certmanager.k8s.io/cluster-issuer: "letsencrypt-cluster-issuer"

kubernetes.io/tls-acme: "true"

certmanager.k8s.io/acme-challenge-type: "http01"



- hosts:

- test-cm.krusche.cloud

secretName: quickstart-example-tls-5-prod


- host: test-cm.krusche.cloud



- path: /


serviceName: nginx

servicePort: 80

secretName – this Secret contains a certificate that should be used in Ingress. It will be created automatically.

Your cert-manager should now be all set up on Kubernetes ready to start automating certificate management.

K&C - Creating Beautiful Technology Solutions For 20+ Years . Can We Be Your Competitive Edge?

Drop us a line to discuss your needs or next project