MQTT Bridge with an external mosquitto broker. ERR 14? tlsv1 alert internal error?!

LPWAN Industrial Gateways / Concentrators RAK7258
1

Hello!! I am trying to make MQTT bridge with an external mosquitto broker.
I have set everyting but I got this system log below.
mqttEvDisconnectCB: MqttClient [gwBridgeS Mqtt Client] Disconnected: [14]
mqttEvWrReady: mosquitto [[gwBridgeS Mqtt Client]] loop write ERR: 14
mqttEvRegister: Register mosquittto event [gwBridgeS Mqtt Client]

And log message as below is mosquitto broker side error message.
SSL routine:ssl3_read_bytes:tlsv1 alert internal error

Other MQTTFX clients like MQTTFX can connect well with the same option.

Please, somebody help me to solve this problem!

2

Hi. Which Gateway, firmware are you using? SSL? Which port for MQTT bridge?
And where is broker hosted?

3

Hello.
Rak7258 with latest firmware version, tlsv1 with self signed certificate+client certificate, 443 and 8883 was tested, mosquitto broker is hosted on the Azure VM, mqtt user name and password are not required.

4

Will be to do with the self signed certificates as the remote broker cant validate the certificates your service has when setting up the TLS.

Does the Azure platform have any way to add the CA server public certificates you used for signing?

Alternately on the remote MQTT server you need to somehow disable SSL host verification which is insecure

Better yet use a proper TLS cert that is publicly trusted, i.e. a commercial one

5

Thanks for replying.
I am just using azure virtual machine. So I think self-signed certificate is enough now for the test.
After finishing the test, I am gonna change it to commercial certificate.
Anyways am I missing something from rak`s document about mqtt bridge?
Does this kind of err can be occurred if I put the wrong certificate in the input form? :cry:

6

Yes quite possibly and the certificate type you generated can also have an impact on it working or not.

the self signed CA will still work and is fine for testing just as long at the signing computer is added to the Azure VM as a ROOT CA otherwise the Azure vm will not be able to validate the certificate. I’m not saying this is the root of your problem, just seems the likely one as I’ve had plenty of issue in the past with TLS and self signed certificates (not with Mosquitto tho).

I did find this article that may help you https://mcuoneclipse.com/2017/04/14/enable-secure-communication-with-tls-and-the-mosquitto-broker/

7

Hello

I am having the same error/issue, using Mosquitto broker, and self-signed server certificate with or without client certificate, on RAK7249. MQTT is configured to use TLS V1.2.

I have used the Rakwireless-provided script and recommendations in the RAKWireless “MQTT Bridge Configuration for Integration with an External Chirpstack” V1.1 document to generate the CA, server and client certificates on the server, and configure the Mosquitto server.
I can see a TLS connection handshake between the client (RAK7249) and server. The client (RAK7249) server sends “Client Hello” to the server. The server responds with a “Server Hello”, followed by a Certificate, followed by a Server Key Exchange/Certificate Request/“Server Hello Done” packet. After ACK’ing these packets, the RAK7249 sends a TLS V1.2 Alert (Level: Fatal, Description: Internal Error).

Did you solve your problem? If so, please can you share your solution.
Thanks!

8

This problem seems to be the result of generating invalid certificates (using the RakWireless recommended generate-CA.sh script. Specifically, omitting the domain name from the “optional” HOSTLIST that is commented out at the top of the script. As I understand, the CN field in certificates is deprecated, in favour of a subAltName list, that is by default populated with IP addresses on the server, that may not be accessible to the client through a NAT layer. Therefore the domain name or external IP address of the server should be included in the HOSTLIST or IPLIST respectively. I deduced much of this through analysing the network packets in both directions on the server.