About Eclipse Mosquitto

Eclipse Mosquitto is an open-source MQTT broker supporting the MQTT protocol 5.0, 3.1.1, and 3.1. It supports authentication, certificates, and is small and easy to configure. It can also be used to create a redundant solution with the following configuration:

• There are two redundant application servers (physical or virtualized) - Windows or Linux.
• On both servers, D2000 Servers are running as a redundant application (Master/Standby).
• On both servers, Eclipse Mosquitto MQTT brokers are running, configured in TLS mode with a certificate signed by a certification authority. They are running without configuring message exchange between them, i.e., each of them is completely independent.
• D2000 Kom process has a configured TCP/IP-TCP Redundant line, with configured MQTT broker certificate verification, and with configured certificates. D2000 KOM is therefore connected to both MQTT brokers simultaneously.
• Other MQTT clients (PLC and other devices) are connected to at least one of the MQTT brokers (i.e., they allow you to configure 2 IP addresses of MQTT brokers to which they try to establish a connection alternately).
• TLS certificates signed by a certification authority are used to verify the identity of all clients.

This document provides an example of a basic configuration of the Eclipse Mosquitto MQTT broker.

Configuration file mosquitto.conf

The example shows the configuration on Windows; the paths on Linux OS need to be adjusted (the configuration file itself can be located, for example, in /etc/mosquitto/mosquitto.conf).

#MQTTS listener on port 8883
listener 8883
#broker certificate
certfile c:\Program Files (x86)\mosquitto\broker.crt
#broker private key
keyfile c:\Program Files (x86)\mosquitto\broker.key
#require valid certificates of clients
require_certificate true
#file with certificate authority's public key(s)
cafile c:\Program Files (x86)\mosquitto\caMQTT.crt
#use CN (Common Name) of client certificate as username (and ignore MQTT username+password)
use_identity_as_username true
#password file is not used for username/password verification (due to use_identity_as_username true)
#password_file pwfile
#acl file with defined access rights
acl_file c:\Program Files (x86)\mosquitto\myacl.conf

Note: It is also possible to authenticate MQTT clients based on name and password. In this case, the use of identity must be disabled and a password file must be defined:

use_identity_as_username false
password_file c:\Program Files (x86)\mosquitto\pwfile

In the pwfile file, you need to define usernames and passwords using the mosquitto_passwd utility. The first time you use it, you need to use the -c switch to create the file, but this is not necessary for subsequent uses. The -b parameter activates batch mode, which allows you to enter passwords on the command line:

mosquitto_passwd.exe -b -c pwfile myuser1 mypassword1
mosquitto_passwd.exe -b pwfile myuser2 mypassword2

Warning: If MQTT clients are authenticated based on name and password, and certificates are required, there is no defined binding between the user and the certificate. So if somebody were to obtain another user's certificate (and private key), they could use it to connect to the MQTT broker.

Configuration file myacl.conf

The configuration file contains rules for MQTT clients that define which MQTT topics they can read (subscribe to) and write to.

Example for simple MQTT clients:

• MQTT client with certificate containing Common Name=myPLC, publishing data with topic PLC1/out and receiving commands with topic PLC1/cmd
• MQTT client with certificate containing Common Name=myD2000, reading data with topic PLC1/out and sending commands with topic PLC1/cmd

#user without username: anonymous is forbidden, but just to make sure: deny everything
topic deny

#MQTT client myPLC: writes to PLC1/out, subscribes to PLC1/cmd
user myPLC
topic write PLC1/out
topic read PLC1/cmd

#MQTT client myD2000: reads from PLC1/out, writes to PLC1/cmd
user myD2000
topic read PLC1/out
topic write PLC1/cmd

Example for MQTT Sparkplug clients:

• MQTT Host Application with certificate containing Common Name=myHost, with Sparkplug Host ID=D2000komHA
• MQTT Edge Node with certificate containing Common Name=myEdge, with group_id=myGroup, with edge_node_id=myEdgeNode

#user without username: anonymous is forbidden, but just to make sure: deny everything
topic deny

#MQTT Edge Node: writes to DATA/BIRTH/DEATH for myGroup/myEdgeNode (and its subdevices), subscribes NCMD/DCMD and queries the state of Host Application
user myEdge
topic write spBv1.0/myGroup/NDATA/myEdgeNode/#
topic write spBv1.0/myGroup/DDATA/myEdgeNode/# 
topic write spBv1.0/myGroup/NBIRTH/myEdgeNode/#
topic write spBv1.0/myGroup/DBIRTH/myEdgeNode/# 
topic read spBv1.0/myGroup/NCMD/myEdgeNode/#
topic read spBv1.0/myGroup/DCMD/myEdgeNode/#
topic read spBv1.0/STATE/D2000komHA

#MQTT Host Application: reads/writes its STATE, reads everything (this might be more precisely specified based on topics above), writes commands for myEdgeNode (and its subdevices)
user myHost
topic readwrite spBv1.0/STATE/D2000komHA
topic read spBv1.0/#
topic write spBv1.0/myGroup/NCMD/myEdgeNodeNadpis 3
topic write spBv1.0/myGroup/DCMD/myEdgeNode/#

Generating and signing TLS certificates

To generate keys and TLS certificates and sign them, you must have the OpenSSL package installed. On Windows, you can use, for example, the Win32/Win64 OpenSSL Installation Project  (installed in c:\Program Files\OpenSSL-Win64\bin).

