MQTT Mosquitto broker with SSL/TLS transport security
ust a quick note in setting up transport layer security on the MQTT Mosquitto broker for both supported protocols: MQTT and WebSockets.
There are several posts on the web regarding this, namely:
SSL Client certs to secure mqtt and Mosquitto websocket support
Those posts explain more or less what is needed to be done to have TLS/SSL transport security. These are just my notes:
Generating the server certificates:
This can be quite easily accomplished by using the following script:https://github.com/owntracks/tools/blob/master/TLS/generate-CA.sh.
This script will generate a self signed certificate to be used by Mosquito for providing TLS for the MQTT and WebSocket protocol. All that is needed to run the script is to have openssl installed on your Linux machine.
If the script is called without parameters, it will generate a self signed certificate for the hostname where the script is running. Otherwise a we can pass a hostname as the first parameter to the script.
After running the script, the following files are generated:
- ca.crt – The CA (Certificate Authority, who published the host certificate) public certificate.
- hostname.crt – The hostname, that will run the mosquitto broker, public certificate.
- hostname.key – The hostname private key.
After having these files, we need to configure the Mosquitto Broker to use them.
Mosquitto configuration:
To configure the Mosquito broker we need first to copy the certificates and key files to a known directory. We will create a certs directory under /etc/mosquitto:
sudo -s
mkdir -p /etc/mosquitto/certs
cp ca.crt /etc/mosquitto/certs
cp hostname.* /etc/mosquitto/certs
After this we can modify the mosquitto configuration file. One important thing to keep in mind is that lines must be following each other without blank lines after the listener directive.
So:
# Plain MQTT protocol listener 1883 # End of plain MQTT configuration # MQTT over TLS/SSL listener 8883 cafile /etc/mosquitto/ca.crt certfile /etc/mosquitto/hostname.crt keyfile /etc/mosquitto/hostname.key # End of MQTT over TLS/SLL configuration # Plain WebSockets configuration listener 9001 protocol websockets # End of plain Websockets configuration # WebSockets over TLS/SSL listener 9883 protocol websockets cafile /etc/mosquitto/ca.crt certfile /etc/mosquitto/hostname.crt keyfile /etc/mosquitto/hostname.key
We will make one more change, but restart mosquitto broker now and do some testing.
Testing MQTT TLS/SSL configuration
We can use Mqtt-Spy to subscribe to our defined test topic: test. We can use plain MQTT or use MQTT over TLS/SSL:
MQTT Spy simple TLS configuration
We can use then the MQTT spy tool to publish or subscribe MQTT topics.
By command line, the mosquitto_sub and mosquitto_pub only worked if the port number for MQTTS is provided, otherwise it gives a TLS error:
mosquitto_pub --cafile /etc/mosquitto/ca.crt -h localhost -t "test" -m "message" -p 8883 mosquitto_sub -t \$SYS/broker/bytes/\# -v --cafile /etc/mosquitto/ca.crt -p 8883
This should work without any issues.
Testing MQTT websockets over TLS/SSL configuration
The issue with this testing is that we are using a self signed certificate, so only useful for local, restricted, testing.
Before we can use the MQTT websockets with TLS/SSL enabled we need to use the browser and visit the following URL:
https://MQTT_BROKER_IP_OR_HOSTNAME:9883/mqtt
Note that we are using HTTPS. When connecting to the above URL, the browser should complain about the insecure connection, due to the self signed certificate, and we need to add an exception and always accept that certificate. After that the error should be something like connection reset or failed to load page. This is normal, since the browser won’t upgrade the connection to a web socket.
We can now use the Hive MQTT Websockets Client to test our connection, and it should work fine (Note the connected green icon and SSL is selected):
Forcing TLSv1.2
All this work of enabling TLS/SSL on the Mosquitto Broker is needed, since most IoT clouds that have MQTT interface need that the connection is over TLS/SSL. More specifically AWS IoT cloud needs the connection to be protected by TLS/SSL, but that connection must be only on version 1.2 of the TLS protocol. AWS IoT cloud also requires client authentication through client certificates, but we are not dealing with this part on this post.
So we are now configuring our Mosquitto broker to only accept TLSv1.2 connections. To do that we modify themosquitto.conf file and add the following line:
# MQTT over TLS/SSL listener 8883 cafile /etc/mosquitto/ca.crt certfile /etc/mosquitto/hostname.crt keyfile /etc/mosquitto/hostname.key tls_version tlsv1.2 # WebSockets over TLS/SSL listener 9883 protocol websockets cafile /etc/mosquitto/ca.crt certfile /etc/mosquitto/hostname.crt keyfile /etc/mosquitto/hostname.key tls_version tlsv1.2
and restart the broker.
Testing TLS V1.2
We can specify the TLS version on the mosquitto command line utils:
[pcortex@pcortex:~]$ mosquitto_pub --cafile ./ca.crt --tls-version tlsv1.2 -h localhost -t "test" -m "mes" -p 8883 -d Client mosqpub/26994-pcortex sending CONNECT Client mosqpub/26994-pcortex received CONNACK Client mosqpub/26994-pcortex sending PUBLISH (d0, q0, r0, m1, 'test', ... (3 bytes)) Client mosqpub/26994-pcortex sending DISCONNECT [pcortex@pcortex:~]$ mosquitto_pub --cafile ./ca.crt --tls-version tlsv1.1 -h localhost -t "test" -m "m3224" -p 8883 Error: A TLS error occurred.
As we can see the lower versions of the TLS protocol are now not accepted.
The Websockets client should work without any issues.
Conclusion:
This configuration only solves the transport security, not the authentication security. The later can be accomplished by using the username/password process or using client certificates, which is the process that Amazon AWS IoT cloud uses. But those are topics for other posts.