Format of certification files needed to use secure MQTT in nRF-9160 and nRF-9151

[Alan-Ni]

Hi all,

Recently I am trying to start a secure MQTT connect between Rabbit MQ broker and nRF-9160 or nRF-9151.

nRF9160 is running Serial LTE Modem(SLM) application with v2.4.0 SDK , and nRF-9151 is also running SLM but under v2.7.0 SDK.

Broker was set to single way MQTTS with credentials applied from "let's encrypt" (or called simple MQTTS as I heard, which only clients would check server, server doesn't check client).

I'm now using PC tool "Cellular Monitor" to import certificate files, and according to the GUI, there could be CA certificate(CA) / Client Certificate(CC) / Private Key(PK).

My questions are:

1. According to ChatGPT (might not be correct...):
   "when running simple MQTTS,
   server needs       CA certificate / Server Certificate / Server Private Key,
   and clients need Client CA Certificate / Client Private Key, Client Certificate usually is not a must."
   So... does server and clients both use the same CA certificate file? Does server and client need to have different private key file?
2. I've got 3 files named "cert.pem" "chain.pem" "privkey.pem" provided by server side colleague (I assume these are CA file, CC file and PK file).
   However when I import them into SLM with cellular monitor tool, no matter if I feed CA only / CA + PK / CA + CC + PK, AT#XMQTTCON always returns "ERROR"(Any method to found reason of error?).
   As I'm surfing trying to find some solution, I noticed that some company requires user to turn .pem files into one-line format before feeding them. So does \r and \n needed to remove before feeding my certificate file into SLM?
   
   (Connection to MQTT port success, but connection to MQTTS port with <sec_tag> returns ERROR
   
   
3. I've noticed there are a command AT%KEYGEN. But I'm not sure if I need to use this and how do I use this.
   As mentioned in question 1, do I have to generate a private key per client by it self or can it just use the same PK file as server?
   If it is a must to generate a private key by each client themself, is this the correct command I should use?
   The first purpose stated in the page "Client private key and certificate signing request (CSR) (<key_type> 2, <response_content> 0)" seems kind of like what I need, as it says it could be used for TLS credential. But 1st how does it know which CA should it try to apply client certificate + private key (could CA certificate file help?), 2nd we are only doing simple MQTTS so we might not need the generated client certificate, would "extra certificate file" be a concern or we may just ignore it?

[Øyvind]

Hello, 

Have you verified that the certificates are correct through testing with e.g. Mosquitto broker? From exactly where did you download the certificates? Have you verified correct CA certificate i.e. followed staps provided under https://letsencrypt.org/certificates/?

Could you share the CA certificate with me?

Kind regards,
Øyvind

[Alan-Ni]

Hello,

Thanks for replying the question.

I haven't verified these certificates by myself before.
But my coworker said these 3 files were the certificates files used to config the MQTTS server( set up by someone else), and his client environment could connect successfully. However, I'll try to ask if he knows more detail about how the environment work and how are the files used.

[Øyvind]

Hello, 

The certificates should be connected to the device you are going to connect with. Please ensure correct certificates. 

Kind regards,
Øyvind

[Alan-Ni]

Hi Øyvind,

I tried connecting to the broker with PC software "MQTTX", it would connect if I choose "CA signed server certificate" which I doesn't need to provide certificate file. And it would pop an error saying "unable to get local issuer certificate" if I choose to use our certificate files.

So I looked up for what might the error message means, and looks like the result is "The “unable to get local issuer certificate” error is related to issues with SSL/TLS certificates. It indicates that the certificate chain could not be verified back to a trusted root certificate authority. This error typically occurs in web browsers when connecting to a website that is using an untrusted or invalid SSL certificate."(From this page)

Then I went back to Let's Encrypt and I found this post. Now I'm thinking maybe I need to use fullchain.pem instead of cert.pem.

Otherwise looks like chain.pem doesn't belong to any key types listed in AT%CMNG page to me.

[Øyvind]

For your device you will need the CA root certificate, client certificate and client private key. These are handled by the Certificate Manager which uses the AT command AT%CMNG. To verify what certificates that have been provisioned to your device, please issue AT%CMNG=1.