...

NOTE - These instructions were taken mostly from some random blog post: https://itnext.io/automated-tls-with-cert-manager-and-letsencrypt-for-kubernetes-7daaa5e0cae4

Prerequisites

• A 1+ node Kubernetes cluster
• Helm and Tiller installed on Kubernetes cluster
• NGINX Ingress Controller running in Kubernetes cluster
• A DNS record setup to point at the IP of the NGINX controller

Let's Encrypt: Staging vs Production

Before we get into any of this, I'd like to point out that we used the staging server for this example because it is much more forgiving about how often you can request a new certificate.

...

For more information on the rate limits in place on LetsEncrypt, see https://letsencrypt.org/docs/rate-limits/

Step 1: Install cert-manager via helm

Create cert-manager-values.yaml on disk:

...

$ kubectl logs -f deploy/cert-manager -n kube-system

Step 2: Create a ClusterIssuer

An Issuer or ClusterIssuer represents the CA that will distribute certificates for your ingress rules - in our case, this is LetsEncrypt.

...

If you see all of the above, then you should be ready to issue some certificates!

Step 3: Annotate Your Ingress

In the startup logs for the cert-manager, you may have seen info message about missing annotations, for example:

...

NOTE: The rest of the ingress fields should be able to stay the same. Only those rules with the annotation will be affected by cert-manager, so only add it to ingress rules for which you'd like for it to control/renew TLS.

Step 4: Issue a Certificate

Create dev.cis.ndslabs.org-certificate.yaml on disk:

...

NOTE: I suspect that this is required, but did not attempt otherwise - as you can see above, I did explicitly specify a namespace here to make sure my certificate/secret was created in the same namespace as my ingress rule. I have no idea how it would otherwise figure out which namespaces needs which secrets.

What should you see? (Console)

That's it! If everything worked correctly, you should see some successful log messages in the cert-manager logs:

...

$ kubectl get certificate,secret -n cis-dev
NAME                                            AGE
certificate.certmanager.k8s.io/cis-tls-secret   5m

NAME                         TYPE                                  DATA      AGE
secret/cis-tls-secret        kubernetes.io/tls                     2         2m
secret/default-token-p2sxz   kubernetes.io/service-account-token   3         5d

What should your users see? (Browser)

Navigating to your ingress rule, you should see that you now have a LetsEncrypt TLS certificate.

...

This will show you who issued the certificate, and can also shed light on who is the owner of a particular domain.

Certificate Differences: LetsEncrypt staging vs production

If you are using the LetsEncrypt staging server, the issued certificate will still appear Not Secure at first glance. Examining it, you should see that it was Issued by: Fake LE Intermediate X1

...

For more information on the differences between staging and production on LetsEncrypt, see https://letsencrypt.org/docs/rate-limits/

Migrating from Staging to Production

If you've made it this far using staging, then you are probably ready to start issuing real certificates - simply change https://acme-staging-v02.api.letsencrypt.org/directory above to https://acme-v02.api.letsencrypt.org/directory

...