Client is not authorized to connect

you can also save and share the tcp stream and send it to Hivemq and they can recreate the packets to their TLS server

MQTT.FX connection worked my bad. wrong cluster address.

meanwhile, I will investigate more into this issue

@Daria_H can you please provide a test server with weak SSL so you can view incoming packets. the only thing that I noticed is that mosquitto servers use MQTT PACKET with a TCP wrapper. you guys use pure MQTT protocol which might be the difference in embedded systems.

@nofan Give me a time, I will try to use wireshark.


@chaiyasitr @Daria_H Hello again I have captured the data from my local Hivemq.

I didn’t configure it to user SSL yet just to prove that the encoding is fine.

I will look at auth method =0 and test it further.

If someone from support can help us to trace SSL connection on a cluster this will save me so much time.

2022-03-31 12:58:37,027 - [bg95Test] - Received CONNECT message (mqtt version: MQTTv3_1, client identifier: bg95Test, clean start: true, keep alive: 120, session expiry interval: 0, topic alias maximum: 0, receive maximum: 65535, maximum packet size: 268435460, request response information: false, request problem information: true, auth method: none, username: bg95Test, password: bg95Test1)

2022-03-31 12:58:37,090 - [bg95Test] - Sent CONNACK message (session present: false, retain available: true, shared subscriptions available: true, subscription identifier available: true, wildcard subscriptions available: true, maximum packet size: 268435460, server receive maximum: 65535, topic alias maximum: 0, reason code: 0)

and this is the hex dump from wireshark

00000000 10 2b 00 06 4d 51 49 73 64 70 03 c2 00 78 00 08 .+…MQIs dp…x…
00000010 62 67 39 35 54 65 73 74 00 08 62 67 39 35 54 65 bg95Test …bg95Te
00000020 73 74 00 09 62 67 39 35 54 65 73 74 31 st…bg95 Test1
00000000 20 02 00 00 …

Dear HiveMQ support,

Please test the above MQTT CONNECT packet with your callbacks to see why my device and @chaiyasitr 's can not connect to our clusters with NOT_AUTHORIZED return in our clusters mentioned above.

@nofan Many thanks.
Let me know if you need my support.

I will try to use wireshark on : MQTT, unencrypted, authenticated.

@Daria_H @DKrueger kindly help @nofan.


So the traced connect packet looks fine. I added the bytes into a unit test for the connect decoder and the result looks fine.
username: bg95Test
password (interpreted as UTF8): bg95Test1
Just like shown in the trace log.

I do not understand why it does not work with tls. Is the password for the cloud also alpha-nummeric? If not, can you do another test (capturing the connect bytes) with a password that is not alpha-nummeric (or rather not ACII compatible). I really think this could be the problem.

Usually TLS implementations work or they fail on the handshake sequence. Also I believe the can decode the CONNECT successfully, we would not send NOT_AUTHROIZED otherwise, but close the tcp connection.

Best regards, Daniel

So this line can not work with UTF8 characters outside of the ASCII compatible section:
char * password = MQTT_PASSWORD;

Background char was designed as a 1byte data type. However this is problematic with encodings that need a more space. Therefor UTF8 and other encodings were created. These encodings use more byte (if the symbol to be encoded is outside the extended ASCII).
This source line will likely reduce any not ASCII compatible char to the 8 less-significant bits - I assume. or it will interpret it as more ASCII characters. The encoded connect will still be correct, but the byte array that represents the password will not be the password you set and as a result authorization will fail.
There are other data types in C for UTF8-compatible strings:

To test my assumption, change/create a user in hivemq clould whose password and username only includes lower and upper case letters and numbers.

My username is TestDevice001 and password is Pass123456789, that it doesn’t work.


We need someone who has a tls enabled server or someone from support to start a trace and capture the username/password from the server.

The first 127 chars in UTF8 are ascii char bytes with only 1 byte. Maybe Hivemq auth call backs treat UTF8 chars as 3 bytes.

