API registration of certification for Azure IoT Hub / DPS

[Thomas]

I am trying to connect a custom device to the Azure IoT Hub using DPS service. Because I am using a custom board I am trying to write certificates to the modem using api calls to the modem_key_mgmg functions. Theses functions have a tag and a credential type.

But trying to get around the different certificates in use.and what tags and credential types i should use when writing the certificates.

I have registered Baltimore and DigiCert root CA certificates using the tag CONFIG_MQTT_HELPER_SEC_TAG and CONFIG_MQTT_HELPER_SECONDARY_SEC_TAG and both of them with credential type set to MODEM_KEY_MGMT_CRED_TYPE_PUBLIC_CERT.

For the device certificate I am not really sure what the tag should be, so just set it to 12 for both types.

Then the private certificate is registered with type MODEM_KEY_MGMT_CRED_TYPE_PRIVATE_CERT.

But what about the public part? Should it be MODEM_KEY_MGMT_CRED_TYPE_PUBLIC_CERT?

Is the above at all correct? I am wondering about the tag field since I find no description except a reserrved tag for nRFCloud. Is it used somewhere in the Nordic libraries for Azure and has to have a specific value?

I am getting mqtt_helper, mqtt_connect, error: -111 when trying to connect.

[Charlie]

Hi Thomas,

Thanks for checking with us. The error is also reported in the following case. Have you read through it before to find some hint?

(+) Sample Azure IoT Hub (Thingy9.1) - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com)

Best regards,

Charlie

[Thomas]

Hi Charlie

I have not tested different things to see if I can find a solution....

I have gone through the the Microsoft tutorial on creating and uploading certificates from the beginning again. This was to test that I did not have a problem with the certificates. I have created new internal root CA, subordinate and device certificates.

From this I have

• Internal root CA
• Subordinate certificate used for creating device certificates
• Device certificate(s)
• Device private key(s)

I also have two other public certificates old and new IoT hub

• Baltimore
• DigiCert

There are a number of different ways I can register these certificates in the device.... Is it possible that someone can describe this process from within the application.

I think the only certificates needed in the device is

• Device certificate(s)
• Device private key(s)
• Baltimore
• DigiCert

So I'm doing:

modem_key_mgmt_write(CONFIG_MQTT_HELPER_SEC_TAG, MODEM_KEY_MGMT_CRED_TYPE_CA_CHAIN, digicert, sizeof(digicert));

modem_key_mgmt_write(CONFIG_MQTT_HELPER_SECONDARY_SEC_TAG,MODEM_KEY_MGMT_CRED_TYPE_CA_CHAIN, baltimore, sizeof(baltimore));

modem_key_mgmt_write(CONFIG_MQTT_HELPER_SEC_TAG, MODEM_KEY_MGMT_CRED_TYPE_PUBLIC_CERT, devicecert, sizeof(devicecert));

modem_key_mgmt_write(CONFIG_MQTT_HELPER_SEC_TAG, MODEM_KEY_MGMT_CRED_TYPE_PRIVATE_CERT, devicecertpriv, sizeof(devicecertpriv))

[Thomas]

A few questions (I think I have tried the different combinations, but....)

When uploading a certificate to Azure IoT hub certificates list, are you using the PEM file with only the generated subordinate certificate or a manually combined file with the certificate section for both subordinate and slef-signed root CA?

When adding your testdevice do you set authentificate to "X.509 Self-Signed" or "X.509 CA Signed"?

If you select "X.509 Self-Signed", what secondary thump print do you use?

[Charlie]

Hi Thomas,

Thomas said:

Could you share the test certificates and the exact way you register them?

I can share more details about how I register them.

1. Follow Tutorial - Create and upload certificates for testing - Azure IoT Hub | Microsoft Learn you will get the following keys.

C:\NCS\AzureIoTCerts>dir /s
 Volume in drive C has no label.
 Volume Serial Number is 7C9B-FC43

 Directory of C:\NCS\AzureIoTCerts

18/12/2023  15:21    <DIR>          .
18/12/2023  15:21    <DIR>          ..
18/12/2023  15:18    <DIR>          rootca
18/12/2023  16:08    <DIR>          subca
               0 File(s)              0 bytes

 Directory of C:\NCS\AzureIoTCerts\rootca

18/12/2023  15:18    <DIR>          .
18/12/2023  15:18    <DIR>          ..
18/12/2023  16:04    <DIR>          certs
18/12/2023  16:04    <DIR>          db
18/12/2023  15:10    <DIR>          private
18/12/2023  15:16             2,099 rootca.conf
18/12/2023  15:18             4,135 rootca.crt
18/12/2023  15:16             1,022 rootca.csr
               3 File(s)          7,256 bytes

 Directory of C:\NCS\AzureIoTCerts\rootca\certs

18/12/2023  16:04    <DIR>          .
18/12/2023  16:04    <DIR>          ..
18/12/2023  15:18             4,135 88A8F7A2E59F52BF8F8EA450CDBB125E.pem
18/12/2023  16:04             4,484 88A8F7A2E59F52BF8F8EA450CDBB1260.pem
               2 File(s)          8,619 bytes

 Directory of C:\NCS\AzureIoTCerts\rootca\db

18/12/2023  16:04    <DIR>          .
18/12/2023  16:04    <DIR>          ..
18/12/2023  15:03                 5 crlnumber
18/12/2023  16:04               231 index
18/12/2023  16:04                21 index.attr
18/12/2023  15:25                21 index.attr.old
18/12/2023  15:25               157 index.old
18/12/2023  16:04                34 serial
18/12/2023  15:25                34 serial.old
               7 File(s)            503 bytes

 Directory of C:\NCS\AzureIoTCerts\rootca\private

