Enable TLS

To enable TLS support, first generate the certificates as described in the RabbitMQ documentation for SSL certificate generation.

Once the certificates are generated, you have two alternatives:

• Create a secret with the certificates and associate the secret when deploying the chart
• Include the certificates in the values.yaml file when deploying the chart

To create and use a secret with the certificates, follow these steps:

• Execute the following command to create the secret, replacing the example paths shown with the correct paths to your certificates:

    $ kubectl create secret generic rabbitmq-certificates --from-file=./ca.crt --from-file=./tls.crt --from-file=./tls.key
  

• Deploy the RabbitMQ chart setting the parameters below:

    tls.enabled=true
    tls.existingSecret=rabbitmq-certificates
  

Alternatively, include the certificates in the values.yaml file when deploying the chart, as shown in the example YAML configuration below:

auth:
  enabled: true
  caCertificate: |-
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  serverCertificate: |-
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  serverKey: |-
    -----BEGIN RSA PRIVATE KEY-----
    ....
    -----END RSA PRIVATE KEY-----

Set the auth.tls.failIfNoPeerCert parameter to false to allow a TLS connection if the client fails to provide a certificate.

Set the auth.tls.sslOptionsVerify to verify_peer to force a node to perform peer verification. When set to verify_none, peer verification will be disabled and certificate exchange won’t be performed.

If using Cert-manager to provision Let’s Encrypt certificates, the tls.crt key in the generated TLS secret will contain the full certificate chain. Depending on the version of Cert-manager in use, this could either be an empty ca.crt key, or none at all. In order to instruct RabbitMQ to look for the CA certificate within the primary certificate, the auth.tls.existingSecretFullChain parameter can be set to true.