TLS authentication
Zenoh supports TLS as a transport protocol. +
TLS authentication
Zenoh supports TLS as a transport protocol. TLS can be configured in two ways:
server side authentication: clients validate the server TLS certificate but not the other way around, that is, the same way of operating on the web where the web browsers validate the identity of the server via means of the TLS certificate.
mutual authentication (mTLS): where both server-side and client-side authentication is required.
The configuration of TLS certificates is done via a configuration file.
Client configuration
The field root_ca_certificate is used to specify the path to the certificate used to authenticate the TLS server.
It’s important to note that if the field is not specified then the default behaviour is to load the root certificates provided by Mozilla’s CA for use with webpki.
However, if we manage our own certificates, we need to specify the root certificate. Suppose we generated the certificate using MiniCA as explained below, then the configuration file for a client would be:
{
/// The node's mode (router, peer or client)
@@ -98,6 +98,37 @@
}
}
}
+Close on certificate expiration
Starting with Zenoh v1.0.3, TLS and QUIC links can be closed when the remote certificate chain expires: the configured local instance will monitor the expiration time of the first expiring certificate in the remote instance’s certificate chain, and will disconnect the link when said time is reached.
This behavior can be enabled via the zenoh config file, by setting the field close_link_on_expiration to true. This is valid for both TLS clients and servers.
Client configuration
Below is an example config for a TLS client with certificate expiration monitoring. mTLS-related config fields can also be added if required.
{
+ "mode": "client",
+ "connect": {
+ "endpoints": ["tls/localhost:7447"]
+ },
+ "transport": {
+ "link": {
+ "tls": {
+ "root_ca_certificate": "/home/user/server/minica.pem",
+ "close_link_on_expiration": true
+ }
+ }
+ }
+}
+Listener configuration
Note that certificate expiration can only be monitored by a TLS listener when mTLS is enabled, since without mTLS a client does not need certificates to connect. Below is an example config for a router acting as TLS server with certificate expiration monitoring.
{
+ "mode": "router",
+ "listen": {
+ "endpoints": ["tls/localhost:7447"]
+ },
+ "transport": {
+ "link": {
+ "tls": {
+ "root_ca_certificate": "/home/user/client/minica.pem",
+ "listen_private_key": "/home/user/server/localhost/key.pem",
+ "listen_certificate": "/home/user/server/localhost/cert.pem",
+ "enable_mtls": true,
+ "close_link_on_expiration": true
+ }
+ }
+ }
+}
Testing the TLS transport
Let’s assume a scenario with one Zenoh router and two clients connected to it: one publisher and one subscriber.
The first thing to do is to run the router passing its configuration, i.e. router.json5:
$ zenohd -c router.json5
Then, let’s start the subscriber in client mode passing its configuration, i.e. client.json5:
$ z_sub -c client.json5
Lastly, let’s start the publisher in client mode passing its configuration, i.e. client.json5:
$ z_pub -c client.json5