diff --git a/docs/manual/tls/index.html b/docs/manual/tls/index.html index 5a221ffa..ebe8b435 100644 --- a/docs/manual/tls/index.html +++ b/docs/manual/tls/index.html @@ -1,6 +1,6 @@ TLS authentication · Zenoh - pub/sub, geo distributed storage, query

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)
@@ -45,7 +45,14 @@
   }
 }
 

When using such configuration, the peer will use the provided root_ca_certificate to authenticate the TLS certificate of the peer it is connecting to. -At the same time, the peer will use the provided server_private_key and server_certificate for initiating incoming TLS sessions from other peers.

Let’s assume that the above configurations are then saved with the name peer.json5.


Mutual authentication (mTLS)

In order to enable mutual authentication, we’ll need two sets of keys and certificates, one for the “server” and one for the “client”. These sets of keys and certificates can be generated as explained in the appendix section below. +At the same time, the peer will use the provided server_private_key and server_certificate for initiating incoming TLS sessions from other peers.

Let’s assume that the above configurations are then saved with the name peer.json5.


TLS with Scouting ⚠️

Zenoh provides a scouting mechanism that allows peers to discover other neighboring peers automatically.

By default, this feature is enabled and attempts to establish connections with other peers using all Zenoh-supported protocols (not just TLS).

To ensure that all connections are established using TLS, you can configure the protocols filter as shown below:

{
+  "transport": {
+    "link": {
+      "protocols": ["tls"]
+    }
+  }
+}
+

The protocols configuration field specifies which protocols Zenoh should whitelist for accepting and opening sessions. If this field is not configured, Zenoh will automatically whitelist all supported protocols.


Mutual authentication (mTLS)

In order to enable mutual authentication, we’ll need two sets of keys and certificates, one for the “server” and one for the “client”. These sets of keys and certificates can be generated as explained in the appendix section below. Let’s suppose we are storing them under $home/user/ with the following files and folders structure:

user
 ├── client
 │   ├── localhost