How do you diagnose a “no authorization” error when trying to connect to HiveMQ Cloud?
Some background:
I am using the MQTT Driver in a product called Fernhill SCADA to connect as an MQTT client to a free instance of a MQTT Cloud Cluster. The MQTT driver establishes a TLS session correctly, but receives a “not authorized” response to the CONNECT request. The user name and password sent in the request match an entry in the Active MQTT Credentials.
A connection from mqtt-cli using the same user name and password works.
The MQTT Driver in Fernhill SCADA is known to work with:
HiveMQ CE running locally both for secure and non-secure connections.
There could be a number of causes of the “no authorization” error, but there is no obvious way to work out why connections fail from the cluster management console.
welcome to the community! “Not Authorised” usually indicates that username or password or other token is not correct or not transmitted.
How does the mqtt command, that works, look?
How does the connection info in the Ferhill Scada look?
Using the Wireshark, make 2 recordings: one recording of the mqtt-cli connection and a recording of the Fernhill Scada connection. The goal of this is to compare the two recordings to see where the difference is.
How do the MQTT credentials in the Scada look?
Did you check the Wireshark logs, can you prove that the mqtt-cli and the Scada produce similar logs, that end in different outcome?
I have installed the Fernhill Scada to my machine and configured an MQTT Connection using my HiveMQ cloud cluster credentials. Unlike in your case, I cannot see the “not authorised” error, my connection works.
Did you try to add a new user to your HiveMQ cloud cluster or add a new cluster to your HiveMQ cloud account and test with the new user?
That is interesting. It shows that Fernhill SCADA is capable of connecting to HiveMQ Cloud.
I have added two users to my HiveMQ cluster, and I get the “not authorized” error for both users. For both users I have checked the user name and password multiple times.
I also know of a user of Fernhill SCADA in Mountain View, California who is getting the same problem.
One thing I have noticed is when I deliberately enter an invalid user name or password, HiveMQ Cloud returns error code 5 “not authorized”. In this situation should HiveMQ Cloud return error code 4 “bad user name or password”?
This is correct - when username or password is not correct, the HiveMQ cloud broker returns CONNACK error code 5 - Not Authorised.
Do you have an example of the broker that would return error 4?
Does the Fernhill SCADA support TLS with server.pem certificate, do you know?
Did you try a similar connection to another broker, for example test.mosquitto.org:8885 ?
Having read the MQTT v3.1.1 specification more closely I can see that error code 4 should only be returned if the user name and password in the connection request is malformed. If the user name and password are correctly formed, but incorrect, then error code 5 is appropriate.
I think I found the cause of the problem. Fernhill SCADA currently does not set the Server Name Indication (SNI) option in the TLS connection request. If I change Fernhill SCADA to set this option, the CONNECT request succeeds.
Can you confirm that providing the Server Name Indication in the TLS connect request is a mandatory requirement to connect to HiveMQ Cloud?
