Adding an individual enrollement for an IOTC device, with only a primary x.509 certificate

Question

When you are configuring a device connection for individual enrollment with x.509 certificates, the IoT Central connection dialog will not allow you to save your connection settings unless you upload both a primary and secondary certificate. In the image attached, you can see that the save button is not enabled after the first certificate is uploaded.

I am using a Microchip ECC608B device project, and the ECC608 only has one x.509 certificate stored in the device. It is not obvious how you continue with this dialog if you do not have a secondary certificate. I did find out through experimentation you can use the same PEM file for both the primary and secondary certificate. But it is difficult to know if this is recommended or expected since I was not able to find a use case in the documentation for a single primary certificate being utilized for an individual enrollment in IOTC.

It is also worth noting in an IoT Hub application it is possible to configure DPS directly such that an individual enrollment only contains a primary certificate. That use case is straight forward.

I would like to request an enhancement to the IOTC connection dialog, allowing user's to save an individual enrollment with either a (primary certificate) OR a (primary certificate AND secondary certificate). This will make the UI more straight forward for use cases that only feature a single primary certificate.

Thanks,

Jason

Answer 1

Hello @Jason Rauch ,

Bringing you the answer I have received from our Azure IoT Security Team. This behavior is by design and intentional so we motivate the usage of best practices when configuring a device connection for individual enrollment with x.509 certificates:

The primary and secondary credential pattern pattern on IoT Hub is for connection reliability when renewing the device key(s). It anticipates the reality where the certificate renewal in IoT Hub does not happen at the same time with the corresponding private key renewal in the device. A device with an old private key attempting to connect to an IoT Hub with a new certificate will fail. However, if the old certificate is retained in the corresponding primary/secondary slot, then IoT Hub will fail over and accept the connection. One can then manage this transition window by how long to retain the old certificate.

Not required by IoT Hub but such reliability through redundancy can be extended into the device by having multiple keys inside the device. ECC608B has up to 16 slots so there are options for multiple keys on the device side should the implementer desire.

Storing the same certificate PEM to both primary and secondary fields misses out on this connection reliability feature.

Let me know if you have further questions?

Remember:

• Please accept an answer if correct. Original posters help the community find answers faster by identifying the correct answer. Here is how.
• Want a reminder to come back and check responses? Here is how to subscribe to a notification.