Cannot connect to MQTT and SSL certificates

Environment: host machine running Red Hat 8.7 and KVM; OpenRemote running on a VM that runs docker and Ubuntu 20.04.

I’ve gone through the other threads here about failing to connect to MQTT, tried those solutions as given, and even those fail. I’ve tried the MQTT explorer and it tells me that the ID (including admin) is “not authorized.” I’ve tried to change the proxy port to 1883 and it is rejected/not started/not accepting connections.

Additionally, is there a way to install a certificate signed using a “known” CA (our internal one that we can install in our browsers and trust database)

Are you running with the self signed certificate or are you using a valid domain name and letting the proxy container generate proper signed TLS certificates (via certbot)…you’ve not explained that.

If you are just using the baked in self signed certificate then you will need to configure your MQTT client to not complain about this or load the certificate into your client:

Yes you can provide your own certificate(s), see:

On initial startup, I am using the self-signed cert. We are attempting to use this for some simulations right now, thus why I ask about being able to use a specified certificate instead of attempting to generate one. Everything is going to be effectively be internal… so if we are going to do something via some kind of domain name, we need to be able to sign the certificate rather than request something via certbot. I generate the certificate by creating the CSR and then using an intermediate certificate that was signed by a self-generated CA certificate (all openssl commands).

Ultimately the goal is to connect and feed in information such as a text status, a date/time, and a boolean value regarding specific assets via MQTT.

Most MQTT clients either use your OS trusted CA database or have their own built in ones.

If your CA root certificate is a self signed certificate and not a standard trusted CA then you will generally need to load the cert chain into your MQTT client so it can validate the full certificate chain.

Right… I have loaded the CA cert into the chain/trust database on the client host. I’ve done this kind of stuff many times in the past. Where I have the issues is working with docker as the server… I am a docker novice, so I don’t know how to simply import the desired server certificate and key that will be recognized as “real” by the client host because it was signed by an internally-known authority.

In the OpenRemote stack the proxy service handles TLS termination and the location where certificates are loaded from is desribed in our proxy github repo README which I linked to above.

The path within the docker container is /etc/haproxy/certs/

You will need to volume map your certificates into this directory then haproxy will autoload them, so you edit the docker-compose yml file you are using and under the proxy service volumes section add something like:

volumes:
      - /path/to/cert/mycert.pem:/etc/haproxy/certs/mycert.pem
1 Like

I managed to get the cert to be used by the proxy… but MQTT Explorer still gives me the self-signed certificate in chain error… so I turn off validation. However, I still get the “not authorized” message… and this is what’s on the error console:

subscribing conn/publish/fff54e72-7cd4-4051-b3d6-0b47c1cc01fe
{ Error: Connection refused: Not authorized
    at MqttClient._handleConnack (/tmp/.mount_MQTT-E9wX5rp/resources/app.asar/node_modules/mqtt/lib/client.js:1076:15)
    at MqttClient._handlePacket (/tmp/.mount_MQTT-E9wX5rp/resources/app.asar/node_modules/mqtt/lib/client.js:365:12)
    at work (/tmp/.mount_MQTT-E9wX5rp/resources/app.asar/node_modules/mqtt/lib/client.js:283:12)
    at Writable.writable._write (/tmp/.mount_MQTT-E9wX5rp/resources/app.asar/node_modules/mqtt/lib/client.js:294:5)
    at doWrite (/tmp/.mount_MQTT-E9wX5rp/resources/app.asar/node_modules/readable-stream/lib/_stream_writable.js:428:64)
    at writeOrBuffer (/tmp/.mount_MQTT-E9wX5rp/resources/app.asar/node_modules/readable-stream/lib/_stream_writable.js:417:5)
    at Writable.write (/tmp/.mount_MQTT-E9wX5rp/resources/app.asar/node_modules/readable-stream/lib/_stream_writable.js:334:11)
    at TLSSocket.ondata (_stream_readable.js:706:22)
    at TLSSocket.emit (events.js:194:13)
    at addChunk (_stream_readable.js:296:12) code: 5 }
unsubscribeAll conn/publish/fff54e72-7cd4-4051-b3d6-0b47c1cc01fe

So for whatever reason it’s not authorizing the service user with the key that was generated.

Is this failure during the connect phase as I see subscribing mentioned in your log…

Authentication is done at connect and authorisation is done for each pub sub; that topic is not one supported by our standard MQTTHandlers so it would generate a failed subscription.

OK, this one is a mea culpa on my part… I forgot that the user has to be “realm:userid” and once I made that adjustment I was able to connect.

2 Likes

Of course now comes the fun part of attempting to publish a string value, a date and time value, and a true/false value to three different attributes. I’ve copied the topic format and tried to publish a text value, but now it gives me a “disconnected from server” message every time I hit the Publish button.

I’ve never done publishes to these kinds of queues before… so my discoveries:

  • When publishing a text string, do not just send the string as value… you must send it as “value” (include the double quotes)
  • When publishing a boolean, you have to send a 1 or 0 rather than “true” or “false”
  • When publishing a date/time you must send the epoch time as it given on MS (1000 times the value of what it is on Linux)

The paho-mqtt module for python has been my friend otherwise. :slight_smile:

1 Like

I did that but still get https/1: SSL handshake failure
https/1: SSL handshake failure … Its a cloudfront ssl cert, any idea

What does a web browser show about TLS certificate if you navigate using the same URL as you set in your MQTT client (obviously port 443 rather than 8883); if it shows errors then that might help you diagnose what is going wrong, there is also the openssl command line tool.