A few weeks ago, we stopped getting location updates from OwnTracks on our phones. Checking the status, I see an error indicating that the connection failed because my certificate does not have a SAN. Which … true, it does not. I knew some consortium agreed that all certs should have SAN values (and RFCs had been updated to reflect this new direction). Evidently version 2.2.2 of OwnTracks has added SAN verification. I reissued the certificate from my CA and added a SAN. I had to put the cert on both my MQTT websockets reverse proxy and the mosquitto server; but, once both were using the new cert, OwnTracks connected and cleared through the queued updates.
Hi Lisa,
Just found your post about this error.
I got myself a Samsung A315 Android 10 phone for Christmas and am getting the same error when connecting OwnTracks to my Mosquitto MQTT (running on Pi3).
The system still works fine for my Motorola Android 8.1.0 with the same certificates (CA, server, client) .
So I suspect I have the same issue you report…..
Just a couple of questions, pleeeeeeaaase..
1. What is used as a ‘SAN’? Does it have to be the servers DNS or can any name be used (as long as is the same on all certificates)
2. How do you ‘put the cert on MQTT websockets reverse proxy’??
One of the hostnames in the SAN will need to match the DNS hostname used to access the server — there can be other names too, but OwnTracks needs to find a match within the SAN list. That’s detailed in OwnTrack’s changelog.
My MQTT websockets reverse proxy (the setup of which is detailed at https://www.rushworth.us/lisa/?p=358) has a few configuration lines for the SSL certificate.
SSLCertificateFile /etc/httpd/conf/ssl/mqtt/mosquitto.rushworth.us.cer SSLCertificateKeyFile /etc/httpd/conf/ssl/mqtt/mosquitto.rushworth.us.key SSLCertificateChainFile /etc/httpd/conf/ssl/mqtt/ca.crtThe same cert is in the mosquitto.conf in the websockets and MQTT listeners
Hope that helps!
–L