Kubernetes: Same Domain SSL with DNS Verification using Let’s Encrypt

Use the Cert-Manager ACME DNS01 solver to generate SSL certificates for the same domain across multiple Kubernetes clusters

Alexander Beattie
QuarkWorks, Inc.
3 min readApr 14, 2022

--

The Problem

Imagine that you own the domain, example.com. You want to setup 2 Kubernetes clusters using the Digital Ocean Nginx Ingress setup guide. You choose to use the subdomain dev.example.com for the development cluster and the root domain example.com for the production cluster. When creating the Let’s Encrypt ClusterIssuer, you elect to use the DNS01 solver instead of the HTTP01 solver.

Setting up the development cluster goes well and now you move to the production cluster. You follow the same procedure as the development cluster, but encounter problems with the ClusterIssuer. You are wondering:

How do I use the Cert-Manager DNS01 solver to generate SSL certificates for the same domain name across multiple Kubernetes clusters?

Until now, the answer required consulting this troubleshooting guide, digging through nested Kubernetes logs, and an internet search rabbit hole.

The Solution

Cert-Manager provides guidance on reusing an ACME Account. The key is to set the field disableAccountKeyGeneration: true, which is shown in the ClusterIssuer below. It is important that you do not set this field for the cluster you use to generate the key, otherwise, you won’t have a key to copy! You cannot apply this ClusterIssuer to your production cluster yet because it will not generate the privateKeySecretRef. The secret needs to exist in this cluster or the ClusterIssuer will be stuck in a retry state and never become ready.

To solve this problem, the secret needs to be copied from the development cluster and imported into the production cluster. The procedure below is slightly modified from this Stack Overflow Post. This method breaks the procedure into two parts to ensure the Kubernetes context is explicitly set for each operation.

This creates a copy of your development cluster’s secret (base64 encoded) locally. The resultant yaml file should look something like the one below (with your fields filled in).

Finally, you can change contexts to your production cluster and apply the secret!

Conclusion

You can now continue setting up your production cluster! The ClusterIssuers for both clusters will now utilize the same secret and will be able to issue certificates for the root domain and any subdomains you choose. This same procedure can be replicated to utilize the same domain for as many clusters as you wish to create.

If you have other questions, you can also get in touch with us on Discord.

Subscribe to our newsletter for more updates on what we’re doing next!

--

--

Alexander Beattie
QuarkWorks, Inc.

Over the past four years I have lived in three countries and navigated the challenges of working, living, studying, and traveling during a global pandemic.