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?
- 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.