Additional Subject Alternative Name (SAN) attributes required by RabbitmqCluster operator

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

swisstch.com

I ran this command:
not applicable

It produced this output:
not applicable

My web server is (include version):
NGINX 1.19

The operating system my web server runs on is (include version):
ubuntu 20.04

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):
yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 1.19.0

Background info:
Using certbot and let's encrypt (thank you!) I have successfully created SSL certificates that I have used for connecting to my local rabbitmq deployment.This works fine!

What I want to achieve:
I want to run a RabbitmqCluster operator in a local kubernetes cluster that uses one way TLS encryption.

The problem:
According to the RabbitmqCluster operator TLS documentation, I need to enrich the certificate's Subject Alternative Name (SAN) with multiple attributes:

The certificate's Subject Alternative Name (SAN) must contain at least the following attributes: *.<RabbitMQ cluster name>-nodes.<namespace>.svc.<K8s cluster domain name> <RabbitMQ cluster name>.<namespace>.svc.<K8s cluster domain name>

If wildcards are not permitted, the certificate must provide a SAN attribute for each RabbitMQ node in the RabbitMQ cluster. For example, if you deploy a 3-node RabbitMQ cluster named myrabbit in namespace mynamespace with the default Kubernetes cluster domain cluster.local, the SAN must include at least the following attributes: myrabbit-server-0.myrabbit-nodes.mynamespace.svc.cluster.local myrabbit-server-1.myrabbit-nodes.mynamespace.svc.cluster.local myrabbit-server-2.myrabbit-nodes.mynamespace.svc.cluster.local myrabbit.mynamespace.svc.cluster.local

Furthermore:

Note that the last SAN attribute is the client service DNS name. Depending on the service type used (spec.service.type), further SAN attributes may be required. For example, if using service type NodePort, the SAN must include the external IP address of each Kubernetes node.

Question:
Is it possible to create certificates that have such SAN attributes using let's encrypt?
If yes, could you please point me to the docs/examples on how to do it?

If where you showed ".local" is actually ".local" and not a real domain name, then the answer is NO.
There is no global CA that can issue a cert for such a TLD.
If you did mean a real domain name, then all ACME clients can be used to obtain a cert with multiple valid FQDNs on it (all of which will be included in the SAN field automatically) via HTTP authentication.
If you did mean a real domain name and you want to get a wildcard cert, then the most important part is being able to fully automate the renewal process - which requires the DNS Service Provider (DSP) to support DNS zone updates via API.

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.