18/12/2023  15:10    <DIR>          .
18/12/2023  15:10    <DIR>          ..
18/12/2023  15:16             1,884 rootca.key
               1 File(s)          1,884 bytes

 Directory of C:\NCS\AzureIoTCerts\subca

18/12/2023  16:08    <DIR>          .
18/12/2023  16:08    <DIR>          ..
18/12/2023  16:08    <DIR>          certs
18/12/2023  16:08    <DIR>          db
18/12/2023  16:05    <DIR>          private
18/12/2023  16:02             2,094 subca.conf
18/12/2023  16:04             4,484 subca.crt
18/12/2023  16:03             1,018 subca.csr
18/12/2023  16:08             4,552 testdevice.crt
18/12/2023  16:07             1,002 testdevice.csr
               5 File(s)         13,150 bytes

 Directory of C:\NCS\AzureIoTCerts\subca\certs

18/12/2023  16:08    <DIR>          .
18/12/2023  16:08    <DIR>          ..
18/12/2023  16:08             4,552 EE3E911808A245024E9E824AC8F90B4E.pem
               1 File(s)          4,552 bytes

 Directory of C:\NCS\AzureIoTCerts\subca\db

18/12/2023  16:08    <DIR>          .
18/12/2023  16:08    <DIR>          ..
18/12/2023  15:58                 5 crlnumber
18/12/2023  16:08               120 index
18/12/2023  16:08                21 index.attr
18/12/2023  15:58                 0 index.old
18/12/2023  16:08                34 serial
18/12/2023  15:58                34 serial.old
               6 File(s)            214 bytes

 Directory of C:\NCS\AzureIoTCerts\subca\private

18/12/2023  16:05    <DIR>          .
18/12/2023  16:05    <DIR>          ..
18/12/2023  16:03             1,884 subca.key
18/12/2023  16:05             1,732 testdevice.key
               2 File(s)          3,616 bytes

     Total Files Listed:
              27 File(s)         39,794 bytes
              26 Dir(s)  101,159,108,608 bytes free

2. Upload subordinate CA certificate C:\NCS\AzureIoTCerts\rootca\certs\88A8F7A2E59F52BF8F8EA450CDBB1260.pem to IoT Hub or DSP Certificates page.

3. Copy and write the following keys into the device.

Server rootCA:  DigiCertGlobalRootG2.crt.pem or  BaltimoreCyberTrustRoot.crt.pem

Client certificate:  C:\NCS\AzureIoTCerts\subca\certs\EE3E911808A245024E9E824AC8F90B4E.pem

Client private key: C:\NCS\AzureIoTCerts\subca\private\testdevice.key

Program AT client or SLM sample first, then use Certificate Manager to write keys.

If you are testing IoT Hub without DSP, remember to set the following configuration

CONFIG_AZURE_IOT_HUB_DEVICE_ID="testdevice" # same as Subject Common Name (CN) field when you generate certificates

CONFIG_AZURE_IOT_HUB_HOSTNAME=""

Just let me know if there is anything else you feel confused.

Best regards,

Charlie

[Thomas]

If just using IoT hub, how do you add the device, especially authentification!

[Charlie]

Thomas said:

When uploading a certificate to Azure IoT hub certificates list, are you using the PEM file with only the generated subordinate certificate or a manually combined file with the certificate section for both subordinate and slef-signed root CA?

I uploaded the PEM file with only the generated subordinate certificate.

Thomas said:

When adding your testdevice do you set authentificate to "X.509 Self-Signed" or "X.509 CA Signed"?

It uses X.509 Self-Signed. I input the secondary thump print same as the first.

Best regards,

Charlie

[Thomas]

I got it connected using Cellular Monitor and fixed on mistake by me. My thumprint was from the subordinate certificate. When creating a device directly like this, it is the thumprint of the device certificate.

These are the 3 certificates used when writing from Cellular Monitor.

MODEM_KEY_MGMT_CRED_TYPE_CA_CHAIN

MODEM_KEY_MGMT_CRED_TYPE_PRIVATE_CERT

MODEM_KEY_MGMT_CRED_TYPE_PUBLIC_CERT

Moving to test on my own hub if this succeeds I will test with DPS.

I have verified that I can connect to my own hub if I replace the Digicert root CA with the Baltimore one.

 

[Charlie]

Thomas said:

I wanted to validate what types are used in the 3 windows of Cellular Monitor...

Certificate Manager windows correspond to the following tree types. NCS\v2.5.0\nrf\samples\cellular\http_update samples demonstrate how to properly write certificates in fw.

MODEM_KEY_MGMT_CRED_TYPE_CA_CHAIN

MODEM_KEY_MGMT_CRED_TYPE_PUBLIC_CERT

MODEM_KEY_MGMT_CRED_TYPE_PRIVATE_CERT

This is not suggested since it will occupy many memory sizes and is also not secure.

Thomas said:

My hub is currently running with Baltimore so to connect now I need Baltimore and at an unknown time it will change to Digicert. If I do not have both certificates in the device I will loose connection.

Couldn't the two sets of keys stored in different secure tags solve your problem?

My first test showed when Baltimore in CONFIG_MQTT_HELPER_SEC_TAG did not work, it would automatically switch to Digicert in CONFIG_MQTT_HELPER_SECONDARY_SEC_TAG to build the connection.

Best regards,

Charlie