Apr 172018
 

I had some problems with the various PowerShell and bash samples in the Microsoft documentation on how to create a certificate chain for use with the Azure IoT Hub Device Provisioning Service. Why did it have to be so complicated to get started with X.509 based authentication towards DPS?

What if I wrote my own program to create the root certificate, some intermediaries, and could also create device certificates? I set out to do that.

In the end, it turned out to be not that hard. .NET Core 2.0 has some new classes to help with certificate requests, so it isn’t necessary to call into native Windows libraries or use an extra library like BouncyCastle etc. Continue reading »

Apr 092018
 
Internet of Things (CC BY 3.0 - https://www.iconfinder.com/samatodedara)

As you may have read, I made a previous blog post, which described how to create a Certificate Authority root certificate and a chain of intermediates using a Microsoft provided PowerShell sample.

In that post, I also showed how to create a Device Enrollment Group within the Device Provisioning Service (DPS). That’s all very nice, but the purpose of IoT Hub and the DPS is to connect devices. So let’s go ahead and do that.

First of all, the device needs its own certificate, which is trusted by the root CA certificate configured in the DPS device enrollment group.

Continue reading »

Apr 042018
 

When using group enrollments with the Azure IoT Hub Device Provisioning Service (DPS), it is necessary with a X.509 certificate infrastructure.

At the very least, it is necessary to have a root Certificate Authority (Root CA) that can be used to sign device certificates.

The devices authenticate with the DPS using a device certificate which is signed by the root CA. That way, the DPS can verify that the device is allowed to connect to the DPS and be provisioned for communicating with the Azure IoT Hub.

It is better if the root CA is used to sign an intermediate CA certificate, which in turn can be used to sign the device certificates. Depending on the need, there can be a chain of intermediates.

The reason for the intermediate certificates is that it makes it easier to see who or what signed a device certificate. If it should become necessary to revoke the intermediate, only a subset of device certificates will stop functioning.

While it is possible to use a public CA as the root CA, it is not necessary. It is possible to create a root CA certificate on your own and use that for DPS. The whole area of X.509 certificates is complicated, so it may be a good idea to consult with professionals in the field before rolling your own CA.

This blog post is the first part of a series that will include C# code to create a certificate chain. The finished project also includes a sample showing how to let an IoT Hub device provision itself without factory-installed certificates or Hardware Security Module based tokens.

Continue reading »