Connecting Owntrack to my own mqtt broker

Configuration
1

Hi There

I’m struggling to get Owntracks to connect with my own install of moquitto which is running on my Rpi.

I have the mosquitto working perfectly and talking on HA. The issue is getting Owntracks to connect into that broker.

I have setup port forwarding on my router for port 1883 and tried connecting but it always fails.

I’m alittle unclear, do I need to make any changes to the mosquitto.conf file? for this to connect correctly?

I wanted to try and use cloudmqtt.com for my owncloud tracking, I have been able to get owntracks to connect to the cloudmqtt server but no messages come in and I get the following error message in the websocket UI in cloudmqtt Could not connect to WebSocket server, most likely you're behind a firewall that doesn't allow outgoing connections to port 30446

If anyone is able to help me solve this problem I would be really grateful

2

Unless you have configured it differently, port 1883 is normally used as an unencrypted port. I would not recommend you use this from the internet.

Normally, you set up the mosquitto configuration files to accept encrypted connections at port 8883, but this is by convention. You would then need to forward port 8883 to your PI. But first I would test the connection just on your local network, by connecting to the PI ip address.

However, this takes some setup and the mosquitto man pages are not the easiest to read. I would suggest going down the cloudmqtt route, and turn of the ‘use websockets’ option in the owntracks app, which should connect.

Creating a bridge between your mosquitto and cloudmqtt was covered in another post somewhere on this forum.

3

Here’s the post Graham was referring to:

4

You sir or madam seem to know about such things!

I’m attempting to use mosquitto on my pi. I have remote access for hass up and running with the duckdns + let’s encrypt combo, and have been using cloudmqtt for a few weeks. But, I’d very much like to use mosquitto instead, especially as I’ve only been able to connect to cloudmqtt with my plain ol’ port, not my SSL port.

I was able to get mosquitto up and running on my pi, and successfully tested it through the home assistant dev tools/services while on port 1883. But once I switched to port 8883 (changed the listener in /etc/mosquitto/mosquitto.conf and port in configuration.yaml files, and rebooted a few times for good measure), I can’t even subscribe to a topic through my pi. When I try to subscribe to a topic on my pi, I get “Error: connection refused”.

Home Assistant is also displeased, the error log says

17-03-05 19:12:57 ERROR (Thread-3) [homeassistant.components.mqtt] Can't connect to the broker. Please check your settings and the broker itself
Traceback (most recent call last):

and so on and so forth.

Do you know what I’m missing or where I’ve gone wrong? Thank you!

5

I have never set up lets encrypt with mosquitto, so I can’t help much, but the following link was written by mosquitto’s author, so should be valid.
https://mosquitto.org/2015/12/using-lets-encrypt-certificates-with-mosquitto/

1 Like
6

Progress! After some tweaking I got to the point where my “certificate verify failed” when trying to subscribe on my pi. But that is indeed progress! That’s all of the time I have for it tonight, but I’ll be giving it a stab again soon. Thank you!

7

After beating my head trying to use ssl encryption with mosquitto, I eventually learned that using Let’s Encrypt certificates (at least as set up by default) won’t work. The key learning for me is embedded in the Note on the mosquitto-tls page:
It is important to use different certificate subject parameters for your CA, server and clients. If the certificates appear identical, even though generated separately, the broker/client will not be able to distinguish between them and you will experience difficult to diagnose errors.
It seems as though the way Let’s Encrypt is set up is too similar. I have on my list sometime to experiment with manually creating a certificate request for Let’s Encrypt to see if that addresses the problem, but I haven’t done so yet.
What I did find is that rigorously following the instructions at https://mosquitto.org/man/mosquitto-tls-7.html to create a self signed certification solved the problem for me.

1 Like
8

I did this, but where are the certificates?

9

did you manage?

10

that’s exactly my case

11

Unfortunately I haven’t yet. I don’t spend too much time on maintaining and improving my setup, and I’ve had a few issues lately that have kept me busy. Hopefully I’ll take a stab at it again sometime soon (e.g. in a few weeks)!

I’m feeling verbose, so for the curious as to what those issues were:

I experienced an (unrelated) issue wherein html5 notifications stopped working (which I fixed by installing pyelliptic version 1.5.7 {thanks to Flimm here! } ), and another issue wherein my front door light wasn’t turning on, which seemed to be caused by calling an rgb_color to a group which previously worked.

12

I suppose that the issue with the certificates from letsencrypt is that you don’t have a lot of control over the subject names. This is very much intentional by letsencrypt as they are certifying control of a specific domain, and so that domain is the subject name.

If you have control over multiple domains, or subdomains, I imagine that you could make letsencrypt certs for those different domains for client/server and that could work? Can someone confirm?

For example if you had a “smithfam.net” domain, and you could create and make certificates for subdomains “mqtt.smithfam.net” and “iphone.john.smithfam.net”, and use those for the server and client respectively.

13

But you can create letsencrypt that cover all subs too. That is how it normally works. You dont need separate certs for example. Com and www.example.com

14

Yes but for owntracks you want a client certificate with a different subject name (different domain) and not covered under the same certificate.

15

I know this is an old topic now, but would it be possible to use lets encrypt to reverse proxy 443 ssl to port 1883 using url re-writes?

I’ve got a couple of lights in my office at work i’d like to automate. I’m the IT manager, but our firewall is controlled by the local authority, so port opening is difficult.

ideally something like:

server {
    listen 443;
    server_name mqtt.example.com;

    ssl on;
    ssl_certificate /config/keys/letsencrypt/fullchain.pem;
    ssl_certificate_key /config/keys/letsencrypt/privkey.pem;
    ssl_dhparam /config/nginx/dhparams.pem;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
    ssl_prefer_server_ciphers on;
	
	client_max_body_size 0;

    proxy_buffering off;

	location / {
        proxy_pass http://192.168.12.201:1883/;
        proxy_set_header Host $host;
        proxy_redirect http:// https://;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }
}