TX62-W MQTTS with HiveMQ | Telit Cinterion IoT Developer Community
April 24, 2023 - 4:52pm, 391 views
Hi,
I'm facing some difficulties with establishing a TLS encrypted MQTT connection to a HiveMQ broker.
I was able to successfully use the TX62-W module to establish a regular MQTT connection to the public broker by following the steps described in the command set document.
Now I want to connect to my cloud hosted HiveMQ isntance using MQTTS, without any luck.
I have previously successfully uploaded the required root certificate into the module certificate store using the TLS certificate tool, as well as all of the missing certificates in the chain of trust, just to make sure.
Using AT^SISS?, my configuration looks like this (user, password, and broker id are redacted):
^SISS: 1,"srvType","Mqtt"
^SISS: 1,"conId","1"
^SISS: 1,"address","mqtts:/user:password@broker.s2.eu.hivemq.cloud:8883"
^SISS: 1,"secopt","1"
^SISS: 1,"ipVer","4"
^SISS: 1,"cmd","unsubscribe"
^SISS: 1,"cleanSession","1"
^SISS: 1,"clientid","004401083574984"
^SISS: 1,"topicFilter","MQTTDemoListener"
^SISS: 1,"secsni","1"
^SISS: 1,"sniname","broker.s2.eu.hivemq.cloud"
Trying to open the connection with the AT^SISO=1,2 command results in the error:
^SIS: 1,0,76,"Certificate format error"
Any help on the topic is appreciated, if you have any questions please contact me :)
Hello,
This at the first glance could suggest the problem with the certificate itself. Might be that the format of the certificate you have loaded is incorrect. The certificate files should be in DER binary encoded format.
Can you read the installed certificates with AT^SBNR="is_cert" command and make sure that the displayed information is correct?
On the other hand please enable the information about the certs sent by the server during the handshake with AT^SIND="is_cert",1 and make sure that you have installed the right certificates. Maybe neither of the certs stored on the module match the server root cert. In fact you only need the root which would be most probably the last one displayed.
You can also disable the server cert check on the module (for test only) with AT^SISS=1,"secopt","0" and check if the connection succeeds.
The server may also require the client certificate for mutual authentication. If that is so, you also need to load the client certificate at index 0.
Best regards,
Bartłomiej
Hello Bartłomiej,
thank you for your reply and the information provided.
The certificate itself is a root certificate provided in the .pem format. I used an openssl command to convert the certificate before uploading and it seems to be correct. Is there any way to double check, or other software I should use for it?
I have tried using the AT^SIND="is_cert",1 command but only ever receive the response:
Furthermore, disabling the server cert check on the module with AT^SISS=1,"secopt","0" worked and I was able to connect to the broker without issue.
Best regards
Maximilian
Hello,
I tried to test it and indeed it looks like AT^SIND="is_cert",1 doesn't work with mqtt. I wasn't aware of that. But I'm sure it works with http. So for test you could replace mqtt with http and connect to the same address and port. You should then get the URCs.
As for the certs format there is no dedicated tool. But if the cert was in binary form and you are able to see it loaded with AT^SBNR="is_cert" command all should be fine from the perspective of format correctness.
In that case please make sure that the correct root cert is on the module. You can also remove other related certs to be sure that you only test the proper root cert.
Please let me know the result.
BR,
Bartłomiej
Hi Bartłomiej,
I wasn't able to test this, as the HiveMQ broker does not accept http requests.
Ineed, I was able to upload the format without issue and AT^SBNR="is_cert" does return the certificate.
I will paste the entire AT^SBNR="is_cert" output here:
Certificates 0-23 were already preloaded to the module, certificate 24, and 25 are the same root certificate of the HiveMQ broker. Certificates 26-30 are other certificates that are part of the trust of chain of the broker.
Do I understand it correctly, that you are suggesting to delete ALL certificates on the module apart from the HiveMQ root certificate?
Edit: All the certificates were uploaded using the -sigType NONE option of the cli tool, does this cause any issues?
Best regards
Maximilian
Hello,
I wouldn't delete the preloaded certificates. For test I would only remove the ones that you installed for this site. Then check what server sends and install only the root cert, if it's not already preloaded.
-sigType NONE is correct option for loading server certs. Interesting that you have one cert loaded twice. Honestly I don't know if this could have any side effects, but I would remove one of them to be sure.
I know that https connection to broker.s2.eu.hivemq.cloud:8883 will fail but before that you should get the list of server certificates with '+CIEV:' URCs. Please try to set this:
AT^SISS=1,"srvType","Http"
AT^SISS=1,"address","https://broker.s2.eu.hivemq.cloud:8883"
AT^SISS=1,"cmd","get"
And then you can compare them to the ones that you uploaded and make sure that the correct root cert is on the module.
BR,
Bartłomiej
Hey Bartłomiej,
I found that one of the preloaded certificates is also the same root certificate for the HiveMQ broker. I should therefore not have to upload any certificates in the first place.
I deleted all of the duplicates and other custom certificates I uploaded but the problem stays the same.
Additionally I attempted the commands you gave me and interestingly enough I still get the same certificate format error, and the AT^SIND="is_cert",1 certificate still gives me an empty response:
I'm pretty sure I'm missing something.
Rather than going back and forth with commands I can test myself, feel free to use the broker url:
17b1e0068c4e4e3291d4102e56012deb.s2.eu.hivemq.cloud
to see if the behaviour is different on your side.
Looking forward to hear from you
Best regards
Maximilian
Here you go:
AT^SISS=4,srvType,"Http"
OK
AT^SISS=4,conId,"3"
OK
AT^SISS=4,address,"https://17b1e0068c4e4e3291d4102e56012deb.s2.eu.hivemq.cloud:8883"
OK
AT^SISS=4,cmd,"get"
OK
AT^SISS=4,secopt,0
OK
AT^SISO=4
OK
+CIEV: is_cert,4,"/C=US/O=Let's Encrypt/CN=R3","035B950351BC359F24E1275969135AAD5726","/CN=*.s2.eu.hivemq.cloud","sha256RSA","sha1","3515DCA6A60B7A88D53582BAAF508B60727D0FA8"
+CIEV: is_cert,4,"/C=US/O=Internet Security Research Group/CN=ISRG Root X1","912B084ACF0C18A753F6D62E25A75F5A","/C=US/O=Let's Encrypt/CN=R3","sha256RSA","sha1","A053375BFE84E8B748782C7CEE15827A6AF5A405"
+CIEV: is_cert,4,"/O=Digital Signature Trust Co./CN=DST Root CA X3","4001772137D4E942B8EE76AA3C640AB7","/C=US/O=Internet Security Research Group/CN=ISRG Root X1","sha256RSA","sha1","933C6DDEE95C9C41A40F9F50493D82BE03AD87BF"
^SIS: 4,0,2200,"Http connect 20.79.70.109:8883"
^SIS: 4,0,48,"Remote peer has closed the connection"
For some reason it did not work each time while with broker.hivemq.com:8883 it did. But we'd have to trace the traffic between the module and server to possible capture what could be the case, maybe the server did not respond for some reason.
Anyway I would suggest you to test with the last one - DST Root CA X3 - installed only as it should be the only one needed. please delete the first 2 certs. The second one is also installed twice in your log.
Hello Bartłomiej,
I have tried what you say, removing all but the 23 preinstalled certificates and uploading only the DST Root CA X3 certificate to the module.
The error stays the same and I can not connect to the broker.
Maybe you can create your own HiveMQ account and test the scenario with your own cloud hosted broker. They offer a free tier that can be used for this purpose without any problems.
If you have any other ideas or suggestions please let me know.
Best regards
Maximilian
Hello,
OK, I tested this with MQTT service, not HTTP, and captured the module trace with chip provider tool from which I exported a pcap file, from which I exported the server certificates.
It looks like the server sends different cert chain this time.
When I open the site cert, it shows me this chain:
But when I open ISRG Root X1 it turns out that there is one another root, higher in the chain - DST Root CA X3:
But it is not the same cert we've seen previously. And the funny thing is that it's already outdated - it was valid to Thursday, September 30, 2021 16:01:15. Serial number: 44afb080d6a327ba893039862ef8406b.
Anyway when I installed this cert on the module the connection with secopt 1 succeeded.
You can now google why they use the outdated cert. I suppose that you should find something.
The log:
AT^SISS=4,"secopt","1"
OK
AT^SISO=4
OK
^SIS: 4,0,8800,"Mqtt connect 20.79.70.109:8883"
^SIS: 4,0,2500,"Connection accepted on clean session."
^SIS: 4,0,2522,"devices/004401083575262/messages/devicebound/#"
AT^SISC=4
OK
The conclusion - you were using the wrong certificate.
BR,
Bartłomiej
Hello Bartłomiej,
thank you very much for the great support and help on investigating this topic.
I am in contact with the HiveMQ support team and have informed them of the behaviour to clear things up.
Could you also provide me with the steps you took to extract this second DST Root CA X3 certificate in order for me to replicate?
Thank you very much in advance.
Best regards
Maximilian
Pages