Cannot connect to Mqtt-Broker over tls-port

Hello, I have a mqtt-integration within my application and am running paho mqtt written in golang to work with the received data.
It works perfectly fine on port 1883 without tls with the client configuration being straight forward.
But that was for testing, and I want to use tls so I changed the port to 8883 and added a tls.config to my dialoptions, just as any tutorial on it does. Weirdly enough it doesnt really matter what I change inside my config, the result I capture over Wireshark scoping the ip of the broker is the same.

The program starts with a successful tls-handshake with the port 443 and immediately connects to the port 8883, also successfully. In the 1883 example a Mqtt-Connect packet follows. In the 8883 example Wireshark interprets it as a ssl-packet. The broker acknowledges it and the connection comes to a keep-alive-freeze. A mqtt connect never occurs nor an error I could look up.

I tried all I could think of without any luck and my network expertise is mediocre.
Does anyone have any spontaneous ideas, knows of this. Or differently, how does it look from the server side if anyone has more insight on this.

You may well need a copy of the TTI certificate to references. Some OS’s aren’t up to date, Windows 10, I’m looking at you …

Could you elaborate which certificate you mean? I’ve been using the ca-file from the root certificate directory. But using it or letting it out did not change the result. Also, I am using Windows 10, but an attempt on a Debian VM is the exact same. And thanks for answering.

Literally the TTI certificate they provide on the docs site

I’m sorry for being dense here, but I can’t point a finger to what you mean exactly. I’m on the searching for TheThingsIndustries/tti or certificate only brings up the root certificates that I am using already. The part with ‘certificate to references’ is also unclear to me. I’m grateful you are helping though

Sorry, iPhone short form reply above, now on desktop:

Using Python on Windows 10 I need to include the certificate on the page above. macOS just works. I know Python isn’t Go, but the certificate issue should in theory be the same.

No problem, I didn’t think of using the V2 docs anymore. I added the pem file on that site to the V3 one, but it didnt change anything. The problem is somewhere else. The tls handshake is obviously working, the mqtt connect packet is somehow misinterpreted or messed up on port 8883. As said, I can use a comepletly empty tlsconfig. I tried with client key pair and without. A thing on the side that also unsettles me, sniffing on my own connection, I can perfectly read out the username and apikey I am trying to send. I know Wireshark can be setup to decrypt that automatically but I never did as much.
On another note, I tried connecting to free test brokers with my code changing only username and such and it worked there. (Well, connected atleast)

Don’t know if it helps, but here’s my Python that crashed & burnt on Windows 10 until I included the certificate file:

My program is pretty much the Go-equivalent of that. I’ve taken a closer look at the packet that changes inbetween 1883 and 8883. It’s perfectly identical barring the port. So I am baffled as to why it is interpreted once as SSL-Protocol and once as MQTT-Protocol. The certificates shouldn’t be a problem, last time they were the program mentioned insecure connection issues. The server side isn’t cancelling the connection as if there was an error. It just upholds it.

I’m more pragmatic hacker software and no so much WireShark, so I’m out of immediate ideas.

You may want to have a snuffle at the GitHub repros for the TTS and bits as they may yield results. And/or check all versions of everything.

I finally found it, after more than a week. Technically I could have noticed it in all the examples on the internet, but it is NEVER explicitly stated and static.

When using no tls “tcp://broker”, when using tls “ssl://broker”

I got the idea somewhat from Github, since the tts stack apparently used to only accept mqtt:// and paho uses only the two above. In your Python example the connect() seems to choose that automatically. In Golang it has to be prefixed.

Edit: It might be still more server side since as far as I understood it, the thingsserver translates the incoming protocols into mqtt or mqtts before processing. So other brokers may have different properties regarding procol usage. Maybe that could be mentioned in the docs then. Paho in Python is surely more common, but it apparently dodges common issues another paho language might have.

Welcome to the last 30 years of my life - it was ever thus - thanks for letting us know as I’m sure it will save someone else some time.

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.