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.

[Alan-Ni]

Hi Øyvind,

Thanks for the reply, 

Recently I'm testing with MQTTX PC software with all the certificate files I've got.

It took me really long time to realize that I probably should import root certificate(ISRG Root X1) as CA file instead of some CA certificate files like cert.pem or fullchain.pem ...etc.

However when I came back to try with 9160 module(using TERA term), it pops Error when I tries to import the root CA to it, no matter with or without \r\n

"""

AT+CFUN=4

OK
AT%CMNG=01

%CMNG: 4294967293,10,"2C43952EE9E000FF2ACC4E2ED0897C0A72AD5FA72C3D934E81741CBD54F05BD1"
%CMNG: 4294967294,6,"88204F1D300667A8DFE05F6C7018C0607B0DFF8D6D69221FF4C2FA7E50543842"
%CMNG: 4294967292,11,"B2C46C2AE7C81943A8BD6DD4ED2A50B659A225A098A177BACB575459CD57CAEF"

OK
AT%CMNG=0,0,0"
-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMTUwNjA0MTEwNDM4
WhcNMzUwNjA0MTEwNDM4WjBPMQswCQYDVQQGEwJVUzEpMCcGA1UEChMgSW50ZXJu
ZXQgU2VjdXJpdHkgUmVzZWFyY2ggR3JvdXAxFTATBgNVBAMTDElTUkcgUm9vdCBY
MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAK3oJHP0FDfzm54rVygc
h77ct984kIxuPOZXoHj3dcKi/vVqbvYATyjb3miGbESTtrFj/RQSa78f0uoxmyF+
0TM8ukj13Xnfs7j/EvEhmkvBioZxaUpmZmyPfjxwv60pIgbz5MDmgK7iS4+3mX6U
A5/TR5d8mUgjU+g4rk8Kb4Mu0UlXjIB0ttov0DiNewNwIRt18jA8+o+u3dpjq+sW
T8KOEUt+zwvo/7V3LvSye0rgTBIlDHCNAymg4VMk7BPZ7hm/ELNKjD+Jo2FR3qyH
B5T0Y3HsLuJvW5iB4YlcNHlsdu87kGJ55tukmi8mxdAQ4Q7e2RCOFvu396j3x+UC
B5iPNgiV5+I3lg02dZ77DnKxHZu8A/lJBdiB3QW0KtZB6awBdpUKD9jf1b0SHzUv
KBds0pjBqAlkd25HN7rOrFleaJ1/ctaJxQZBKT5ZPt0m9STJEadao0xAH0ahmbWn
OlFuhjuefXKnEgV4We0+UXgVCwOPjdAvBbI+e0ocS3MFEvzG6uBQE3xDk3SzynTn
jh8BCNAw1FtxNrQHusEwMFxIt4I7mKZ9YIqioymCzLq9gwQbooMDQaHWBfEbwrbw
qHyGO0aoSCqI3Haadr8faqU9GY/rOPNk3sgrDQoo//fb4hVC1CLQJ13hef4Y53CI
rU7m2Ys6xt0nUW7/vGT1M0NPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV
HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR5tFnme7bl5AFzgAiIyBpY9umbbjANBgkq
hkiG9w0BAQsFAAOCAgEAVR9YqbyyqFDQDLHYGmkgJykIrGF1XIpu+ILlaS/V9lZL
ubhzEFnTIZd+50xx+7LSYK05qAvqFyFWhfFQDlnrzuBZ6brJFe+GnY+EgPbk6ZGQ
3BebYhtF8GaV0nxvwuo77x/Py9auJ/GpsMiu/X1+mvoiBOv/2X/qkSsisRcOj/KK
NFtY2PwByVS5uCbMiogziUwthDyC3+6WVwW6LLv3xLfHTjuCvjHIInNzktHCgKQ5
ORAzI4JMPJ+GslWYHb4phowim57iaztXOoJwTdwJx4nLCgdNbOhdjsnvzqvHu7Ur
TkXWStAmzOVyyghqpZXjFaH3pO3JLF+l+/+sKAIuvtd7u+Nxe5AW0wdeRlN8NwdC
jNPElpzVmbUq4JUagEiuTDkHzsxHpFKVK7q4+63SM1N95R1NbdWhscdCb+ZAJzVc
oyi3B43njTOQ5yOf+1CceWxG1bQVs5ZufpsMljq4Ui0/1lvh+wjChP4kqKOJ2qxq
4RgqsahDYVvTH9w7jXbyLeiNdd8XM2w9U/t7y0Ff/9yi0GE44Za4rF2LN9d11TPA
mRGunUHBcnWEvgJBQl9nJEiU0Zsnvgc/ubhPgXRR4Xq37Z0j4r7g1SgEEzwxA57d
emyPxgcYxn/eR44/KJ4EBs+lVDR3veyJm+kXQ99b21/+jh5Xos1AnX5iItreGCc=
-----END CERTIFICATE-----
"

ERROR
AT%SHORTHWVERSION

%HWVERSION: nRF9160 SICA B1A

OK
AT%SHORTSWVER

%SHORTSWVER: nrf9160_1.3.4

OK
AT%#XSLMVER

#XSLMVER: "2.4.0","2.4.0-lte-788c5f11c0d6"

OK

"""

And below is the root CA I've been trying, downloaded from Let's Encrypt page, Certificate details (self-signed): pem format.

