Configure Mosquitto Bridge With SSL Encryption

It is very likely that a bridged connection between two brokers will be encrypted.

The Mosquitto broker (server) provides two methods of using SSL encryption on a bridged connection

  • Certificate encryption
  • PSK encryption

In this tutorial we will be configuring a secure bridged connection using both methods.

If you are new to certificates then you should read this tutorial on SSL encryption and certificates before continuing.

Broker Setup Overview

in this tutorial we will bridge topics on broker 1 to broker 2.


Broker 1 will be configured as bridge and is effectively an SSL client.

broker 2 will operate as a normal broker, and will not require any configuration for bridging. It will act as an SSL server.

Generally locally connected clients will use the standard port 1883 and not use encryption as shown in the diagram below:


SSL Encryption Using Certificates

Broker 2 needs to be configured as an SSL server and require encryption. I’ve chosen to use port 8883.

Notice the configuration is for an extra listener, and not for a bridge.

Here is the relevant part of the config file on broker 2 showing the SSL settings.


Now broker1 needs to be configured as a bridge.

The setup is almost identical to a normal bridge connection except we need to add a line for the CA file and also change from using an IP address ( to a name (ws4).

This is because my server key on broker 2 was generated with the name ws4. See the Mosquitto ssl tutorial for details.

Here is the bridging part of the config file:


Note: No server key is needed on broker 1 as it is functioning as an SSL client.


The easiest way of testing is to create an error which you can easily do by commenting out the encryption setting on broker 1

You should get an SSL error on broker 1

PSK Encryption Overview

The mosquitto broker supports PSK encryption which can be used instead of certificate based encryption.

In cryptography, a pre-shared key (PSK) is a shared secret which was previously shared between the two parties using some secure channel before it needs to be used. –Wiki

This is the same type of encryption used on Wi-fi Networks.

The key used in Mosquitto is restricted to hexi decimal numbers i.e 0-9,A,B,C,D,E,F

You can generate the key using online key generators, random number generators or just make one up.

For testing purposes it is easier to make one up.

For real world deployments a security policy would need to be created and used.

Note: PSK encryption uses SSL just like certificate based encryption.

PSK encryption isn’t supported on the Paho Python client, and so cannot be used to encrypt a client broker connection.

Configuring PSK on a Mosquitto Bridge Connection

Using the same setup as before. Broker1 is configured as a bridge and broker2 is a normal broker.

There are two settings that you need to add to broker2

  • psk_hint
  • psk_file

The psk_hint option is very important as this is what tells the broker to use PSK.

The actual value that you enter doesn’t appear important for mosquitto but may be in other PSK implementations.

There can only be one psk_file entry.

Below is sample configuration file:


The contents of the PSK file are shown below:

Note the above file is for two PSK connections our current connection will use bridge1.

Broker1 is the bridge and here is the configuration:

bridge-broker-ssl-confThe important entries are the bridge identity bridge1 which matches the bridge identity in the PSK file on broker2.

The bridge_psk value matches the one in the PSK file on broker2.

Multiple Bridge Connection Examples

We will now examine two configuration scenarios. We will use PSK for SSL but the same applies if using certificates.

The diagram below depicts two bridge connections. This would be typical central broker with branch offices configuration

configure-multiple-bridged -connections

Broker2 needs no configuration changes to support multiple bridged connections for both certificate based and PSK.

However it may need additional entries in the PSK file. The psk file shown previously is already configured for two connections.

The configuration on broker 1 (bridge 1) is that shown previously and needs no changes

The configuration file for B3 (bridge2) is shown below:


Multiple Bridged Connection -Example2

This time we will configure the bridge to have multiple bridged connections. This would be a branch office to central broker with redundancy and is depicted in the diagram below:


Broker 1 Configuration

We would usually use the same port for each bridge so we only need a single listener.

Each bridge connection starts with the connection name.

Below we see two connections called bridge-01 and bridge-02.

Here is the configuration file


The configuration files for brokers 2 and 3 would look similar to the one below.


Testing The Connections

When you connect the bridge there is actually no indication that a secure connection is being used provided that the configuration is OK.

However you will get an indication if you have a configuration problem.

The screen shot below show the connection problem that I caused by using a mismatched key for connection bridge-02.


Video- How to Create a Secure Bridged Connection on Mosquitto

Questions and Answers

Q- What is the PSK Hint?

A- See this stackoverflow response

Q- Is PSK less secure than using a certificate?

A- Probably yes but opinions seem to vary- see here. PSK is however much easier to implement than certificates.


Related Tutorials

Please rate? And use Comments to let me know more
[Total: 3   Average: 4.7/5]


  1. Your MQTT videos and posts are really great Steve.. !Thank you for such wonderful content…

    I tried to connect from the local system to the virtual machine in the cloud using bridge concept. I have the TLS encryption in the local system broker and i have included the configuration settings for bridge in the VM broker as ,

    # External MQTT Broker
    connection vm
    bridge_cafile /etc/mosquitto/certs/ca.crts
    topic # in
    topic # out

    But i cant send the data over the bridge. Is it because of my personal local pc IP is not accessible in the cloud VM? or is there any mistake i am making?
    while running commands in the terminal, i am opening two terminals in the local pc for one sub and one pub. Then which ip need to be give there? In the cloud vm part also , in the terminal which ip i have to mention?
    Please reply . I am stuck with this.

      1. Is there any other method instead of bridge concept to send data directly from device to cloud using mqtt? Also, one more doubt. Is it because of this local ip issue that I am unable to connect ? I have also tried to set up the bridge with two virtual machine instance in the cloud as a testing purpose. But its also not working.Data is not being published in the instance terminal after giving sub in the first instance. Looking forward to hear from you.
        Thanks and regards,

          1. Thank you for sparing your time.

            Are you speaking about cloud pub sub? I am new to this cloud and mqtt so please clear this.

            I sent data with google api and pub sub. But i want mqtt broker in my system to connect to cloud. That is what i am trying to do. Do it need bridge ?

            Thanks and regards,

          2. There are a number of cloud based brokers you can use.
            Brokers like
            are for testing and not production
            other like are for production. Cloudmqtt don’t any longer provide a free plan but they did when I wrote this tutorial.
            However does so you could try that.
            There is a list of public broker in this tutorial

  2. Hello Steve,
    I am desperately trying to get my setup up and running. Here is what I want to achieve:
    I have a webhosted vServer running the main broker; it is configured to require a certificate.
    Then I have three RPi zero hosted bridges from my home, office and workshop, each with its own client certificate. Those bridges receive unencrypted data from several devices, mostly tasmota.

    Now here’s the funny thing: If I run mosquitto „manually“ as user pi, it connects successfully, sending up and down. The main service, probably run as root, fails. Can you please do a post about users and permissions? Do I need to generate the certificates on the machine where they are actually used?

    Best wishes and stay safe in these hard times.


    1. Hi
      Mosquitto runs as the user mosquitto and doesn’t require root permissions.
      I assume you are talking about the central broker> I would check that mosquitto user has permissions to read the conf and ca files as it is probably a permission issue.

  3. your articals are very very good and it helps me for upgrading my skills but there is so many many problems when implementing so it is best to provide step by step implementation on pc and solve many problems occurs it will help a lot

  4. For a bridge connection using SSL I added a bridge.conf file using capath. I have Let’s Encypt as a CA.
    connection bridge-01
    bridge_capath /etc/ssl/certs/
    remote_username mqttu
    remote_password mqttpw
    topic home/# out 0

  5. Hi, you have great tutorials for Mosquitto. Your tutorials have help me to configure my brokers in the right way. Thank you so much.

    I have a problem with this tutorial, I already make a connection between two mosquitto brokers without encryption and it works well. I had some troubles making one of the brokers to use encryption but I finally get it to work using your tutorial. I can connect to that broker with a client using the ca.crt file and it works well. But I can’t make a bridge between my two brokers using the ca.crt file.

    The log is showing an error every time it tries to connect:
    OpenSSL Error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number.

    Is there a problem whith my tls version from the config file? Is there a problem if one of my brokers is local and the other one has a domain?

    Hope you can help me out.


    1. Looks like a problem with the .conf file. Can you send me the .conf file for the client side of the bridge or both if you are not sure.
      Use the ask-steve page on the site to send it

    2. Hello, thanks for youre awesome content Steve!

      Im using Node-red to send random values across a bridge and subscribe to them on the other side but getting an error.

      Error: OpenSSL Error: error:xxxxx:SSL routines:SSL3_GET_RECORD:wrong version number

      It appears I am getting the same error as others but have narrowed it down to the ‘local’ MQTT subscribe nodes attempting to subscribe to data from broker 2. Im suspecting the error arises as the local subscribe node doesnt share the same PSK/TLS. My setup on two node-red instances is:

      local MQTT pub node ——-> Broker 1 Broker 2 ——> local MQTT sub node

      Do you know of any way for the local MQTT subscribe node to subscribe to the bridged broker without needing TLS to subscribe to broker 2? Assuming that is the problem..

      Broker 1

      listener 1883
      listener 8883
      log_type all
      connection bridge-01
      bridge_identity bridge1
      bridge_psk dd230d622
      topic # both 0

      Broker 2:

      port 1883
      listener 8883
      log_type all
      psk_hint initiate
      psk_file /mosquitto/psk.txt


      1. Hi
        From what I can see you aren’t using ssl but a preshared key for the bridge.
        Also you have the default port active on both brokers which should mean you don’t need to use ssl on the clients.
        In node-red if you want it to subscribe using ssl and also not using ssl you need to create and configure to mqtt nodes.
        Does that make sense

  6. Hi,

    First of all, well done for this tutorial.

    I tried the SSL configuration on my main broker and it works well.
    I can publish with mosquitto_pub from the same PC or from another one on the same network.

    Unfortunately, when I want to launch a bridge from the other PC I have this problem:
    “ssl handshake failure” (on the main broker)

    I’m using the same PC and the same ca.crt as with the mosquitto_pub so I don’t understand how the handshake could fail.

    Did you encounteredthis problem before?

    1. Hi
      I would suspect the configuration on the new broker. The second broker is acting like a client for the first broker so it is set up similar to a client as regards ssl.
      If you still have probs send me a copy of the config file on each broker and I’ll take a look.(

Leave a Reply

Your email address will not be published. Required fields are marked *