How to diagnose "no authorization" error?

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:

  • The non secure HiveMQ broker at
  • 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.

Hi RBRadford,

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.

Kind regards,
Dasha from HiveMQ team

A connection from mqtt-cli that works looks like:

mqtt-cli pub -h -p 8883 -s -u HiveUser -pw -t 'my/test/topic' -m 'Hello'

The diagnostic log from Fernhill SCADA which shows the request sent before encryption and the reply after decryption is as follows:

2022-02-03 10:17:26.381 15BC IO: Connect to ''...

2022-02-03 10:17:26.410 15BC Socket connection complete
2022-02-03 10:17:26.410 15BC Remote socket name:
2022-02-03 10:17:26.410 15BC Local socket name:
2022-02-03 10:17:26.410 15BC SSLConnect...
2022-02-03 10:17:26.442 15BC SSLConnect...
2022-02-03 10:17:26.443 15BC SSLConnect...
2022-02-03 10:17:26.443 15BC SSLConnect...
2022-02-03 10:17:26.478 15BC SSLConnect...
2022-02-03 10:17:26.478 15BC SSLConnect complete
2022-02-03 10:17:26.478 15BC Cipher: ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
2022-02-03 10:17:26.478 15BC IO: Connection to complete
2022-02-03 10:17:26.478 15BC Start transaction 2 (MQTT Connect) attempt 1
2022-02-03 10:17:26.478 15BC Tx 63 bytes
2022-02-03 10:17:26.478 15BC 0000  10 3D 00 04 4D 51 54 54  04 C2 AF C8 00 16 46 48 .=..MQTT......FH
2022-02-03 10:17:26.478 15BC 0010  41 41 39 39 46 44 45 33  36 44 43 38 45 36 35 38 AA99FDE36DC8E658
2022-02-03 10:17:26.478 15BC 0020  33 30 36 33 00 08 48 69  76 65 55 73 65 72 00 0F 3063..HiveUser..
2022-02-03 10:17:26.478 15BC 0030  ** ** ** ** ** ** ** **  ** ** ** ** ** ** **    ***************
2022-02-03 10:17:26.478 15BC Channel is processing transaction 2 (MQTT Connect)
2022-02-03 10:17:26.506 15BC Rx  4 bytes: 20 02 00 05                                       ...
2022-02-03 10:17:26.506 15BC Transaction 2: MQTT Connect transaction failed: Connection Refused, not authorized

Note: The diagnostic log automatically redacts sensitive information such as passwords.

I could take Wireshark logs, but since the payload will be encrypted, I’m not sure how that will help.

Hey RBradford,

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?

Please clarify,
Dasha from HiveMQ team

The properties of the SCADA:

I took the wireshark captures as requested, but the upload of the pcapng files was blocked. Both wireshark captures show:

  • TLS connection successfully established (both using TLS 1.2)
  • Exchange of encrypted application data.
  • Disconnection

Difficult to prove they are the same because the MQTT application payload is encrypted!

Hi RBradford,

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?

Dasha from HiveMQ team

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

Hi Robert,

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?

Dasha from HiveMQ Team

Hi Robert,

Does the Fernhill SCADA support TLS with server.pem certificate, do you know?
Did you try a similar connection to another broker, for example ?

Dasha from HiveMQ Team

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.

Connections from Fernhill SCADA to work fine, although responses from that broker can be delayed by up to 5-6 seconds.

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?