Let’s encrypt and CertManager

How to use CertManager and Let’s encrypt in Kubernetes

Magsther

Published in

FAUN — Developer Community 🐾

5 min readNov 2, 2022

Introduction

This guide will help you deploy:

CertManager
Let’s Encrypt
Nginx Ingress controller and rules
Demo application
Setup Nginx Ingress with CertManager

What to expect

In this post we will look at CertManager and Let’s Encrypt.

In the next post, we will build upon this and look at Nginx Ingress as well how we can provision certificates for an application.

Prerequisite

To follow along in this post, you need to have a Kubernetes cluster deployed as well as kubectl and helm

CertManager

We can use CertManager to manage and provision TLS certificates (from example Let’s Encrypt)

cert-manager adds certificates and certificate issuers as resource types in Kubernetes clusters, and simplifies the process of obtaining, renewing and using those certificates.

cert-manager also helps to automatically renew certificates, by calculating when to renew a Certificate based on the issued X.509 certificate's duration and a 'renewBefore' value which specifies how long before expiry a certificate should be renewed.

The default value is 90 days and when that is reached, it creates a new certificate request and issues a new certificate from let’s encrypt.

Why do we need CertManager?

We want to use certificates for securing for example web applications with SSL. This process can sometimes be complicated and CertManager automates this within Kubernetes clusters.

Deploying CertManager

To deploy CertManager, we can follow the installation guide outlined in the documentation.

The easiest way of installing CertManager is by running the below command:

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.9.1/cert-manager.yaml

Note that CertManager can also be deployed using Helm.

If you now run kubectl get crds, you should see the following resources created:

NAME                               
certificaterequests.cert-manager.io 
certificates.cert-manager.io 
challenges.acme.cert-manager.io                  
clusterissuers.cert-manager.io 
issuers.cert-manager.io
orders.acme.cert-manager.io

You can also see that three pods are running in the cert-manager namespace.

kubectl get pods --namespace cert-manager

You should see the following output:

NAME    
cert-manager-6544c44c6b-5gx5d              1/1     Running
cert-manager-cainjector-5687864d5f-zjshf   1/1     Running
cert-manager-webhook-785bb86798-8kmtl      1/1     Running

Certificate Issuer

Once CertManager is installed, we can begin creating a Certificate Issuer for the domains that we want to use. When we do this, we will use the certissuer.cert-manager.io CRD that got deployed with the CertManager installation.

A certificate issuer is the entity that verified the information and signed the certificate.

There are many different issuers that CertManager supports to issue certificates.

Let’s Encrypt

In this post, we will use the Let’s Encrypt certificate authority. In a little while we will use this to get a certificate for our demo application.

What is Let’s Encrypt?

Let’s Encrypt is a free, automated, and open certificate authority that provides free TLS certificate.

You can setup Let’s Encrypt using a staging server for testing your certificate configuration, and a production server for rolling out verifiable TLS certificates.

We highly recommend testing against our staging environment before using our production environment. This will allow you to get things right before issuing trusted certificates and reduce the chance of your running up against rate limits.

One of the differences is that the production server have rate-limit requests. Another important difference is that every client will give a certificate error, because the staging CA isn’t trusted.

The production CA is trusted, while the staging CA isn’t.

You can read more about what the differences are between a staging server and a production server are here.

Why should we use Let’s Encrypt?

Let’s encrypt makes it a lot easier and cheaper for anyone who wants to get a TLS certificate. Not only is the installation super easy, you will also get an email when the certificate is about to expire.

Issue a certificate

To issue a certificate, we can use an ACME (Automated Certificate Management Environment) server.

Let’s Encrypt uses the ACME protocol to verify that you control a given domain name and to issue you a certificate.

We can use the example file here to create a it.

Create a new file called clusterissuer.yaml and paste in the following:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    # You must replace this email address with your own.
    # Let's Encrypt will use this to contact you about expiring
    # certificates, and issues related to your account.
    # Replace the EMAIL-ADDRESS placeholder with the correct email account
    email: EMAIL-ADDRESS
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-staging
    # Add a single challenge solver, HTTP01 using nginx
    solvers:
    - http01:
        ingress:
          class: nginx

We use the staging server, which is usually used for testing purpose.
letsencrypt-staging is a Kubernetes Secret to store the ACME account’s private key.
The email address specified is needed to register the certificate.
HTTP01 and DNS01 are two different challenges that Cert Manager uses to verify that you are the owner of your domain.

Apply the configuration with kubectl apply -f clusterissuer.yaml

clusterissuer.cert-manager.io/letsencrypt-staging created

To view the ClusterIssuers available in your cluster, run the following command: kubectl get clusterissuer

NAME                  READY   AGE
letsencrypt-staging   True    5s

CertManager will now ensure that the certificates are valid and up to date, and attempt to renew certificates at a configured time before expiry.

That’s it for this post.

In the next post, we will create a demo application that exposes a service. After that, we will deploy a Nginx Ingress Controller, which will be the access point for HTTP and HTTPS traffic to the backend services running in our Kubernetes cluster.