"""

-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMTUwNjA0MTEwNDM4
WhcNMzUwNjA0MTEwNDM4WjBPMQswCQYDVQQGEwJVUzEpMCcGA1UEChMgSW50ZXJu
ZXQgU2VjdXJpdHkgUmVzZWFyY2ggR3JvdXAxFTATBgNVBAMTDElTUkcgUm9vdCBY
MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAK3oJHP0FDfzm54rVygc
h77ct984kIxuPOZXoHj3dcKi/vVqbvYATyjb3miGbESTtrFj/RQSa78f0uoxmyF+
0TM8ukj13Xnfs7j/EvEhmkvBioZxaUpmZmyPfjxwv60pIgbz5MDmgK7iS4+3mX6U
A5/TR5d8mUgjU+g4rk8Kb4Mu0UlXjIB0ttov0DiNewNwIRt18jA8+o+u3dpjq+sW
T8KOEUt+zwvo/7V3LvSye0rgTBIlDHCNAymg4VMk7BPZ7hm/ELNKjD+Jo2FR3qyH
B5T0Y3HsLuJvW5iB4YlcNHlsdu87kGJ55tukmi8mxdAQ4Q7e2RCOFvu396j3x+UC
B5iPNgiV5+I3lg02dZ77DnKxHZu8A/lJBdiB3QW0KtZB6awBdpUKD9jf1b0SHzUv
KBds0pjBqAlkd25HN7rOrFleaJ1/ctaJxQZBKT5ZPt0m9STJEadao0xAH0ahmbWn
OlFuhjuefXKnEgV4We0+UXgVCwOPjdAvBbI+e0ocS3MFEvzG6uBQE3xDk3SzynTn
jh8BCNAw1FtxNrQHusEwMFxIt4I7mKZ9YIqioymCzLq9gwQbooMDQaHWBfEbwrbw
qHyGO0aoSCqI3Haadr8faqU9GY/rOPNk3sgrDQoo//fb4hVC1CLQJ13hef4Y53CI
rU7m2Ys6xt0nUW7/vGT1M0NPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNV
HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR5tFnme7bl5AFzgAiIyBpY9umbbjANBgkq
hkiG9w0BAQsFAAOCAgEAVR9YqbyyqFDQDLHYGmkgJykIrGF1XIpu+ILlaS/V9lZL
ubhzEFnTIZd+50xx+7LSYK05qAvqFyFWhfFQDlnrzuBZ6brJFe+GnY+EgPbk6ZGQ
3BebYhtF8GaV0nxvwuo77x/Py9auJ/GpsMiu/X1+mvoiBOv/2X/qkSsisRcOj/KK
NFtY2PwByVS5uCbMiogziUwthDyC3+6WVwW6LLv3xLfHTjuCvjHIInNzktHCgKQ5
ORAzI4JMPJ+GslWYHb4phowim57iaztXOoJwTdwJx4nLCgdNbOhdjsnvzqvHu7Ur
TkXWStAmzOVyyghqpZXjFaH3pO3JLF+l+/+sKAIuvtd7u+Nxe5AW0wdeRlN8NwdC
jNPElpzVmbUq4JUagEiuTDkHzsxHpFKVK7q4+63SM1N95R1NbdWhscdCb+ZAJzVc
oyi3B43njTOQ5yOf+1CceWxG1bQVs5ZufpsMljq4Ui0/1lvh+wjChP4kqKOJ2qxq
4RgqsahDYVvTH9w7jXbyLeiNdd8XM2w9U/t7y0Ff/9yi0GE44Za4rF2LN9d11TPA
mRGunUHBcnWEvgJBQl9nJEiU0Zsnvgc/ubhPgXRR4Xq37Z0j4r7g1SgEEzwxA57d
emyPxgcYxn/eR44/KJ4EBs+lVDR3veyJm+kXQ99b21/+jh5Xos1AnX5iItreGCc=
-----END CERTIFICATE-----

"""

Do you have any idea what might the problems are?

[Øyvind]

Note that you can use the Cellular Monitor's certificate manager to provision certificates to your device.

Using the AT command CMNG, please note that there is a missing comma ',' in your command

Alan-Ni said:

AT%CMNG=0,0,0"

This should be > AT%CMNG=0,0,0,"

I had not issues provisioning the root CA in your last comment with both the Certificate Manager and AT command directly as above. 

Kind regards,
Øyvind

[Alan-Ni]

Hi Øyvind,

Ahh... how did I miss that.. thanks a lot for pointing that out!

While the Tera term couldn't work, I also tried to import with Cellular monitor tool within nRF Connect for desktop and that works.

I've tried importing the original ISRG Root X1 and another no \r\n version ISRG Root X1, but both of them end up with ERROR when I'm trying to start the MQTTS connect.

As I mentioned at the top post, we are trying simple MQTTS(one way SSL MQTTS, only clients will verify server).Since MQTTX app could connect successfully with ISRG Root X1 provided as CA file only, I believe this "simple MQTTS" is a doable method.

Now I'm confused that when I get the ERROR response when sending AT#XMQTTCON=... command, is it because SLM thinks I'm missing Client Certificate and Private Key? Or is it because the ISRG Root X1 file is not in the correct format? Is there any way to get more detail about the reason of ERROR?

I'm quite confident with syntax issue this time because connecting to the non secure MQTT port (8883->1883, and without <sec_tag>) works fine