Regenerate SSL certificates when updating hostname

[ShurikAg]

I have one subdomain configured for my host and mapping (for testing). Everything worked created there.
So, I decided to switch to the real prod URL: apii.priz.guru -> api.priz.guru

I am using the automated process, so once changes were pushed, I switch the DNS to point to Ambassador. It was switched, but now the certificate is invalid. How do I force regenerate the certificate?

[ShurikAg]

As I understand, it looks like I need to create a wildcard certificate following these instructions.

Also, looking back at the details of how to configure it, it looks like these instructions are built for domains managed in DO.
In our case our domains are in CloudFlare (and it's important to leave them there).

Where can I find information of how to correctly configure wildcard cert with automation?

[v-ctiutiu]

Hi @ShurikAg

I hope you don't mind, but this looks more like a Q&A session to me, so it makes sense to convert it to a discussion.

Starter Kit is focused around DigitalOcean in general, for obvious reasons. On the other hand, it's a starting point or something to build upon, hence it doesn't cover every aspect or every detail of a production system.

Getting back to your question about regenerating certificates - if your subdomains change often (or dynamic), then a wildcard certificate is more appropriate (as you already discovered). On the other hand, if your subdomains are static or fixed, then you need to regenerate the certificate, obviously.

A certificate is tightly coupled to a hostname, so if the hostname changes then obviously you need to regenerate the certificate. A wildcard certificate is more flexible, but it is also too permissive because the private key is shared across multiple systems. The latter can imply security risks.

We do not cover a Cloudflare setup using Cert-Manager, but you can follow the guide presented in the official documentation. Should be very similar to the one used for DigitalOcean.

Just to summarize, the steps are as follows:

1. First, you create a Kubernetes Secret, containing your Cloudflare API token (the token must be generated using the Cloudflare web console).
2. Then, you create an Issuer CRD, referencing the secret created earlier, containing the API token for Cloudflare.
3. Finally, you configure a Certificate CRD as usual, and reference the Issuer CRD that you created earlier for Cloudflare.

After creating the above Kubernetes resources, the Certficate CRD will use the Issuer CRD to perform the DNS-01 challenge via the Cloudflare API and obtain a certificate for you. So, things should go as usual as in case of the DigitalOcean example. This is one of the nicest things about Cert-Manager - everything is decoupled and has a nice interface.

What's different when compared to the original tutorial created for DigitalOcean? It's only the Issuer CRD setup (Cloudflare specific), rest goes the same and everything should be plug and play.

How about Flux CD? Well, you need the above manifests (Cloudflare Kubernetes Secret, Issuer and Certificate) placed in the sync directory from your Git repository used by Flux CD. Then, Flux CD should take care of the rest. For sealing Kubernetes secrets, I would recommend following the Sealed Secrets tutorial from the Starter Kit, to store the manifests encrypted in your Git repository.

Hope it helps.