MQTT Agent External Broker config

Dharmit · February 10, 2023, 5:04am

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

Rich · March 6, 2023, 10:41am

Hi,

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:

BrutalBirdie · May 23, 2023, 12:58pm

This seems to be still the case right?

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

Rich · May 23, 2023, 3:26pm

Hey,

Nice to meet you.

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

Rich

BrutalBirdie · May 23, 2023, 3:35pm

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.

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

Rich · May 23, 2023, 4:23pm

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.

BrutalBirdie · May 23, 2023, 4:36pm

Will come back again with further details.

BrutalBirdie · May 25, 2023, 7:02am

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%

Rich · May 25, 2023, 1:44pm

It sounds like you’re describing our typical OEM workflow

Devices assigned unique identity using X.509 client certificate during flashing at the factory
Auto provisioning config is defined in OpenRemote using public cert used to sign client certificates
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.

BrutalBirdie · June 6, 2023, 5:46pm

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:

User setup device => gets URL+(UUID and/or Cert File) => Creates Account
OpenRemote links the User to the Device by the (UUID)
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

For now, have a wonderful evening

Cheers,
Elias

BrutalBirdie · June 8, 2023, 11:26am

After a bit more thinking would a mqtt bridge setup not work in this case ?
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?

https://docs.hivemq.com/bridge/4.11/enterprise-bridge-extension/bridge-extension.html

Rich · June 9, 2023, 10:20am

Hi,

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)?

martin.peeters · June 9, 2023, 3:32pm

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.

cbecker333 · June 9, 2023, 5:42pm

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:

github.com

FreeSK8/sk8net_proxy/blob/main/haproxy.cfg#L94


      
              http-request add-header X-Forwarded-Proto https
              http-request set-header X-Forwarded-Host %[req.hdr(Host)]
              http-request add-header X-Forwarded-Port 443
              http-request add-header Strict-Transport-Security max-age=15768000
          
          
    acl auth url_beg /auth
              use_backend keycloak_backend if auth
              use_backend manager_backend
          
          
listen mqtt
              bind *:8883 ssl crt "/etc/haproxy/mqtt-certs" crt "${CERT_DIR}" verify required ca-file "/etc/haproxy/mqtt-certs/tls.crt" no-tls-tickets
              mode tcp
              #Use this to avoid the connection loss when client subscribed for a topic and its idle for sometime
              option clitcpka # For TCP keep-alive
              timeout client 3h #By default TCP keep-alive interval is 2hours in OS kernal, 'cat /proc/sys/net/ipv4/tcp_keepalive_time'
              timeout server 3h #By default TCP keep-alive interval is 2hours in OS kernal
              option logasap
              log-format "%T %ft CLIENT=%ci:%cp BACKEND=%bi:%bp %ts %ac/%fc/%bc/%sc/%rc %sq/%bq"
              balance leastconn
          
          
    server manager "${MANAGER_HOST}":"${MANAGER_MQTT_PORT}" resolvers kube_resolver check inter 1000

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:

github.com

FreeSK8/openremote-custom-deployment-digitalocean-k8s/blob/main/.ci_cd/digital_ocean/modules/cluster/proxy_statefulset.tf#L121


      
            env {
              name = "DOMAINNAME"
              value = var.frontend_hostname
            }
            env {
              name = "CERT_DIR"
              value = "/deployment/certs"
            }
          }
          termination_grace_period_seconds = 10
          volume {
            name = "cert"
            secret {
              secret_name = "tls-mqtt"
              items {
                key = "tls.crt"
                path = "tls.crt"
              }
              items {
                key = "tls.key"
                path = "tls.crt.key"

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.