Ex ‘1’ is 0x31 in ascii and 0x00 0x00 0x31 in utf8.



my cluster address is port 8883

username: bg95Test
password: bg95Test1

you can connect and confirm credentials.

here is another test I have done using MQTT 3.1.1

0000 68 b5 99 c9 25 dc 6c 50 4d d7 9f 93 08 00 45 00 h…%.lPM…E.
0010 00 53 00 5e 00 00 f4 06 e7 46 25 27 f7 5e c0 a8 .S.^…F%’.^…
0020 01 d2 3a 85 07 5b 88 eb 80 01 d7 38 14 d7 50 18 …:…[…8…P.
0030 40 00 47 77 00 00 10 29 00 04 4d 51 54 54 04 c2 @.Gw…)…MQTT…
0040 00 3c 00 08 62 67 39 35 54 65 73 74 00 08 62 67 .<…bg95Test…bg
0050 39 35 54 65 73 74 00 09 62 67 39 35 54 65 73 74 95Test…bg95Test
0060 31 1

and compared it with the Hex Dump from a connection from MQTT.FX

0000 68 b5 99 c9 25 dc 6c 50 4d d7 9f 93 08 00 45 00 h…%.lPM…E.
0010 00 53 77 7b 40 00 78 06 b1 55 25 22 f2 37 c0 a8 .Sw{@.x…U%".7…
0020 01 d2 c5 ed 07 5b 07 29 fc a2 29 15 fa 52 50 18 …[.)…)…RP.
0030 01 02 ce 01 00 00 10 29 00 04 4d 51 54 54 04 c2 …)…MQTT…
0040 00 3c 00 08 62 67 39 35 54 65 73 74 00 08 62 67 .<…bg95Test…bg
0050 39 35 54 65 73 74 00 09 62 67 39 35 54 65 73 74 95Test…bg95Test
0060 31 1

it must be something with the callbacks not encoding unless TLS MQTT connect packet is different.

So if you can please provide a tls enables server where you can trace the packet and make sure it’s fine.


P.S packets are captured from server side not from the client side.

@nofan ‘1’ should be 0x31 in both ASCII and in UTF8. (see: UTF-8 code page). It does not make sense to add empty bytes. ASCII chars will be encoded the same way, thats a main point on utf-8.
The usage of TLS is intransparent for the broker, besides the socket implementation. However as different listeners are used, the listeners might be configured different. I try to get information on that.

Best Regards, Daniel


Can you take another look at your wireshark dump and check the TLS Client Hello?
For Free and Pay As You Go, we require the TLS-SNI extension to be available and used. (See screenshot below).

We ran some tests on embedded C clients so far, but only on the Arduino platforms. Those do support TLS-SNI.

I have enabled SNI but nothing changed




+QMTCONN: 0,0,5 <--------- return code 5 NOT_AUTHORIZED


@simon_b yes I haved used Arduino to connect with HiveMQ with no problems.

but with advanced systems we can not use arduino

@DKrueger Did you have a chance to have a look at the listeners ?

@DKrueger @Daria_H
Any more suggestion for our issue ? Did you have a chance to have a look at the listeners ?


I am trying to connect a device from Iotify simulator (web to hivemq broker.

when I am using public address and mqtt protocol every thing is ok, but when I am trying to connecting device to MQTT cloud broker for free service and mqtt over TLS, client side says not authorized!

I was searching and reading topics for 2 days but problem not solving still!

Also I want to deploy my local hivemq but after installing, the service of hivemq restart repeatedly each one second!

Please Guide me!

Hi @arctrus ,

Thanks for sharing this. Your local deployment might fail due to insufficient resources:

Does your hardware meet Minimum Hardware Requirements?

For connecting to the HiveMQ Cloud broker you need to enable TLS, specify port 8883, supply Username and Password. Your client should have the TLS extension Server Name Indication (SNI) enabled. Please refer to this post that explains how to check this.

I hope this helps,
Dasha from HiveMQ team