NRF9160 modem credential requirements

Hi,

loaded the root CA pem (not the full chain - I had trouble loading that - too large maybe?  is full chain needed?

There's a restriction of 4k. It sounds like that is the issue with the certificate chain.

Trying to connect to the site with security tag 1 results in -111 (-ECONNREFUSED) but only when TLS_PEER_VERIFY is set to REQUIRED (NONE or OPTIONAL makes successful connection).

This indicates that the domain you're connecting to is not verified by the CA that you have inputted to the nRF.

Which CA root are you using, and which domain are you connecting to?

Kind regards,

Håkon

Hi,

loaded the root CA pem (not the full chain - I had trouble loading that - too large maybe?  is full chain needed?

There's a restriction of 4k. It sounds like that is the issue with the certificate chain.

Trying to connect to the site with security tag 1 results in -111 (-ECONNREFUSED) but only when TLS_PEER_VERIFY is set to REQUIRED (NONE or OPTIONAL makes successful connection).

This indicates that the domain you're connecting to is not verified by the CA that you have inputted to the nRF.

Which CA root are you using, and which domain are you connecting to?

Kind regards,

Håkon

Thanks for your reply.  I am connecting to testnet-algorand.api.purestake.io and have tried the CA certificate (amazon root CA 1) and the first cert in the chain (*.api.purestake.io).

I remember seeing it connect successfully using the root CA only before I deleted all other credentials on security tag 1 (only credential type 0 replaced, others unmodified from how it was shipped) unless I was quite confused.

Do I need to load the full chain into the modem?  TLS normally only requires the root certificate to my knowledge.

Hi,

No need for a full chain, you just need the root CA.

I changed the certificate in the https_client to be the AWS Root 1:

https://www.amazontrust.com/repository/AmazonRootCA1.pem

Here's a C header version of the above cert:

"-----BEGIN CERTIFICATE-----\n" \
"MIIDQTCCAimgAwIBAgITBmyfz5m/jAo54vB4ikPmljZbyjANBgkqhkiG9w0BAQsF\n" \
"ADA5MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRkwFwYDVQQDExBBbWF6\n" \
"b24gUm9vdCBDQSAxMB4XDTE1MDUyNjAwMDAwMFoXDTM4MDExNzAwMDAwMFowOTEL\n" \
"MAkGA1UEBhMCVVMxDzANBgNVBAoTBkFtYXpvbjEZMBcGA1UEAxMQQW1hem9uIFJv\n" \
"b3QgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALJ4gHHKeNXj\n" \
"ca9HgFB0fW7Y14h29Jlo91ghYPl0hAEvrAIthtOgQ3pOsqTQNroBvo3bSMgHFzZM\n" \
"9O6II8c+6zf1tRn4SWiw3te5djgdYZ6k/oI2peVKVuRF4fn9tBb6dNqcmzU5L/qw\n" \
"IFAGbHrQgLKm+a/sRxmPUDgH3KKHOVj4utWp+UhnMJbulHheb4mjUcAwhmahRWa6\n" \
"VOujw5H5SNz/0egwLX0tdHA114gk957EWW67c4cX8jJGKLhD+rcdqsq08p8kDi1L\n" \
"93FcXmn/6pUCyziKrlA4b9v7LWIbxcceVOF34GfID5yHI9Y/QCB/IIDEgEw+OyQm\n" \
"jgSubJrIqg0CAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMC\n" \
"AYYwHQYDVR0OBBYEFIQYzIU07LwMlJQuCFmcx7IQTgoIMA0GCSqGSIb3DQEBCwUA\n" \
"A4IBAQCY8jdaQZChGsV2USggNiMOruYou6r4lK5IpDB/G/wkjUu0yKGX9rbxenDI\n" \
"U5PMCCjjmCXPI6T53iHTfIUJrU6adTrCC2qJeHZERxhlbI1Bjjt/msv0tadQ1wUs\n" \
"N+gDS63pYaACbvXy8MWy7Vu33PqUXHeeE6V/Uq2V8viTO96LXFvKWlJbYK8U90vv\n" \
"o/ufQJVtMVT8QtPHRh8jrdkPSHCa2XV4cdFyQzR1bldZwgJcJmApzyMZFo6IQ6XU\n" \
"5MsI+yMRQ+hDKXJioaldXgjUkK642M4UwtBV8ob2xJNDd2ZhwLnoQdeXeGADbkpy\n" \
"rqXRfboQnoZsG4q5WTP468SQvvG5\n" \
"-----END CERTIFICATE-----\n"

And changed the hostname to connect to yours. This is the output:

*** Booting Zephyr OS build v2.7.99-ncs1-1  ***
HTTPS client sample started
Certificate match
Waiting for network.. OK
Connecting to testnet-algorand.api.purestake.io
Sent 83 bytes
Received 261 bytes

>        HTTP/1.1 403 Forbidden

Finished, closing socket.

No problem connecting at my end. Could you try to use https_client to connect on your side as well, to see if it runs as expected?

Kind regards,

Håkon

Hi Håkon,

I cloned a new copy of NCS, pasted the certificate you copied here in to be sure, edited host, changed sec_tag to 1, and this is the output:

*** Booting Zephyr OS build v3.0.99-ncs1  ***
HTTPS client sample started
Certificate match
Waiting for network.. OK
Connecting to testnet-algorand.api.purestake.io
connect() failed, err: 111

I'm pretty sure I saw it working earlier before I changed something.  I think it stopped working after I deleted the other credential types on sec tag 1.  Could you try deleting

MODEM_KEY_MGMT_CRED_TYPE_PUBLIC_CERT,
MODEM_KEY_MGMT_CRED_TYPE_PRIVATE_CERT,
MODEM_KEY_MGMT_CRED_TYPE_PSK,
MODEM_KEY_MGMT_CRED_TYPE_IDENTITY

on the sec tag you're using and see if it will connect?  AFAIK these shouldn't be necessary for server verification only but it's the only logical difference in our setups I can think of.

Thank you for your help,

Erin H

There's definitely something strange going on.  It's working on a different DK and I suspect there's some type of nvm corruption going on with the original.  Before posting here I attempted to load a certificate chain >4KB into the modem and started seeing some strange responses when working with the sec tag I attempted that on (I think it was tag 42).  Is there a way to clear modem nvm to some type of "factory default" state?  I think I may have corrupted my original DK in such a way that it can't do TLS properly anymore

Hi,

Q1: which mfw are you using?

Q2: Could you load the at_client onto the failing board, and issue this AT command?

AT%CMNG=1

And then delete any unused certs?

Docs for reference: https://infocenter.nordicsemi.com/topic/ref_at_commands/REF/at_commands/security/cmng_set.html?cp=2_1_11_7_0

Kind regards,

Håkon