|
1 | 1 | # Mutual TLS Peer Verification (Mutual TLS Authentication, mTLS) Example |
2 | 2 |
|
| 3 | +This example is an extension of the [basic TLS example](../tls) and |
| 4 | +adds mutual peer verification ("mTLS") in addition to enabling TLS for client connections. |
| 5 | + |
| 6 | +It is recommended to get familiar at least with the basics of [TLS setup in RabbitMQ](https://www.rabbitmq.com/ssl.html) |
| 7 | +before going over this example, in particular with [how TLS peer verification works](https://www.rabbitmq.com/ssl.html#peer-verification). |
| 8 | + |
| 9 | +TLS has multiple moving parts and concepts involved. Successful TLS connections |
| 10 | +require sufficient and compatible configuration on **both server and client sides**, and understanding the terminology |
| 11 | +used would help a lot. |
| 12 | + |
| 13 | + |
| 14 | +## Specifying Server Certificate and Key |
| 15 | + |
3 | 16 | Both RabbitMQ and clients can [verify each other's certificate chain](https://www.rabbitmq.com/ssl.html#peer-verification) for |
4 | 17 | trust. When such verification is performed on both ends, the practice is sometimes |
5 | 18 | referred to "mutual TLS authentication" or simply "mTLS". This example |
6 | 19 | focuses on enabling mutual peer verifications for client connections (as opposed to [node-to-node communication](../mtls-inter-node)). |
7 | 20 |
|
8 | | -For clients to perform peer verification of RabbitMQ nodes, they must be provided the necessary TLS certificates and private keys in Secret objects. |
9 | | -You must set `.spec.tls.secretName` to the name of a secret containing the RabbitMQ server's TLS certificate and key, |
10 | | -and set `spec.tls.caSecretName` to the name of a secret containing the certificate of the Certificate Authority which |
| 21 | +For clients to perform peer verification of RabbitMQ nodes, they must be provided the necessary TLS [certificates and private keys](https://www.rabbitmq.com/ssl.html#certificates-and-keys) in Secret objects. |
| 22 | +It is necessary to set `.spec.tls.secretName` to the name of a secret containing the RabbitMQ server's TLS certificate and key, |
| 23 | +In addition, set `spec.tls.caSecretName` to the name of a secret containing the certificate of the [Certificate Authority](https://www.rabbitmq.com/ssl.html#certificates-and-keys) which |
11 | 24 | has signed the certificates of your RabbitMQ clients. |
12 | 25 |
|
13 | 26 | First, you need to create the Secret which will contain the public certificate and private key to be used for TLS on the RabbitMQ nodes. |
@@ -35,13 +48,13 @@ Once the secrets exist, you can deploy this example as follows: |
35 | 48 | kubectl apply -f rabbitmq.yaml |
36 | 49 | ``` |
37 | 50 |
|
38 | | -## Peer verification |
| 51 | +## Enabling Mutual Peer Verification ("mTLS") |
39 | 52 |
|
40 | | -With mTLS enabled, any clients that attempt to connect to the RabbitMQ server that present a TLS certificate will have that |
| 53 | +With client peer verification enabled, any clients that attempt to connect to the RabbitMQ server that present a TLS certificate will have that |
41 | 54 | certificate verified against the CA certificate provided in `spec.tls.caSecretName`. This is because the RabbitMQ configuration option |
42 | 55 | `ssl_options.verify_peer` is enabled with mTLS by default. |
43 | 56 |
|
44 | | -If you require RabbitMQ to reject clients that do not present certificates by enabling `ssl.options.fail_if_no_peer_cert`, |
| 57 | +To reject client connections that do not present a certificate, enable `ssl.options.fail_if_no_peer_cert`, |
45 | 58 | this can be done by editing the RabbitmqCluster object's spec to include the field in the `additionalConfig`: |
46 | 59 |
|
47 | 60 | ```yaml |
|
0 commit comments