Azure DPS and IoT hub, x509 authentication and certificate management

Question

I am reading up and experimenting with DPS, IoT hub and x509 authentication, but some things are not entirely clear for me. Assuming a setup with x509 and group enrollment through intermediate certificates:

• When a device connects to DPS, will it be registered to a hub if the intermediate certificate is removed, but the root certificate is still present and valid?
• When a device connects to DPS, will it be registered to a hub if the intermediate certificate has expired but the root certificate is still valid?
• When a device connects to DPS, will it be registered to a hub if the intermediate certificate is valid but the root certificate has expired?
• To disallow DPS access in a group certificate setup, one would create an individual device registration using the device certificate and then disable that device. However, in such a setup the device certificate might not be available as that is generated with the intermediate certificate. How does one create this individual device registration in this case?
• Is the device certificate actually used as TLS client authentication or is device authentication something built on top of of TLS?
• What are the recommended validity periods of CA, intermediate/group and device certificates in DPS/IoT hub?
• What is the recommended strategy regarding device certificates if devices could be offline for longer (5 years and more perhaps) periods of time in which there might be no way of updating (client) certificates?

Answer 1

Hello @Tom Bulsink | Inspiro , This is really a great question on DPS and IoT Hub best practices. The majority covers very broad areas! I tried my best to put it in a simple way to reduce reading confusion.

When a device connects to DPS, will it be registered to a hub if the intermediate certificate is removed, but the root certificate is still present and valid?
When a device connects to DPS, will it be registered to a hub if the intermediate certificate has expired but the root certificate is still valid?
When a device connects to DPS, will it be registered to a hub if the intermediate certificate is valid but the root certificate has expired?

Please see this documentation for an example: DPS device chain requirements

Be aware, though, that, if you delete the enrollment group and there is an enabled enrollment group for a signing certificate higher up in the certificate chain of one or more of the devices, those devices can re-enroll. More info: Enrollment groups||How to deprovision devices that were previously auto-provisioned

To disallow DPS access in a group certificate setup, one would create an individual device registration using the device certificate and then disable that device. However, in such a setup the device certificate might not be available as that is generated with the intermediate certificate. How does one create this individual device registration in this case?

You may be interested to read this document: Disallow specific devices in an enrollment group

Is the device certificate actually used as TLS client authentication or is device authentication something built on top of of TLS?

This document talks about the DPS and TLS support: TLS support in Azure IoT Hub Device Provisioning Service (DPS)

What are the recommended validity periods of CA, intermediate/group and device certificates in DPS/IoT hub?

The frequency in which you roll your certificates will depend on the security needs of your solution. Customers with solutions involving highly sensitive data may roll certificate(s) daily, while others roll their certificates every couple of years. Please see this document on How to roll X.509 device certificates

What is the recommended strategy regarding device certificates if devices could be offline for longer (5 years and more perhaps) periods of time in which there might be no way of updating (client) certificates?

Please see this document : Understand extended offline capabilities for IoT Edge devices, modules, and child devices, for the certificate management, again it depends on the security needs of your solution.

Please comment in the below section if you need any further help in this matter, happy to help.

If the response is helpful, please click "Accept Answer" and upvote it.

Answer 2

Hello @QuantumCache

My apologies for the late response, and thank you for the information provided. Regarding DPS and certificate management i think its mostly clear now : The DPS will search the chain up to the first certificate it can validate and if that certificate is valid, the device will be allowed provision and if its invalid or disabled it will not be allowed to provision. This means that if the intermediate certificate is valid but its 'parent' certificate is not, the device will be allowed to provision. Is that correct?

You may be interested to read this document: Disallow specific devices in an enrollment group

This specifies what to do to block a device (make an individual device registration) but not how to obtain this registration if the device certificate was generated/signed by an intermediate certificate. How would one in that case obtain the device certificate to make this registration?

This document talks about the DPS and TLS support: TLS support in Azure IoT Hub Device Provisioning Service (DPS)

It does not say however if the device certificate is actually used in the TLS client authentication step. For now i'm assuming it is.

Please see this document : Understand extended offline capabilities for IoT Edge devices, modules, and child devices, for the certificate management, again it depends on the security needs of your solution.

This article is about a setup using an IoT Edge gateway device. In our setup we are not using a gateway.

One other question that came up during testing:
The device when connecting to the DPS service should provide the Scope ID of the DPS service. Is this Scope ID changed every time the DPS service is (re)created? That is, if a device was offline for a longer period of time, could the DPS ID Scope have changed if the DPS service was deleted and re-deployed in Azure?