MQTT Agent External Broker config

I am Trying to configure a MQTT Agent with Moqsuitto Broker. I have successfully configured a client with 1883 port. But i want to connect to 8883 port for which i have CA certificate and Client certificate. I want to know the procedure of uploading a certificates in a MQTT agent configuration.Thank you


The built in MQTT agent is quite basic and there are no config options for custom certificates; the agent is using HiveMQ client though which is quite functional and you might be able to configure the system to get something working:

This seems to be still the case right?

I am also running into this right now. :confused: what a bummer.


Nice to meet you.

Just to confirm you need to connect OpenRemote to another MQTT broker running a custom TLS certificate?


I need OpenRemote to connect to a remote MQTT broker with X.509 ca/cert/key authentication.

Also the Auto Provisioning part with X.509 could work I assume since the CA Certificate (PEM) can be added and the device can then communicate with the X.509 Provisioning Request Message

  “type”: “x509”,
  “cert”: “...”

But that is another (the next) topic and would swamp this topic. :smiley:

If I can’t even connect to the MQTT broker via X.509 then that’s trouble already.

To avoid any confusion…

Auto provisioninng is for edge devices to connect to an instance of the OpenRemote MQTT broker and indeed best saved for its’ own topic.

The MQTT agent is there to allow linking asset attributes to an external MQTT broker.

I’m assuming we’re talking about server side X.509 and your server (MQTT broker) is using a custom cert chain?

We can look to enhance the MQTT agent to allow loading a custom JKS but also likely possible to import the custom cert into the standard JRE cacert keystore ($JAVA_HOME/lib/security/cacerts) could even value map in a cacerts file with the custom cert already imported.


Will come back again with further details. :slight_smile:

Maybe there’s a misunderstanding, potentially of the term “provisioning”.

“Provisioning” as in “providing the devices with an identity” is a solved problem for us.

Our devices are provided with individual x509 client certs used to connect and identify themselves towards the MQTT broker (and restricted to their topics).

What we’re looking for is a way of associating the devices (speak: associate the x509 identities) with an online account each, where the owner/operator of the device can eventually log in to and e.g. see a dashboard of values aggregated from values gathered from the device via MQTT and/or triggering commands conveyed via MQTT and eventually executed by the device (e.g. “update”).

This online account would need to be created, obviously, and we’re looking for a way to do it as smooth for the user / operator of our devices as possible - e.g. by a QR code printed on the the device, containing an URL, which points to a form which, after just some values to enter, creates an account and associates it with the device.

As MQTT broker we use mosquitto, which does a nice job in restricting devices to their MQTT topics according to their x509 attributes.

In that way OpenRemote would act as web<->mqtt gateway, being an MQTT client which is subscribed to all topics (=all devices), and respectively publishes on / reacts to certain messages on the MQTT bus.

Is this something OpenRemote could be the solution for? - After my research I can’t confirm nor deny it 100% :confused:

It sounds like you’re describing our typical OEM workflow

  1. Devices assigned unique identity using X.509 client certificate during flashing at the factory
  2. Auto provisioning config is defined in OpenRemote using public cert used to sign client certificates
  3. Device connects to the OpenRemote MQTT broker publishes its’ X.509 client certificate and then it is provisioned within OpenRemote and authenticated

Provisioning within OpenRemote involves:

  • Creating an asset to represent the device
  • Creating a service user for the device
  • Linking the service user to the device asset

Authorisation is then handled per attribute (by assigning PROTECTED_READ/PROTECTED_WRITE configuration items) - this can be done in the auto provisioning config.

The MQTT topics and/or the data received on the topics is determined by what assets/attributes the user is linked to (user asset links) and which attributes have the above mentioned configuration item(s). For example a device can subsribe to wildcard topic for the device asset but that user will only ever receive events on that topic that they have access to.

The confusion for me is the talk of ‘the broker’ as some external broker to OpenRemote and it’s not clear to me what OpenRemote’s role is in this scenario.

1 Like

Sorry for the delayed response. Had much on my plate.

I think I might need to take a step back and explain a bit more.
Please bear with me.

Yes that is correct. Also the part about flashing at the factory.

We are running our own MQTT Broker with multiple ports for different type of MQTT accesses with different CAs.
This Server / Setup is non negotiable at the moment.

We want OpenRemote to be the missing part for a workflow like this:

  1. User setup device => gets URL+(UUID and/or Cert File) => Creates Account
  2. :question:OpenRemote links the User to the Device by the (UUID)
  3. Each User getting a Dashboard with graphs and notifications (like more data in n/time)

For 1. Seems not to critical since OpenRemote uses KeyCloak which is solid
For 3. Should be no issue, after reading the docs this is all provided by OpenRemote

For 2.
This is the questionable part, since we are running an external MQTT Broker which is the “master”.
Now the question is can we use our external MQTT Broker with OpenRemote.
So yes we would like to utilize all the parts of OpenRemote except we need to use our own MQTT Broker.

After writing this I look back at me prior response:

I think I described it pretty well what we would like OpenRemote to be for us.

So the only part really blocking us from going one step forward from using OpenRemote is:

Everything I’ve seen and read sounds like this is the critical part.
If its not the OpenRemote MQTT broker the ‘provisioning’ will not work.

If this still creates confusion it might be better to do a video call with my team and yours to clear out some confusions :grimacing:

For now, have a wonderful evening :slight_smile:

Elias :beers:

After a bit more thinking would a mqtt bridge setup not work in this case :thinking:?
I will do some testing.

After some reading docs about mosquitto, OpenRemote and HiveMQ.
As far as I understand everything, OpenRemote should then be a bridge to our MQTT for getting values.
Did I get that right?


Thanks for taking the time to explain your use case a little more.

Indeed using OpenRemote as an MQTT bridge to your existing MQTT broker makes sense; at a very basic level we have an MQTT Agent which utilises HiveMQ Client and allows OpenRemote to pub-sub to another broker but this is for simple use cases.

I would suggest a custom ContainerService that uses an instance of the MQTT client to connect to your broker and subscribe to some wildcard topic(s) for your devices. This container service can then contain the specific business logic to:

  • Extract a unique identifier
  • Create an asset and maybe a retricted user in OpenRemote (linking the user to the new asset)
  • Updating the attributes of this asset when data is received
  • Create an insights dashboard for the user/device

@martin.peeters I guess the work you have done on dashboards doesn’t currently support variables (e.g. regex/substring user name and use this in widgets for attribute source)?

1 Like

Don’t exactly know what you mean, neither have I followed the topic,
but with the widgets that are currently available, you can only insert attribute values into them.
Every value type should work though.

Bulding a custom widget would always work of course.

Hi, back to the original question, are you looking to use tls client cert verification for your 8883/tls connected clients? I have a proxy configuration for that here:

there’s an entry in our container config that maps a secret to the decoded cert/key values which our container mounts to /etc/haproxy/mqtt-certs:

This provides assurances that only devices you manufactured can get past the proxy, at which point they’ll still need to authenticate to the MQTT backend, which they can do by publishing a provisioning message as described in the openremote autoprovision guide. For this you’ll also need upload the CA cert in the openremote admin UI for configuring your autoprovision.