I have pondered around the google trough and settled on trying the mosquitto broker. Mostly, because I have a Linux box that has it as a standard package. In the Opto22 videos, as far as I can tell, it is assumed that an MQTT broker is available.
I am setting up a development environment that will use multiple EPIC and RIO devices. We do need to use the “untrusted” ports and TLS with certificates. Certificates are another learning curve for me. In a nut shell I will have about 6 publishers and about 4 subscribers.
My understanding is I need to generate a certificate on each EPIC/RIO device and copy these over to the broker server and install them on the broker so that the broker can communicate via encrypted messages to/from each publisher/subscriber device.
Since you are on a ‘private’ or non-internet facing network, you don’t have a CA (unless your IT guys are running a private CA, in which case, stop reading and go talk to them - they have the certs you need), so you just need to make a self signed CA and client certificate on the broker.
Googles first hit is pretty good:
You need Steps 1, 2 and 5.
So, do those steps on the Linux box running Mosquitto, then put the Public Client cert you make into each EPIC and RIO using groov Manage.
You can then publish and subscribe (it does not make any difference, its the connection that will be SSL) from each client to the broker.
So in short, you were right, but flipped. You make the cert on the server (the broker) and put the public client cert from it into each EPIC/RIO.
Certificates can be “marked” as server or client. Web servers, OpenVPN servers, and MQTT Brokers will all have server certificates. Some clients verify this and will not connect if the wrong type of cert is given.
Client certificates are like user passwords that a server will use to check if the client is allowed to connect to the server - the only place I use these a lot is in OpenVPN for the clients. Some MQTT clients can use client certs, but I haven’t seen anyone use it.
The groov manage part is a separate step. Maybe I am not remembering this correctly, but don’t the CA certs and self signed server certs that you want the groov to connect to go in the client SSL section in groov manage? Why is it named Client SSL?
As far as I can tell, if I am using MQTT with EPIC/RIO devices, the EPIC/RIO are always MQTT clients. The “Server SSL” part confuses me a little. These devices do basically have a “Web Interface”, Groove Manage, Node-Red Editor, and Groove View. These latter functions being “server” roles.
Correct, but that’s not how you are using it (ie, your original question). In your case all the Opto devices are clients to the Broker on the Linux PC which is the server.
Yes, they can be used that way - and we have a lot of customers doing that - but you need the server public cert in the client so that when they connect they can exchange keys and encrypt (not authenticate) the connection which they then pass the broker user/pass over… encrypt, then authenticate.
Or the certificate of a trusted certificate authority that has signed the servers certificate.
With PKI, done correctly, you get both encryption AND authentication - by having a trusted third party (the certificate authority) to vouch for the public key/cert (or by including the public key of the remote device like you are describing) and being able to successfully decrypt incoming data from that source, you have now confirmed who you are talking to - that is authentication.
Without the authentication part, your data could be man-in-the-middle intercepted.
Everyday example: When I log into my bank, I want my data encrypted AND I want to know that I am talking to my bank and not someone else.
That will only work if his network has a gateway to the internet (sounded like he did not in his first post) and if he is using FQDN, which, again, unless I am reading it wrong, it sounded like his network was not setup like that.
For the immediate future, I will have no connectivity to the internet. However. we have network communications between facilities which we presume are untrusted for a variety of reasons (for example, possibly wireless, wi-fi not considered secure at all, WEP2 or otherwise). It will require authentication and encryption.
An update for folks interested. In the following two cases I have not set up any passwords or encryption yet. Just getting the basics to work. I have loaded the Mosquitto broker on both a Linux box and a Windows box on a test network along with a Groov RIO. (Do make sure you add a firewall rule in the RIO to allow port 1833)
Case1) The Linux box is running Fedora 34 and Mosquitto out-of-the-box works great and the RIO is publishing to this broker without issue using the NodeRed nodes. (sweet and easy). I am also using the MQTT Explorer on windows to subscribe to and observe the published data via this Linux broker. The CLI based subscribers also work fine on Windows and Linux sides. Note: mosquitto installed with ‘sudo dnf install mosquitto’
Case 2: On Windows 10 Pro, not so good. I have not been able to get the broker to work correctly. With the MQTT Explorer I can connect to “localhost” only. I can not connect to the broker via it’s IP address locally or externally. I suspect I am missing a config setting. The broker will start and stop successfully but I can not publish to it or subscribe from it. Why things are made so difficult, beats me.
Any hints from users would be greatly appreciated. Once I get these basic things working, then I will add in the authentication and encryption pieces.
You shouldn’t need a firewall rule on the RIO to publish to a broker.
On the windows machine, what do you have setup for the “listener” in the mosquito configuration? Also remember that windows has a firewall as well that will need configured.
The windows machine has three NIC interfaces. I am pretty sure I don’t have the syntax correct for this. I have Windows firewalls off at the moment as this is an isolated test machine on this private network.
PS The RIO is publishing and subscribing to the topic I created. Perhaps I was thinking I needed the firewall rule because I ran into the setup issue on Windows box.
Latest question. I have a RIO communicating with Node-Red using the MQTT nodes and with passwords and TLS enabled. Now onto configuring an Epic PR1 on the same network. This one I am have a little trouble connecting. I am going to update it to the latest firmware which mentions possible MQTT connection issues and will note back here. In the meantime. The question.
Does each Epic or Rio device require it’s own unique username when connecting with the mqtt broker?
Are you using Node-RED on the PR1 to connect to the broker?
I have never had any issues with that connecting.
To answer your question. No. But.
No, they don’t need their own user/pass. Just set the topics different and you will be up and running.
But, do you really want everyone logging in with the same user/pass?
I can’t answer that one for you, but as an example, I do a mix. Some of the stuff (like everything in my house) has the same user pass. But for my aircraft data, I split it either by satellite or by country. That way if I need to cut a feed off, I can just change or delete that one user/pass and don’t have to ask everyone else to change theirs.
User Id had a typo. All working OK so far. I am seeing an error about an MQTT node missing a certificate or key file. This issue I see is in another thread.
