MOSQUITTO
MQTT BROKER FOR IOT (INTERNET OF THINGS)
Guide to setup a free and secure MQTT network using 2 bridged brokers, SSL encryption and Cert based authentication. Basic setup guide with pictures and sample configs! Real life example using Owntracks App!
Edition 2017/01 By
KARL M. JOCH Copyright © 2017 Website: http://KMJ.at The books and e-books page on my site: https://kmj.at/buecher-und-e-books/ Exclusive distribution of this e-book by:
CTS GMBH A-5020 Austria Website: http://CTS.at
INTRODUCTION 1978 I started in the IT-Industry using IBM S3/15, Siemens BS2000 Jumbos and DEC PDP systems. At this time we have done most of the coding in Assembler, Cobol and other languages people mostly don’t know anymore. As the market was growing I opened my own company, CTS GMBH (https://CTS.at), in November 1985 to serve customers with IT services. CTS GMBH is successful since over 30 years and a trusted partner for IT services. Customers range from small companies to European Top-500. Working with Open Source Software started in the early 90’s of the last century, building up a knowledge base which is not seen very often. Privacy and security was always a top priority for me. General rule: “I don’t have anything to hide, but compared to a lot of people I do care a lot who spies on me and collects data about me.” I hope you enjoy reading my books, using the information to build solutions for a stable, secure, monitored, scalable, easy maintainable and as much as possible automated IT-infrastructure. *Note: I am native German speaker and have done the best to make my English error free as much as possible. If you still find typos or grammar errors, feel free to inform me at
[email protected].
TABLE OF CONTENTS Introduction Table of Contents Legal Notes Introduction to IoT IoT (Internet of Things) short info 8 IoT security problems with 9 MQTT Broker for IoT (Internet of Things) 11 Developers MQTT description on mqtt.org 11
Firewall Setup (Optional) Description of firewall ports 13
Setup of this guide – Our Goal Network setup 14 Our final setup will be 15
Download & Install Mosquitto Download the software 17 Install and start the software 17
First configuration steps Prepare the needed SSL certificates 19 We will need the following certificates 19 Server Black 19 Server White 21 Configure Mosquitto 22 Black Server(copy certificates) 22 White Server(copy certificates) 23 Both Servers(mosquitto.conf) 24 Black Server(mosquitto.conf) 25 White Server(mosquitto.conf) 25 Create users in pwfile 26 Black Server(pwfile) 27 White Server(pwfile) 27 Create aclfile 27 Black Server(aclfile sample) 28 White Server(aclfile) 28 Restart the server and check log 29 Black Server(Startup Messages) 29
White Server(Startup Messages) 29
Testing Setup with MQTT.fx Introducion to MQTT.fx 31 Black Server(MQTT.FX connection settings) 32 White Server(MQTT.FX connection settings) 33 MQTT.FX tabs 33 Log 33 Broker Status 33 Scripts 34 Subscribe 34 Publish 35
A real life example using Owntracks Prepare Owntracks setup 37 Install Owntracks on your smartphone 38
More Features About The Author Other Books By (Author) Link List for this e-book Mosquitto project page 44 Openfire download page 44 MQTT.fx project page 44 MQTT.fx download page 44 Authors e-book about SSL Certificates 44 Description of the XMPP protocol 44 MQTT project page 45 Owntracks Project Page 45 FreeBSD Project Page 45
Can I Ask A Favour?
LEGAL NOTES The author’s intellectual property rights are protected by international Copyright law. You are licensed to use this digital copy strictly for your personal enjoyment only. It must not be redistributed or offered for sale in any form. Non of my book are “an advice” in any form. I describe my own experiences, which must not work for you. To all of my writing rules 1-3 from below applies and you should never try things out without asking an expert first. For all content of this book, all information in this book and for any of the described software the following terms, in regard of warranty or liability, of the GPL 3.0 (http://gnu.org) applies: 1) Disclaimer of Warranty. THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 2) Limitation of Liability. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 3. Interpretation of Sections 1 and 2. If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee.
INTRODUCTION TO IOT IOT (INTERNET OF THINGS) SHORT INFO The Internet of Things (IoT) will massive change the world of IT professionals. Machine-to-machine communication, home automation and other new ways of communication or management will deeply move into the business and private world. IoT is the next multi-billion dollar tech market where IT professionals will meet people from home automation, office and production automation, PLC (programmable logic controller) developers and transportation engineers. All of them are fighting for their part of the market. Customers wants to switch heating on or off from their smartphone in the same way as they want to control home or office lights, doors, cams and even the fridge. Not enough, they want the lights go on the time they arrive at home, wants to see the location of family members or business staff on maps and far more. Machines will communicate with machines to securely drive without a human, order missing food in your home and alert in case of emergency. Developer, designers and managers already have $ signs in their eyes every time thinking about the M2M (machine-to-machine) market. I am not sure we really want to have that way of control and communication entering and changing our personal live that much, but we will have to live with it and so we have to deal with the security of IoT.
IOT SECURITY PROBLEMS WITH The IoT market in this form is new, but the parts now working together already existed in their different worlds since a long time. PLC development, home and office automation, controlling machines based on techniques not related with the Internet is done since a very long time. A lot of specialists lived in this part separated from the companies IT-network or the Internet. Most of them never need to care about security. This part of IoT never told other people that each of their controllers and systems is simply a PC with operating system. Often a different one as known be IT people, but still an operation system, sometimes also using IP transport technologies as used in the IT world. These systems are like a PC without any firewall, virus protection and often even without password. Connecting them to IoT they are an easy target for any hacker, even script kiddies. IT professionals created office and home networks, connected them to the Internet and most of the IT systems are able to reach the Internet now. Security was a big part of IT administration job and at the time of writing this e-book most companies and home networks are protected by firewall, virus scanner, email filters, strong encryption, VPN’s and other state-of-the-art protection methods. Most IT professionals never touched PLC/M2M stuff in the past. IoT brings both worlds together and from now on hackers will try to use controllers, switches and other parts of home and office automation as their target. In the easy form a hacker switches off your light in the living room while you are there, in the worst form a hacker powers off your house or office building over a simple Internet connection. Self driving cars as target opens ways to kill people and attacking production companies could lead to explosions or other deadly situations. A huge part of the IoT developers job from now on is security to avoid such situations. This book was written because I saw people connecting MQTT devices and brokers to networks or the Internet without any security in mind. Everybody was able to connect to the MQTT broker without traffic encryption and authentication. This is like leaving the door open while leaving the house. Furthermore, with unencrypted MQTT and IP protocols you more or less add a list of valuable goods at the entrance so people can take all very easy. Every 12 year old can sniff your traffic and read everything in clear text. This e-book will guide you to a basic Mosquitto MQTT broker setup with encrypted traffic and certificate and/or username based authentication. We also will look at the ACL system to restrict the possibility to publish or subscribe to parts of your MQTT messages.
MQTT BROKER FOR IOT (INTERNET OF THINGS) The developers introduce Mosquitto on their website: “Eclipse Mosquitto™ is an open source (EPL/EDL licensed) message broker that implements the MQTT protocol versions 3.1 and 3.1.1. MQTT provides a lightweight method of carrying out messaging using a publish/subscribe model. This makes it suitable for “Internet of Things” messaging such as with low power sensors or mobile devices such as phones, embedded computers or microcontrollers like the Arduino.”
DEVELOPERS MQTT DESCRIPTION ON MQTT.ORG MQTT is a machine-to-machine (M2M)/“Internet of Things” connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. For example, it has been used in sensors communicating to a broker via satellite link, over occasional dialup connections with healthcare providers, and in a range of home automation and small device scenarios. It is also ideal for mobile applications because of its small size, low power usage, minimised data packets, and efficient distribution of information to one or many receivers”
FIREWALL SETUP (OPTIONAL) DESCRIPTION OF FIREWALL PORTS Before you setup Mosquitto I suggest you decide the IP addresses to use and prepare your firewalls in front of the Mosquitto server and between the two instances. This is optional, but a server always should have the best possible protection. Our Mosquitto setup uses the following port configuration: 8883/TCP Port to connect to the Mosquitto server Optional if you use FreeBSD as in this book: 22/TCP SSH (should be restricted to your IP’s) If you install on Windows, MAC, Linux, Raspberry or other you can work on the Desktop or using SSH, depending on your system. Windows doesn’t need port 22, but will use port 3389 if you connect using RDP. ! If you are connected with a dynamic IP running your Mosquitto Server thru Tor hidden services lets access your server without NAT and port forwarding. Learn more about the Tor network in my upcoming book about the Tor network and the good sides of the Darknet.
SETUP OF THIS GUIDE – OUR GOAL
NETWORK SETUP We will use the above network setup. On following pages the black server represents the server connected to the Internet using the red connection line. We need a public IP for this connection. The red connection should be protected by a firewall only allowing inbound connections to port 8883. Outbound connections should be allowed to port 8883 of the white server only. Black and white server are connected using a MQTT bridge so black server can forward messages to the white server. For security reasons this is a one-way only forwarding configured messages from black to white. The white server represents the server connected to your local LAN protected by a firewall. Firewall allows connections to port 8883 incoming from the black server IP only. Port must be forwarded from the firewall IP to the white Mosquitto server in case of using NAT. I suggest you serve static IP’s from your DHCP server to all MQTT devices connected to your LAN (connection blue). The white server accepts connections from LAN (connection blue) based MQTT devices on port 8883.
OUR FINAL SETUP WILL BE Black server has a Internet connection and port 8883 is open to clients on the net. Connecting to port 8883 will open an encrypted connection. Client is forced to show a certificate for authentication and optionally username/password too. We will setup ACL’s to restrict access in different ways. Black server will forward configured messages to the white server and not write a local database. Connecting to port 8883 of the white server will open an encrypted connection too and client is forced to show a certificate for authentication and optionally a username/password as on the black server. The white server will have all messages ready, e.g. for home automation software (See my upcoming book “Home Automation with free Open Source Home Assistant”). This server will also write a local database. With this setup we protect our network from public connections reaching our LAN. Every device will connect only to the publicly available black server, witch is protected by encryption and certificate based authentication. No public device will reach our LAN at any point and brute force attacks wont work because of the missing certificate. We will save no data on the black server and only messages are forwarded. In the worst case of hacking the black server no data can be viewed by the attacker because they are simply not here. Depending on the ACL settings only a restricted subscribe/publishing right on the black server would be granted to the attacker.
DOWNLOAD & INSTALL MOSQUITTO DOWNLOAD THE SOFTWARE You find the binary versions and the source tarballs at the projects download page https://mosquitto.org/download/ Download the version for your operating system.
INSTALL AND START THE SOFTWARE Run the installer as with other software on your system. Installing from source is out the scope of this guide. If you are on Linux or FreeBSD your package manager should have a package for Openfire available. ON Debian apt-get update apt-get install mosquitto does the job. We have chosen FreeBSD for our installation, so pkg update pkg install mosquitto installs Mosquitto. FreeBSD requires to have mosquitto_enable=“YES” in /etc/rc.conf for starting Openfire on system startup. Run service mosquitto start to start Mosquitto the first time. The basic setup of Mosquitto is done!
FIRST CONFIGURATION STEPS PREPARE THE NEEDED SSL CERTIFICATES If really suggest you build your own CA as described in my e-book “My own Certificate Authority“ ( https://www.amazon.com/own-Certificate-Authoritygraphical-PRO-ebook/dp/B01N31I9PQ ). MQTT needs a lot of server and client certificates. A structured management of certificates is the only way to a hassle free administrator life. You should create one sub CA for each server and handle your server and client certificates signed by this CA. If you use self signed I assume you know how to create root CA, signed server certificates and client certificates by your own. OpenSSL Certificate management is out of the scope of this e-book.
WE WILL NEED THE FOLLOWING CERTIFICATES SERVER BLACK Create a CA for this server and export the public key of the CA. Do not combine black and white servers certificates under one CA, especially if you use certificate based authentication using the commonName field only. We will name this black_ca.crt (public key) Create a server certificate for the black server signed by the black CA. Export the public key and the private key file as pem format. We name this black_server.crt (public key) black_server.pem (private key) Create a client certificate, signed by the black CA and save public and private key for further usage. We will use this one later with the MQTT.fx client to prove our setup. Use bclient1 as common Name field. If we use certificate only for authentication this will become the username. We will name this black_client1.crt (public key) black_client1.pem (private key) Finally we need the bridge certificate to authenticate and encrypt the bridge traffic. Create a client certificate, signed by the black CA and save public and private key for further usage. We name this black_bridgetowhite.crt (public key) black_bridgetowhite .pem (private key) SERVER WHITE We will repeat the steps from above. Create a CA for this server and export the public key of the CA. We will name this white_ca.crt (public key) Create a server certificate for the white server signed by the white CA. We name this white_server.crt (public key) white_server.pem (private key) Create a client certificate with common Name wclient1, signed by the white CA and save public and private key for further usage. We will name this white_client1.crt (public key) white_client1.pem (private key)
Finally we need the bridge certificate to authenticate and encrypt the bridge traffic. Create a client certificate, signed by the white CA and save public and private key for further usage. We name this white_bridgetoblack.crt (public key) white_bridgetoblack .pem (private key) We have prepared all the required certificates now.
CONFIGURE MOSQUITTO Mosquitto stores the configuration in text files. Use your preferred editor to change the files as needed. If you are working on FreeBSD files are stored under /usr/local/etc/mosquitto We create mosquitto/Cert mosquitto/Cert-External on both servers to store the needed certificates. BLACK SERVER(COPY CERTIFICATES) We add the following certificates here mosquitto/Cert black_ca.crt black_server.crt black_server.pem mosquitto/Cert-External white_ca.crt white_bridgetoblack.crt white_bridgetoblack .pem WHITE SERVER(COPY CERTIFICATES) We add the following certificates here mosquitto/Cert white_ca.crt white_server.crt white_server.pem mosquitto/Cert-External black_ca.crt black_bridgetowhite.crt black_bridgetowhite .pem On both servers create empty files with the name aclfile, pskfile and pwfile. Now we have to edit the mosquitto.conf file on both servers and edit special
settings per server later. ! Lines starting with – are removed from the default config, the ones with + are added. ! On FreeBSD the path is /usr/local/etc. Adopt this to your installation. BOTH SERVERS(MOSQUITTO.CONF) -port 1883 +port 8883 -#require_certificate false +require_certificate true -#use_identity_as_username false +use_identity_as_username false +#NOTE#use_identity_as_username true +#if true commonName becomes username +#and no entry in pwfile is needed. +#if false we need certificate AND authentication +#with user/pass + entry in pwfile for each user +#we want certs plus username auth -#log_dest stderr +log_dest stdout +log_dest syslog +log_dest topic -#log_type information +log_type error +log_type warning +log_type notice +log_type information +## DEBUG ONES## +log_type subscribe +log_type unsubscribe +log_type debug +log_type all -#connection_messages true +connection_messages true -#log_timestamp true +log_timestamp true -#allow_anonymous true +allow_anonymous false -#password_file +password_file /usr/local/etc/mosquitto/pwfile -#acl_file +acl_file /usr/local/etc/mosquitto/aclfile
BLACK SERVER(MOSQUITTO.CONF) -#tls_version +# we really want TLS 1.2 only on the public server! +tls_version tlsv1.2 +cafile /usr/local/etc/mosquitto/Cert/black_ca.crt +certfile /usr/local/etc/mosquitto/Cert/black_server.crt +keyfile /usr/local/etc/mosquitto/Cert/black_server.pem -#bridge_insecure false +# –––––––––––––––––––––— +# Bridge to our internal MQTT Server / send owntracks to it +# Natted thru Firewall +# we forward all owntracks topics out to white +# owntracks is a nice gps tracking software +# open source for android and IOS +# –––––––––––––––––––––— + +connection bridgetoint +address WHITESERVERSFIREWALLIP:8883 +bridge_cafile /usr/local/etc/mosquitto/Cert-External/white_ca.crt +bridge_certfile /usr/local/etc/mosquitto/Cert-External/white_bridgetoblack.crt +bridge_keyfile /usr/local/etc/mosquitto/Cert-External/white_bridgetoblack.pem +remote_username bridgefromext
+remote_password extbridgebook +bridge_insecure true +topic owntracks/# out
WHITE SERVER(MOSQUITTO.CONF) -#tls_version +## some clients, e.g. HA works with 1.0 only. So LAN side +## actually we cant use 1.2 only +##tls_version tlsv1.2 - #persistence false +#we save data on LAN side server +persistence true +# The filename to use for the persistent database, not including +# the path. -#persistence_file mosquitto.db +persistence_file mosquitto.db +# Location for persistent database. Must include trailing / +# Default is an empty string (current directory). +# Set to e.g. /var/lib/mosquitto/ if running as a proper service on Linux or +# similar. -#persistence_location +persistence_location /var/db/mosquitto/ +cafile /usr/local/etc/mosquitto/Cert/white_ca.crt +certfile /usr/local/etc/mosquitto/Cert/white_server.crt +keyfile /usr/local/etc/mosquitto/Cert/white_server.pem -#bridge_insecure false +# –––––––––––––––––––––— +# Bridge to our external MQTT Server / get owntracks from it +# Natted thru Firewall +# –––––––––––––––––––––— + +connection bridgetoext +address BLACKSERVERSIP:8883 +bridge_cafile /usr/local/etc/mosquitto/Cert-External/black_ca.crt +bridge_certfile /usr/local/etc/mosquitto/Cert-External/black_bridgetowhite.crt +bridge_keyfile /usr/local/etc/mosquitto/Cert-External/black_bridgetowhite.pem +remote_username bridgefromint +remote_password intbridgebook +bridge_insecure true +topic owntracks/# in
CREATE USERS IN PWFILE We are using certificate and user/pass based authentication, so we have to add the required users in pwfile. Mosquitto offers a command line password tool. Replace the /usr/local/etc part with your path to the config files. mosquitto_passwd /usr/local/etc/mosquitto/pwfile username_to_create
asks for the password and adds the user to the pwfile. We need to create BLACK SERVER(PWFILE) bridgefromint with password intbridgebook bclient1 with password bookbc1
WHITE SERVER(PWFILE) bridgefromext with password extbridgebook wclient1 with password bookwc1
CREATE ACLFILE We have set aclfile in mosquitto.con, so lets add some ACL’s with extra protection. ACL’s are based on usernames and notifications. Notifications are build up in the form home/livingroom/switch1 We can use wildcards in the form of + for 1 level or # for all levels following. E.g. home/+/switch1 or home/#. You find a more detailed description of the ACL’s in the Mosquitto server documentation. If used with pattern instead of topic you can place %u (username) or %c (connection) to use an ACL against a pattern. $SYS is a system topic. Will show this when introducing MQTT.fx later. If read or readwrite is not given, readwrite is assumed by Mosquitto. BLACK SERVER(ACLFILE SAMPLE) ########################################################### # This affects access control for clients with no username. ########################################################### # DISABLED topic read $SYS/# ########################################################### # configurations for bclient1 ########################################################### user bclient1 topic readwrite $SYS/# topic readwrite owntracks/# ########################################################### # This affects all clients. # 1) for Bridges # 2) let owntrack users handle their own stuff ########################################################### pattern $SYS/broker/connection/%c/state pattern owntracks/%u/#
WHITE SERVER(ACLFILE) ########################################################### # This affects access control for clients with no username. ########################################################### # DISABLED topic read $SYS/# ########################################################### # configurations for bridgefromext # bridge from black server must be able to write owntracks notifications # on server white. If not nothing will arrive! ########################################################### user bridgefromext topic readwrite owntracks/# ########################################################### # configurations for wclient1 ########################################################### user wclient1 topic readwrite $SYS/# topic readwrite owntracks/# ########################################################### # sample home assistant config for owntracks integration
########################################################### user home-assistant topic read $SYS/# topic read owntracks/# ########################################################### # This affects all clients. # 1) for Bridges # 2) let owntrack users handle their own stuff ########################################################### pattern $SYS/broker/connection/%c/state pattern owntracks/%u/#
RESTART THE SERVER AND CHECK LOG We are now ready to restart Mosquitto and check if everything is up as expected. On FreeBSD run service mosquitto restart and check /var/log/messages for error messages. Entris should look similar to BLACK SERVER(STARTUP MESSAGES) Jan 12 12:28:32 mosquitto[38380]: Connecting bridge bridgetoint (whiteserverip:8883) Jan 12 12:29:02 mosquitto[38380]: New connection from whiteserverip on port 8883. Jan 12 12:29:02 mosquitto[38380]: New client connected from whiteserverip as whiteserverhostname.bridgetoext (c0, k60, u’bridgefromint’). Jan 12 12:29:02 mosquitto[38380]: whiteserverhostname.bridgetoext 0 owntracks/#
WHITE SERVER(STARTUP MESSAGES) Jan 12 12:28:32 mqtt mosquitto[10370]: New client connected from blackserverip as blackserverhostname.bridgetoint (c0, k60, u’bridgefromext’). Jan 12 12:28:32 mqtt mosquitto[10370]: blackserverhostname.bridgetoint owntracks/# Jan 12 12:29:02 mqtt mosquitto[10370]: Connecting bridge bridgetoext (blackserverhostname:8883)
We are done. Both servers up and running, bridge is connected. Now we are ready to really test our installation with some MQTT client.
TESTING SETUP WITH MQTT.FX INTRODUCION TO MQTT.FX Before we continue I want to show you a way to see the messages on your Mosquitto server. We use MQTT.fx as our development tool. MQTT.fx is a MQTT Client written by Jens Deters in Java. MQTT.fx is available from the MQTT.fx project page at mqttfx.org as binary for Linux, MAC and Windows. Download and install should be no problem. MQTT.fx is able to handle certificate based authentication and user/pass authentication.
We need to create the connections using the gear button left of connect. On the new window click the + button in the left bottom corner. BLACK SERVER(MQTT.FX CONNECTION SETTINGS) Create a connection as follows
Click apply and save the connection. Click the blue connect button and check your servers log. It should show something like mosquitto[38518]: New client connected from YourCLientIP as bclient1 (c1, k60, u’bclient1’).
WHITE SERVER(MQTT.FX CONNECTION SETTINGS) Create the connection for the white server accordingly, using the IP of the white server, wclient1 as credential and the white_ca.crt in combination with the white_client1 certificates. Connect to the white server and check your system log.
MQTT.FX TABS LOG The first tab you should check is the log tab which is you MQTT console, showing very helpful informations. In case of problems check this first. BROKER STATUS If the clients ACL’s permitts reading $SYS/# you can click the Subscribe button here. This will subscribe you to the $SYS/# notifications and show you the server figures.
SCRIPTS Here you can test scripts, e.g. switch light on and off. SUBSCRIBE Your essential tab for testing. Here you can subscribe to notifications using the same wildcards as within the aclfile. Subscribe to $SYS/# and owntracks/# for testing purposes and you should see something like
For bridge testing you are able to start a second MQTT.fx instance and watch both sides at the same time. Testing a bridge is easy with it:
PUBLISH The greatest part within MQTT.fx. We cannot only subscribe to notifications. We can publish as long as our ACL settings permit us readwrite to the notification tree. Our ACL settings for ?client1 permit readwrite to $SYS/# and owntracks/#. We publish a few test notifications on the black server
and switch to the subscribe tab on the black server connection to see the notifications because of our subscription to owntracks/#
Even better, having two MQTT.fx instances side by side, you see the notifications immediately appearing on server white too.
We are now ready the applications like e.g. Home Assistant can read the notifications from server white as soon as they arrive on server black.
A book about
“Home Assistant” will be released soon. We now have all of our MQTT notifications encrypted and secured by strong authentication without having any data somewhere in a Cloud (a new name created by marketing specialists for server on the Internet, controlled by people you don’t know, with highest risk for your data). Everything runs within your infrastructure, nobody can sniff something. A perfect setup for everybody.
A REAL LIFE EXAMPLE USING OWNTRACKS I thought about ending here, but finally decided to give you a real life example for our setup which shows the importance of keeping your notifications within your own infrastructure. “OwnTracks ( http://owntracks.org/ ) for IOS and Android allows you to keep track of your own location. You can build your private location diary or share it with your family and friends. OwnTracks is open-source and uses open protocols for communication so you can be sure your data stays secure and private.” Owntracks has the possibility to work with a freely definable MQTT broker, supports certificate and username based authentication and is ready to report your location as MQTT notification to server black. It is also possible to define a “Home” area and report area changes. Putting all of this features together we can use e.g. “Home Assistant” Open Source home automation to switch on lights or heating the time we come home, open the garage or whatever using GPS or area based events. Looking at this example it is very clear you don’t want to have other people reading your data on a Cloud server or sniffing your data. The danger for you, your house or your office would be very high if somebody knows your location and can alert himself with a small app to leave if you are on your way home. Breaking into houses or offices would be very easy that way. So better keep your data private and only trust yourself.
PREPARE OWNTRACKS SETUP Create a new client certificate signed by black_ca CA. Add a user with the same name as the common Name of your certificate to the pwfile. I used karliphone1 for our example.
INSTALL OWNTRACKS ON YOUR SMARTPHONE Install Owntracks App on your Android or IOS smartphone. Install the black_ca.crt as trusted root certificate the way written in the Owntracks documentation available here: http://owntracks.org/booklet/features/tls/ Export the client certificates, e.g. karliphone1 and import them into Owntracks as described in their documentation: http://owntracks.org/booklet/features/tlscert/ You can export as pkcs12 if you followed my other book regarding the Certification Authority. Select the imported certificate and your setup should look like this:
Enable custom security policy with mode “None” and “Allow Untrusted Certificates”. The Owntracks Info page must show connected and you will see entries like this in MQTT.fx. This entries must show up on server black and server white.
Your device is now successfully reporting the device location to your Mosquitto servers and you are ready to use these informations e.g. for “Home Assistant” (ebook to be released soon). A screenshot from “Home Assistant” showing devices at home.
We can switch
things if leaving or coming home, even when entering or leaving other named zones. Detailed setup will be shown in the upcoming e-book “Open Source Home Automation with Home Assistant”.
MORE FEATURES The MQTT protocoll and Mosquitto brokers can be used for different developments. Lighter then http and with push technology opens a huge market. All IT professionals should be used to MQTT in the near future. The intention of this e-book was to have a secure server with encrypted communication and strong authentication. You can run this setup on KVM, VirtualBox or VMWare virtual machines in the same way as using them on Raspberry. Any combination is possible. Other features like adding controllers, switches, sensors and automation related hardware is out the scope of this e-book but I wanted you to be aware of additional features.
ABOUT THE AUTHOR Karl M. Joch Find out more at https://kmj.at/ Karl M. Joch is founder of CTS GMBH with more than 30 years experience in national and international projects. He worked in over 15 countries. IT Skills, especially with Open Source Solutions: IT Infrastructur / Network IT Security – Firewalls, Virusprotection Email Security, Appliances Home Automation Solutions, MQTT, aso. HA Solutions, Auto Failover VPN Solutions FreeBSD, Unix, Linux Asterisk VOIP (Voice over IP) Network Monitoring Webhosting, E-Commerce Solutions Virtualization
OTHER BOOKS BY (AUTHOR) An always up-to-date list of my books can be found here: https://kmj.at/buecher-und-e-books/
LINK LIST FOR THIS E-BOOK MOSQUITTO PROJECT PAGE https://mosquitto.org/
OPENFIRE DOWNLOAD PAGE https://mosquitto.org/download/
MQTT.FX PROJECT PAGE http://jensd.de
MQTT.FX DOWNLOAD PAGE http://mqttfx.jfx4ee.org/index.php/download
AUTHORS E-BOOK ABOUT SSL CERTIFICATES https://www.amazon.com/own-Certificate-Authority-graphical-PROebook/dp/B01N31I9PQ
DESCRIPTION OF THE XMPP PROTOCOL https://en.wikipedia.org/wiki/MQTT
MQTT PROJECT PAGE http://mqtt.org/
OWNTRACKS PROJECT PAGE http://owntracks.org
FREEBSD PROJECT PAGE http://freebsd.org
CAN I ASK A FAVOUR? If you enjoyed this book, found it useful or otherwise then I’d really appreciate it if you would post a short review at the shop you was buying. I try to read all the reviews personally and appreciate your post. I do care who reads my books so the server created for this book is up and running. I would appreciate if you send a message to
[email protected] after your server is up and running. Thank you very much for your support!