Username and password authentication to remote broker

[bruniii]

I'm sorry to use this "issues" section for something that's more asking for help, and perhaps it's even a stupid question. If there is any other way to get help without opening a fake issue here, please let me know.

I need to use a username/password to connect the LabVIEW MQTT client to a remote broker; no SSL/TLS autentication, only the credentials. I cannot find any input variables of any VIs in you libraries (MQTT Client, Connection, TCP Connection, MQTT Secured TCP Connection, Websockets Connection) that looks like a username/password.

Can you help me? am I missing the right vi/class?

Thank you!
Marco.

[francois-normandin]

@bruniii you can specify the username and password as part of the Connect method. That is where you add the username, password, will topic and messages... Along with the session flags.

(And this is the right place to ask those questions... When one person asks, ten others will find the answer here in the future and won't need to ask) 🙂

[francois-normandin]

For completeness, here is the node in the MQTT palette.

[bruniii]

Thank you! Now it's working. Also, to any future reader: remember to change to True the respective booleans in the "Connect flags" variable of the same VI "Connect to server"

[bruniii]

Now that the authentication Username/Password is working I had to move to the production environment where a MQTTS broker is running and both Username/password and SSL/TLS 1.2 with a certificate have to be used.

I received a ".pfx" certificate file. The IP address and Username/password are the same as the test broker, where I used the TCP connection class.

Below the diagram based on your example for a MQTT client, where I'm using the Secured TCP connection class instead. "Ready for SSL" is true but after "Connect to Server.vi" I'm getting Error 01 "Add Trusted Certificate To TLS Configuration in Connection.TCP-TLS.lvclass:onConnection.vi".

Also, I'm afraid I don't know the correct Hostname input; I've just asked for more information to the maintainer of the MQTTS broker.

Could you help me (AGAIN) with these limited information?

EDIT: they just send me also the ".crt" file. Using this I get the error -715056 "Start TLS in Connection.TCP-TLS.lvclass:onConnection.vi:590001->MQTT_Connection.lvlib:Connection.lvclass:Connect.vi:3060003->MQTT Client.lvlib:Client.lvclass:Connect to Server.vi:7180002"

These are the settings that I'm using with MQTT.fx to successfully connect to the MQTTs broker, together with the .crt file.

Thank you,
Marco.

[francois-normandin]

The domain is determined by the server's certificate. It cannot be an IP address, so it usually looks like "www.my-domain.com" or something of the sort. It is the domain where the certificate is valid (you cannot reuse the same certificate on a different server, so you can be certain, as a client, that the certificate you have will identify the server you are targeting).

The pfx file will not work. It is a format that includes both the certificate and the private key(s), so you must extract the raw certificate from there. The certificate is usually a .cer or. crt file. The private key is usually saved as a .pem or a .key file, and should be kept secret. You would use the key/pem only if LabVIEW is the broker.

This resource might be helpful:
https://www.ibm.com/docs/en/arl/9.7?topic=certification-extracting-certificate-keys-from-pfx-file

There is more, if you need to identify yourself with the server through mutual TLS, then the client must use a private key and the server must have installed the client certificate, but in this case, I think you need only the server's certificate to establish communication.

Maybe this can help:
https://youtu.be/2-OJ-U6eTmE

It contains the broker part and how to create self signed certificates, so you can skip those parts...

[jDaniel-Rodriguez]

Hello everyone! This is my first time posting here about an "issue" similar to the described above by @bruniii, I hope someone could read this
I'm working on a MQTT client connection, that we have tested with python to a exposed Internet MQTT-TLS broker Server, I think that the Broker is not the problem as there are no errors with python.

Now with Labview I have this state machine to perform the TCP-SSL conection with the "Secured TCP Client" and "Configure Secured TCP Client Certificate and Key". (I'm not showing the certificates, address and hostname, but in the second image you can see is working)

In the state "Conectar" I have the "Connect to Server" Vi, I configured the clean session, user and password bits as True, and the payload with the correct password and user

But here I have the problem, after the "Connect to Server" Vi I'm have the error:
Error 66 occurred at MQTT Client.lvlib:Session.Client.lvclass:Send Packet.vi:6230001
Possible reason(s):
Server disconnected

And inside the "Connect to Server" I have:
Error 1446 occurred at Preserve Run-Time Class in MQTT Client.lvlib:Client.lvclass:Connect to Server.vi:7180001->SIMOMET 1.0.vi
Possible reason(s):
LabVIEW: (Hex 0x5A6) The class of object in did not match the class of target object at run-time.

[jDaniel-Rodriguez]

I don't know if there is a relation between this two errors. I put a probe on the MQTT wire before the "Connect to Server" and I got the next information

I am using the following versions of the libraries

If there is anyone who knows something about this issue I will really appreciate a lot, thanks

[francois-normandin]

@jDaniel-Rodriguez
I believe the issue you are having is that the MQTT Client requires a "Connection Configuration" object, not an actual instantiated connection. The MQTT Session handles the connection generically when the MQTT client connects.

This pattern allows 1) connection and reconnection without having to handle the connection object again and 2) allow a connection plugin to be created in any future version of LabVIEW (ex: TLS support in LV2020) while the core MQTT client code is in 2013.

See below how I configure the connection and let the Client`s process (called asynchronously within the Start method) handle the actual act of connection.

Below is a "suggested" pattern for your state machine... in case this is helpful.

Handle auto-reconnection when the client is disconnected, where the True case is where you perform your business logic (state enqueuing, etc.)

Ignore a few error codes which result from the connection being terminated, and let the next iteration attempt a reconnection: