Connecting to MQTT Broker using TLS

, ,
1

The company I am contracting for is using a cumulocity instance and I’m trying to connect to the broker using TLS. Unsecured connections work fine, but when I try to use TLS it fails. I’m using the same root certificate to validate broker certificates that is being used for the device cockpit web interface. It uses the same URL that I’m using for the unsecure MQTT connections (obviously using port 1883 for unsecure and 8883 for TLS).
I’m using a board with an ESP32-S3 module using Espressif’s SDK. I was hoping that you might have some ways that I can troubleshoot the issue.

2

What is the exact error you are getting? Have you tried it using a MQTT tool like MQTTx to valid the steps?

3

MQTT Error
MQTT Error1022×590 29.2 KB

I’ve used MQTTBox which also can’t connect. Haven’t tried MQTTx. I’ll give that a shot

4

Found this - maybe it helps. But it should work with MQTTBox or MQTTx if a CA root certificate is used at your instance or you import it accordingly.

5

It might be worth taking a step back as the port 8883 can be configured in two different ways (see Device integration using MQTT - Cumulocity IoT documentation)…the default is to support two-way ssl where you have to use certificates to establish the connection (so you can’t just switch between the 1883 and 8883 ports as the later requires device x509 certs)

From what I’ve read in the post it sounds like you’re just talking about 1-way ssl where you just verify the server is who it says it is…1-way ssl is not the default setting, so I suspect this is the root cause.

6

It would help to know on which instance you want to connect. Is it a cloud instance? If so is it a public one or private hosted one? Asking because instances can be configured differently as Reuben has pointed out.

7

Stephan’s advice got me a lot further. Although I’m still having issues. I can connect to Broker using 1-way using MQTTX so I guess that is enabled. Still having issues with my ESP32 which I’m thinking may be my TLS setup (I’m going to try mucking with my buffers since I’m getting f_read errors). But I’m still unsure of the root certificate. I tried setting up MQTTX to experiment with different root certs by;

image
image2758×837 83.3 KB

But irrespective of what I put into the CA field it seems to access the computers root cert store and I can’t figure out which one it’s using even with DEBUG log turned on.
By using;
openssl s_client -showcerts -debug -servername .com -connect .com:443 2>/dev/null | openssl x509 -inform pem -noout -text
It shows that the intermediate cert is signed by DigiCert Global Root G2 so I’m trying to use that root cert in my ESP32 setup. I wish I could verify, I know that with curl I can hard set the root certs I’m using but I haven’t been able to find that in any mqtt client I’ve tried.

Sorry about obfuscating the urls. I need to figure out if I have permission to divulge that information.

8

Agreed, it would be helpful to know which instance you are trying to connect to. However, I also wanted to clarify what Reuben said as that piece of documentation is misleading - we actually have a ticket on our backlog to fix it, which maybe I should prioritise a bit higher. Anyway, my understanding is that 1-way SSL (client validates server certs) is always enabled by default on port 8883, and 2-way (server also validates client certs) is enabled but optional, so that if the client provides a certificate we will attempt to validate it, and reject the connect if the validation fails. Of course your instance may be configured differently, but that is the default, and how the Cumulocity cloud SaaS instances should behave.

9

OK, the problem appears to be with the ESP32 SDK when using TLS1.3. They have a patch that they talk about here;
[TLSv1.3] ESP32S3 failing to connect when using DS peripheral (IDFGH-12477) espressif esp-idf issues 13489
Until they put the fix into psa_crypto. I’ve also discovered that if I move back to TLS1.2, it works and that I, indeed, have the correct root certificate for the MQTT Broker.

So last question before closing ticket. Do you think the TLS1.2 fix is sufficient or should I go back to 1.3 and apply the patch?

10

My opinion: Depends on your use case. In general TLS 1.3 should be better as TLS 1.2. So if we are talking about productive use cases you might want to go the TLS 1.3 + fix way.
If it’s just a prototype and you want to go on for now you can also go for TLS 1.2 and later switch to TLS 1.3 when the fix is available.