Azure IoT Edge & Certificates

Question

We would like to deploy a few thousand IoT devices on our internal network and connect them to Azure IoT hub via IoT Edge as a transparent gateway (using MQTT).

Reading this Understand how Azure IoT Edge uses certificates it would seem that I need my own root CA, so I need to set up and manage my own internal PKI infrastructure (or pay a fortune for an enterprise managed CA service from a 3rd party). Is that correct?

My alternative is to add my own MQTT server module and not use the "transparent" gateway capability, but then I forego C2D functionality as a module can't receive C2D messages.

Are my assumptions above correct or misinformed?

Answer 1

We went the route of standing up our own internal CA for IoT Hub activity.
We created the Root CA and an intermediate CA and then deployed it to the IoT Edge.
We provided the intermediate certificate and private key (we had to remove the passcode) to the IoT Edge We sent the Root cert to the device manufacturer.

Answer 2

(FYI - I'm the author of the doc you link to.. :-) ) There is not a requirement to use a full PKI infrastructure or public certs (like Digicert). The main requirement is that your leaf IoT devices trust the certificate that IoT Edge returns when your leaf devices attempt to connect. The easiest way to do this is to use a public CA (digicert, etc) or, in an enterprise environment that already has PKI infrastructure, which may already be trusted by devices in the enterprise. But neither of those are a requirement. The requirement is to get the leaf to trust the root cert from which the Edge cert is generated, which can be a self-signed root cert generated from openssl, etc (like our scripts do). The downside of that is that it's now up to you to both secure the private half of that cert to keep bad actors from getting it, but most importantly, it's up to you to get that cert(public) distributed out to, and trusted by, your leaf devices. Depending on the OS of our leaf devices, that may be easier (e.g. Windows group policy, linux scripts, etc) or much harder (e.g. embedded OS). But the key point there is that it's possible to just use self-signed certs, you are just then on the hook for getting the leaf devices to trust them by getting that self-signed root cert into the devices trusted root ca list (which is both OS and programming language dependent).

Also, there is no requirement to have an intermediate cert between the root cert and your device ca cert (our scripts just do this to show a 'typical' environment). However, the device ca cert itself is 'technically' an intermediate (it's a 'signing' cert).

Answer 3

Azure's GitHub has some files to help get started with your own certs from a development/testing perspective, but if you explore those files a little bit you might also be able to leverage that work to make long-lived certs that could meet your production needs.

This needs to be done very cautiously, though; you'd be making powerful security "keys" that need to be carefully protected.