Azure IoT Hub
An Azure service that enables bidirectional communication between internet of things (IoT) devices and applications.
Is Device Provisioning Service not case sensitive?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(70.4, 61%, 16%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ENZ%3C/text%3E%3C/svg%3E)
Niclas Zettervall
0
Reputation points
In IoT Hub documentation it says that deviceId is case sensitive:
Due to different reasons we need to change the Common Name in our certificates to always be lowercase. Hence we have some already out with uppercase. I they expire the new one will be changed to lowercase.
I made a test to see what happens if the device was provisioned by the Device Provisioning Service and had a certificate where CN was uppercase. The deviceId in the IoT hub matches the CN and sending data is ok.
Then I made a certificate with “same” CN in lowercase, and made a device provisioning. Then I expected to get a new device in the IoT Hub since the deviceId shall be case sensitive but this happens:
The same device in the IoT Hub is updated with the new cert thumbprint instead of creating a new device with lowercase.
Trying to send telemetry data or update the device twin (with any of the certs) now results in UnauthorizedError.
The only way to fix is to delete the device in the IoT Hub and then make the provisioning again. Then a device with lowercase is created.
Seems that Device Provisioning Service not handles the deviceId as case sensitive when searching in its records and updates a device instead of creating a new.
Is this a bug in DPS? I need to know if we need to handle this when this scenario will happen to some of our devices in the future.
Azure IoT Hub
{count} votes
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(214.4, 74%, 30%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAM%3C/text%3E%3C/svg%3E)
AshokPeddakotla-MSFT 36,006 Reputation points Moderator2023-11-03T14:34:43.6633333+00:00 Niclas Zettervall Greetings!
In IoT Hub documentation it says that deviceId is case sensitive:
I believe, you are referring to Device identity properties page. Did you also check IoT Hub Device Provisioning Service (DPS) terminology ?
As mentioned, the deviceId in IoT Hub is case-sensitive. However, in your test, you found that the Device Provisioning Service (DPS) updated the existing device in IoT Hub with the new certificate thumbprint instead of creating a new device with lowercase.
To give more context, when a device is provisioned through DPS, it creates a device identity in IoT Hub with a unique device ID. The device ID is generated based on the registration ID that is specified in the enrollment record. The registration ID is case-insensitive, but the device ID that is generated from it is case-sensitive.
In your case, when you provisioned the device with a certificate that had an uppercase CN, DPS created a device identity in IoT Hub with an uppercase device ID that matched the CN. When you later provisioned the same device with a certificate that had a lowercase CN, DPS updated the existing device identity in IoT Hub with the new certificate thumbprint instead of creating a new device identity with a lowercase device ID. This is because DPS recognized the registration ID as being the same for both enrollments, and therefore updated the existing device identity instead of creating a new one.
Is this a bug in DPS? I need to know if we need to handle this when this scenario will happen to some of our devices in the future.
I will check and update you as earliest with my findings.
-
Niclas Zettervall 0 Reputation points
2023-11-17T09:50:46.33+00:00 Thanks, it confirms that I works as the test result.
Any updates if this is a bug or will be addressed as a problem that will be solved?
Sign in to comment
Sign in to answer