The following procedure describes how to create keys and TLS certificates for the MQTT broker, the MQTT client myPLC (PLC or other device), and the MQTT client myD2000 (D2000 KOM process).

1.1 Creating a certification authority

This step can be skipped if you already have an existing certification authority, or if someone else signs your certificates. The -days parameter specifies the validity period of the certificate. The -keyout parameter defines the name of the private key file (which must be protected from theft), and the -out parameter defines the name of the certificate (which must be published).

openssl req -new -x509 -days 1000 -extensions v3_ca -keyout caMQTT.key -out caMQTT.crt

When creating a key, you must enter a password to protect it.

1.2 Copying a Certification Authority Certificate

The certification authority certificate (caMQTT.crt) must be copied so that the D2000 KOM has access to it (the easiest way is to put it in the application directory) and set the path to it as the "Partner certificate" parameter (#APPDIR#\caMQTT.crt) in the TCP/IP-TCP Redundant line configuration.

The certification authority certificate (caMQTT.crt) must be copied to the MQTT broker so that the MQTT broker can use it to verify the validity of MQTT client certificates.

Note: In the case of redundant MQTT brokers and redundant D2000 application servers (and other MQTT clients), it is necessary to copy the certification authority certificate to all relevant servers!

2.1 Key creation and certificate signing request for the MQTT broker

This step must be repeated for each of the MQTT brokers.

Creating a key (2048 bits):

openssl genrsa -out broker.key 2048

Creating a certificate signing request (csr). Several parameters must be entered; the values given in the example must be modified. It is recommended that the CN (Common Name) match the name of the computer with the MQTT broker.

openssl req -out broker.csr -key broker.key -new        
    
        Country Name (2 letter code) [AU]:SK
        State or Province Name (full name) [Some-State]:Slovakia
        Locality Name (eg, city) []:Žilina
        Organization Name (eg, company) [Internet Widgits Pty Ltd]:Ipesoft
        Organizational Unit Name (eg, section) []:D2000
        Common Name (e.g. server FQDN or YOUR name) []:myserver
        Email Address []:ipesoft@ipesoft.sk
        
        Please enter the following 'extra' attributes
        to be sent with your certificate request
        A challenge password []:
        An optional company name []:

2.2 Creating a certificate for the MQTT broker

This step must be repeated for each of the MQTT brokers.

If you created a certification authority above, you are creating a certificate (signing a certificate signing request). Otherwise, you send the broker.csr file for signing to the appropriate certification authority (e.g., the company's IT department).

The -days parameter specifies the certificate validity period in days.

 openssl x509 -req -in broker.csr -CA caMQTT.crt -CAkey caMQTT.key -CAcreateserial -out broker.crt -days 1000

The broker.crt file (MQTT broker certificate) must be copied to the MQTT broker, along with the broker.key file (MQTT broker private key). It is also recommended to protect the broker.key file (with access rights, encryption) so that only the user under whom the MQTT broker is running has access to it.

3.1 Creating a key and certificate signing request for the MQTT client

Similar to the MQTT broker, you need to create a key and a certificate signing request for the MQTT client. The procedure is the same, only the file names are different.

Creating a key (with a size of 2048 bits):

openssl genrsa -out myPLC.key 2048

Creating a certificate signing request (csr). It is necessary to enter several parameters, the values given in the example must be modified. It is necessary to enter a CN (Common Name) that corresponds to the MQTT user name:

openssl req -out myPLC.csr -key myPLC.key -new

       Country Name (2 letter code) [AU]:SK
        State or Province Name (full name) [Some-State]:Slovakia
        Locality Name (eg, city) []:Žilina
        Organization Name (eg, company) [Internet Widgits Pty Ltd]:Ipesoft
        Organizational Unit Name (eg, section) []:D2000
        Common Name (e.g. server FQDN or YOUR name) []:myPLC
        Email Address []:ipesoft@ipesoft.sk
        
        Please enter the following 'extra' attributes
        to be sent with your certificate request
        A challenge password []:
        An optional company name []:       

3.2 Creating a certificate for the MQTT client

If you created a certification authority above, you are creating a certificate (signing a certificate signing request). Otherwise, you send the myPLC.csr file for signing to the appropriate certification authority (e.g., the company's IT department).
The -days parameter specifies the certificate validity period in days.

openssl x509 -req -inmyPLC.csr -CA caMQTT.crt -CAkey caMQTT.key -CAcreateserial -out myPLC.crt -days 1000

The myPLC.crt file (MQTT client certificate) must be copied to the MQTT client, along with the myPLC.key file (MQTT client private key). It is also recommended to protect the myPLC.key file (with access rights, encryption) so that only the user under whom the MQTT client is running has access to it.

4 Repeating the procedure for the D2000 MQTT client

Just as the key for the myPLC MQTT client was created and signed, it is necessary to create and sign the key for the myD2000 MQTT client. Its public certificate (myD2000.crt) and private key (myD2000.key) must be copied so that D2000 KOM can access them (the easiest way is to the application directory) and set the path to them as the parameters "My certificate" (#APPDIR#\myD2000.crt) and "My key" (#APPDIR#\myD2000.key) in the TCP/IP-TCP Redundant configuration.

The configuration of a D2000 line of type TCP/IP-TCP Redundant will look like this:

Note: The private key for the D2000 MQTT client (myD2000.key) can also be protected with a password, which must be entered in the "Pre-shared key" field. For more information, see the TCP/IP-TCP Redundant line description.