Get a wildcard certificate for rancher web UI.

In this blog I will show you how to obtain an official signed wildcard certificate to be in rancher and kubernetes clusters.

When it comes to access a web interfaces e.g. rancher management web interface, we often face the issue that the self signed tls certificate is not trusted by your web browser of choice. The reason is because the certificate your browser received is not signed by an official CA "Certificate Authority". Therefore the web site is untrusted and you received the warning.

What we need is an official registered domain name and a CA that signed our tls certificates. offers domain names that are really affordable even for demo and labs environments. offers free and automated tls certificate signing service.

Withe this two organizations I can start creating my wildcard tls certificates for my kubernetes and rancher deployments.

The Steps:

step one:

Install certbot on your Linux system.

On SLES15SP2 or higher you can simply run below command to install certbot.

zypper install -y certbot

After certbot is installed use certbot to obtain the signed certificates from letsencrypt by using below command as an example:

sudo certbot certonly --server --manual --preferred-challenges dns -d *

As you can see I use DNS as challenge type simply because I don't have a web hosting for my required domain.

One the above certbot command is executed it will contact the letsencrypt server api and start the process. For the DNS challenge certbot will output the TXT record name and value that you need to add on namecheap - your DNS administration - place.

Create a new record type of "TXT Record" and for host enter _acme-challenge and for the value the given value you find in the certbot output.

After you saved the new record at you should verify if the TXT record can be queried by testing with:

Enter your subdomain as in my example:

and select TXT lookup to query.

The result should show the same value as you received from the certbot utility. If this is the case go back to your certbot output to continue by press enter.

Letsencrypt will query also the TXT record value and if a match is found the certificates will be issued.

The output of the certificate files will be stored on the system you ran certbot in a directory named by your domain name.


Step two:

Now we have the certificates (CA + intermediate CA + wildcard certificate) including private key for our wildcard domain.

Use this command to view the wildcard certificate:

sudo openssl x509 -in cert1.pem -noout -text

Use this command to view the CA certificate:

sudo openssl x509 -in chain1.pem -noout -text

Use this command to verify if the certificate is signed with the given CA file:

sudo openssl verify -CAfile chain1.pem cert1.pem

The output should be OK.

To renew the certificates you simply run 'certbot renew' in the future to handle the certificate renewals manually.

Step three:

Now we want to replace or add the new official signed tls certificates into our rancher and kubernetes deployment.

I use kubectl to replace the existing self signed rancher certs. First I delete the existing secret in the namespace cattle-system and create a new secret with the same name as before.

The fullchain1.pem file holds CA + intermediate + wildcard certificates.

kubectl delete secret tls-rancher-ingress -n cattle-system

kubectl create secret tls tls-rancher-ingress --cert fullchain1.pem --key privkey1.pem -n cattle-system

After I created the new secret if I open the web interface of rancher web UI again the https connection is established without any browser warnings. Well done.

So now I could use above steps to repeatedly create secret for other apps that need https tls certificates.

To summarize:

This way of obtaining tls certificates for kubernetes is not the standard way which uses cert-manager that is usually deployed within your kubernetes cluster. But my approach shows how to obtain a wildcard certificate that is for labs environment often useful.

Of course we should not forget to renew our certificates every 90 days as this is per default defined by letsencrypt.


EveryWare AG - for providing the hosting resources

Diese Webseite verwendet Cookies. Durch die weitere Nutzung stimmen Sie der Verwendung von Cookies zu.