Testing Location Sample Using Custom nrf9160 Boards Failed

[tonyl02]

Hi, I was trying to test the location sample on my custom board that has an nrf9160 chip. I did everything in this link: https://docs.nrfcloud.com/Guides/GettingStarted/Devices/#securely-generating-credentials-on-the-nrf9160, but when I tried to run the nrf Location sample, it gave me this error:

When I was following the steps described in the "securely generating credentials on the nRF9160" section in https://docs.nrfcloud.com/Guides/GettingStarted/Devices/#securely-generating-credentials-on-the-nrf9160, for step 6, the AT command I was sending to my custom boards over UART was "AT%CMNG=0,16842753,1,\"-----BEGIN CERTIFICATE-----\r\nMIIBZjCCAQ0CFEIJ8...-----END CERTIFICATE-----\"\r\n", so I was using \r\n to indicate line breaks in the certificate pem file, and I also used \r\n to indicate the end of an AT command, and I was wondering if this is ok.

Besides, for step 8, I was wondering if I need to provision the devices using the "ProvisionDevices" endpoint, and my device needs to appear and be connected on the nRF cloud, in order for the location sample to work. Since I noticed the location sample only uses the nRF cloud REST API, I only registered the public key using the "RegisterPublicKeys" endpoint. Also I didn't specify my nRF cloud API key and my device ID in my location sample codes , and I was wondering if that is what caused the program to fail.

Following the steps in https://docs.nrfcloud.com/Guides/GettingStarted/Devices/#securely-generating-credentials-on-the-nrf9160 is pretty much all I did. I didn't update my modem firmware on my custom boards, since I am not sure how to do that without using the Programmer app in nRF Connect for Desktop. But I doubt that is what caused the issue.

Sorry for this long question, but I am not sure what I did wrong in the process, so I figured I'd be more detailed. If you need any other information, please let me know.

[Didrik Rokhaug]

Hi,

When you provisioned the credentials to the device, did you include the <CR><LF> at the end? (it is also a part of the certificate, and must be included).

Which device ID did you use when you added the device to nRF Cloud? Did the device appear in nRF Cloud?

The error code indicates that something went wrong during the TLS handshake, which caused the server to reject the connection. If you take a modem trace, then I can look further into why the connection was refused.

Best regards,

Didrik

[tonyl02]

I apologize for the late reply. I have taken another modem trace. I waited for one hour or so before I stopped logging, so hopefully this time it'll help.

modem-trace (2).bin

[Didrik Rokhaug]

Thanks, this trace is a lot better (still not perfect, but that is probably due to the RTT transport).

I haven't been able to find anything directly wrong yet, but the length of our certificates (both CA and the device's) has significant different sizes.

How did you write the certificates to the device?

If you write them from the code, you can see an example of how it can be done in the mqtt_simple sample. There, they have a CA certificate correctly formatted in the certificates.h file, and they use the modem_key_mgmt_write function to write it to the modem in the certificates_provision funtion in main.c.

[tonyl02]

I actually wrote the certificates using AT commands through STM32. And the CA credential that I used is: https://www.amazontrust.com/repository/AmazonRootCA1.pem, and the device credential is the one that is generated using the create_device_credentials.py script. I did notice that in the mqtt_simple sample the line breaks in credentials are represented using "\n", but when I flashed the credentials I used "\r\n". Is this something that could cause the issue?

[Didrik Rokhaug]

tonyl02 said:

I did notice that in the mqtt_simple sample the line breaks in credentials are represented using "\n", but when I flashed the credentials I used "\r\n". Is this something that could cause the issue?

If I write a certificate to the modem with the Certifiate Manager, it also uses <CR><LF>, same when I read the certificate out from the modem, so I don't think that is the issue.

Regardless, I still suspect there could be something wrong with your credentials. Could you try to write them from the application, or read out the CA certificate to confirm that it was written correctly?

And pay particular attention to the line endings, including the one at the end, after the "-----END CERTIFICATE-----"