RabbitMQ TLS/SSL Configuration

Peer Verification

As described in https://www.rabbitmq.com/ssl.html the operator can specify TLS/SSL configuration that changes a RabbitMQ server's behavior when it comes to SSL/TLS connections.

In particular the options rabbitmq.ssl.verify and rabbitmq.ssl.fail_if_no_peer_cert can be set. The settings' meaning is described in https://www.rabbitmq.com/ssl.html#peer-verification. E.g. set rabbitmq.ssl.verify to value verify_peer and rabbitmq.ssl.fail_if_no_peer_cert to value true in order for a RabbitMQ server to demand a TLS certificate from any client connecting. You can also enable it for existing instances with cf update-service [INSTANCE_NAME] -c '{"fail_if_no_peer_cert": true, "verify":"verify_peer"}'. In addition, this certificate must have been signed by a certifcate authority that the RabbitMQ server trusts.

Certificate Rotation

If you create a service instance with a SSL plan, the instance will generate a self-signed certificate for it. To implement a signed CA, please follow this guide: Common TLS Configuration.

If you have running instances with a self-signed certificate and change the SPI to use a signed CA, you might want to update the old ones.

While creating or updating a service instance, the CertGenerator checks, if the certificates are valid or not.

If they are valid, the (re)generation will be skipped and it will still use the existing one.

30 days before the certificate gets invalid, it can be rotated by updating the service instance.

To bypass the 30 days restriction and force the instance to update the certificate, you can use the user parameter force_certificate_rotation to force the re(generation) while using update-service.

For example:

cf update-service my-rabbitmq -c '{"force_certificate_rotation": true}'