Queries reg. MS Azure migration to Digicert

Question

Hello, We are using TI CC3235SF gateway and connecting to Azure IoT Hub and using DPS for provisioning. We are Azure IoT SDK in C language. Recently, Azure IoT Hub migrated to Digicert and we realized the gateway was not able to connect to the hub although DPS provisioned the device successfully. To resolve this we added the Digicert Global Root G2 to the "ms.pem" file using the "flashCerts" API. We also removed the Baltimore certificate from the "ms.pem" file as the migration has already occured. On testing, we observed that DPS was no longer able to register the device successfully. We had to add both "Baltimore" and "Digicert" in order to provision and connect (send and Receive msgs to cloud) the device successfully to the Azure IoT Hub. Why do we need "Baltmore" certificate for provioning if Hub has already migrated ? Does the SDK has anything to do with the fact that DPS is not working if Baltimore is not added in ms.pem file? Is Baltimore hardcoded anywhere in the SDK to cause this issue or is the DPS itself requiring Baltmore certificate for verification? Any information in this regard will be helpful. Thank you!!

Answer 1

mrudula y Greetings!

Why do we need "Baltmore" certificate for provioning if Hub has already migrated ?

It's important to have all three certificates on your devices until the IoT Hub and DPS migrations are complete. Keeping the Baltimore CyberTrust Root ensures that your devices will stay connected until the migration, and adding the DigiCert Global Root G2 ensures that your devices will seamlessly switch over and reconnect after the migration. The Microsoft RSA Root Certificate Authority 2017 helps prevent future disruptions in case the DigiCert Global Root G2 is retired unexpectedly.

Does the SDK has anything to do with the fact that DPS is not working if Baltimore is not added in ms.pem file? Is Baltimore hardcoded anywhere in the SDK to cause this issue or is the DPS itself requiring Baltmore certificate for verification?

This is because DPS uses the Baltimore CyberTrust Root certificate to verify the identity of the IoT hub during the registration process. The Azure IoT SDKs in C language rely on the underlying operating system's certificate store to retrieve trusted roots for server authentication during the TLS handshake. Therefore, it is possible that the SDK is requiring the Baltimore CyberTrust Root certificate for verification

When can I remove the Baltimore Cybertrust Root from my devices?

You can remove the Baltimore root certificate once all stages of the migration are complete. If you only use IoT Hub, then you can remove the old root certificate after the IoT Hub migration is scheduled to complete on October 15, 2023. If you use Device Provisioning Service or IoT Central, then you need to keep both root certificates on your device until the DPS migration is scheduled to complete on February 15, 2024.

Please see Migrate IoT Hub resources to a new TLS certificate root for more details.

Let us know if you have any further queries.

Answer 2

mrudula y The error code PROV_DEVICE_RESULT_TRANSPORT indicates that there was an error in the transport layer during the provisioning process. This could be due to a network issue or a problem with the TLS handshake.

The error code PROV_DEVICE_RESULT_DEV_AUTH_ERROR indicates that there was an error in the device authentication process during the provisioning process. This could be due to an incorrect device ID or primary key, or a problem with the device's certificate.

The PROV_DEVICE_REG_STATUS_CONNECTED status message indicates that the device has successfully connected to the provisioning service. This does not necessarily mean that the TLS handshake was successful, as there could still be issues with the transport layer or device authentication.

To troubleshoot the issue, you can try enabling debug logging in the Azure IoT SDK to get more information about the error. This can help you identify the root cause of the issue and find a solution. You can also try checking the device ID and primary key to ensure they are correct, and checking the device's certificate to ensure it is valid and trusted by the provisioning service.

Hope this helps. Let me know if there are any further queries.