Secure your MQTT server with authentication and encryption

I found it to be much easier to put haproxy in TCP mode in front of mosquitto than to use mosquitto&#x27;s TLS capabilities. This lets me reload the certificate without restarting mosquitto.<p>My local devices (esp8266) can&#x27;t really handle TLS well, but I want access from outside of my local network to be encrypted. This lets them operate in plain-text mode locally, with firewall rules forcing outside access to be secure.

My approach with a recent personal project (i.e. no actual scaling required) was to have the MQTT server just listen on localhost. Application connects without TLS on the loopback interface. Clients connect over WebSocket (TLS) using their existing OAuth access token as the username and &quot;x&quot; as the password. The application involves an API as well so client credentials are already in use.<p>I used jpmens&#x2F;mosquitto-auth-plug &lt;<a href="https:&#x2F;&#x2F;github.com&#x2F;jpmens&#x2F;mosquitto-auth-plug" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jpmens&#x2F;mosquitto-auth-plug</a>&gt; for the Mosquitto side of things, with a query along the lines of:<p><pre><code> SELECT &quot;hardcoded password hash&quot; FROM oauth_access_tokens WHERE access_token = &quot;%s&quot; AND scope REGEXP &quot;\bmqtt\b&quot;;</code></pre>

We were able to set up a certificate-per-device authorization for MQTT where we use CN field of the cert for mapping to what particular device is allowed to pub&#x2F;sub to

I use almost the same thing with an Internet accessible MQTT server that acts as relay of Zoom Webhook events, except it is using nginx as the proxy. I have local MQTT server that connects to the public MQTT server and then local clients that show zoom status via LEDs are connected to my local server.<p>There is also no mention in article of what is being used for internal DNS resolution. I could assume pi-hole, but something to resolve DNS on home network is required is this operation.

This is a good tutorial to get the server side of things secured. I didn&#x27;t know you could use Traefik to proxy the MQTT connections as well which looks quite useful.<p>The biggest issue I have is with the client side and its various support of TLS and getting a trusted CA certificate distributed. This is the harder part of the equation in my opinion, support is getting better with firmwares like Tasmota but getting some third party IoT device to work over TLS is still a challenge.

I&#x27;m a bit confused. You got a local MQTT server, and a local Traefik proxy, all behind your local firewall. How does Traefik get its LetsEncrypt certificate from behind the firewall when LetsEncrypt can&#x27;t see Traefik?<p>The last time I tried to use LetsEncrypt for a local server, several years ago, this could not be done. Has this changed?

You lucky guys with IP stacks and TLS! I had to secure an IoT MQTT install where the packets themselves needed encryption which meant hamfisting in an encapsulated packet scheme (plain text header, end to end encrypted payloads). Kinda painful and I would not do that again!

Securing MQTT is all good and well. It&#x27;s more difficult with MQTT-SN (lighter weight and lower bandwidth) can run over UDP which is recommended for running over NB-IoT and similar cellular systems.

Could we MQTT in regular applications as well? or just in IOT?