Skip to content

Commit 71d24f6

Browse files
Mutual peer verification example: README edits
1 parent e6b6830 commit 71d24f6

File tree

1 file changed

+19
-6
lines changed

1 file changed

+19
-6
lines changed

docs/examples/mtls/README.md

Lines changed: 19 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,26 @@
11
# Mutual TLS Peer Verification (Mutual TLS Authentication, mTLS) Example
22

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+
316
Both RabbitMQ and clients can [verify each other's certificate chain](https://www.rabbitmq.com/ssl.html#peer-verification) for
417
trust. When such verification is performed on both ends, the practice is sometimes
518
referred to "mutual TLS authentication" or simply "mTLS". This example
619
focuses on enabling mutual peer verifications for client connections (as opposed to [node-to-node communication](../mtls-inter-node)).
720

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
1124
has signed the certificates of your RabbitMQ clients.
1225

1326
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:
3548
kubectl apply -f rabbitmq.yaml
3649
```
3750

38-
## Peer verification
51+
## Enabling Mutual Peer Verification ("mTLS")
3952

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
4154
certificate verified against the CA certificate provided in `spec.tls.caSecretName`. This is because the RabbitMQ configuration option
4255
`ssl_options.verify_peer` is enabled with mTLS by default.
4356

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`,
4558
this can be done by editing the RabbitmqCluster object's spec to include the field in the `additionalConfig`:
4659

4760
```yaml

0 commit comments

Comments
 (0)