In a previous post, I showed you how to register a device with Azure’s Device Provisioning Server (DPS) over raw MQTT. A reader/commenter asked how the process would differ if we used x.509 certificate based authentication vs. the SAS-token based authentication that the article was based on.
Since it’s inevitable that I’ll run across this in a customer situation, I thought I’d tackle it. Based on the knowledge from the previous article, as well as my article on DPS over the REST APIs, it was pretty straightforward. The process was nearly identical except for a few fields in the connection information, specifically specifying the iothub root cert, the device cert/key, and leaving off the SAS token. I’ll cover the details below.
Generating Certs
The steps for generating the device certificates and creating the enrollment in DPS is the same process as outlined in my DPS over REST API article. Specifically the sections titled “Prep work (aka – how do I generate test certs?)” and “X.509 attestion with individual enrollments- setup”, so I won’t repeat them here… For the screenshots below, I called my enrollment registration id ‘dpstestdev01’.
The only other thing you need is the IoT Root CA cert. This is the Baltimore-based root ca cert from which all the IoT Hub and DPS “server-side” TLS certificates are generated. The client needs this to validate that it is indeed talking to the genuine microsoft endpoint and not a ‘man in the middle’. The easiest way to get this cert, is to open this file from the Azure IoT C SDK, copy everything from (and including) line 23 to (and including) line 43, then strip out the quotes at the beginning and end of each line, and strip off the ‘\r\n’ off the ends. Save the file with a .pem extension. We will call that the “DPS-root-CA” cert.
Client Setup
You can leverage any MQTT 3.1.1 client to talk to DPS, however, like in previous articles, I’m going to use MQTT.fx, which is an excellent MQTT GUI tool for ‘manually’ doing MQTT. It allows you to get a really good feel for what’s happening under the covers without writing a bunch of code.
Through a series of screenshots below, I’ll show you my configuration.
The first step is to open Mqtt.Fx, click on the little ‘gear’ button next to the Connect button, and in the bottom right, click on the “+” button to create a new connection. You can call it anything (I called mine ‘dpscert’ in the screenshots below)
This screenshot shows the ‘general’ settings…
- The type is MQTT Broker
- The broker address is the global DPS endpoint (global.azure-devices-provisioning.net)
- The port is the MQTTS (tls) port 8883
- The client ID is the ‘registration id’ from DPS, specifically in this instance is the CN/Subject name you used for your device cert when you generated it
- the only other change from the defaults is to explicitly choose MQTT version 3.1.1
This screenshot shows the user credentials. For DPS, the user-id is of the form of:
{idScope}/registrations/{registration_id}/api-version=2019-03-31
where {idScope} is the idScope of your DPS instance.
Note that, unlike the SAS-Token case, the password is BLANK for x.509 authentication.
This screenshot is the most important one and the biggest difference from the SAS-Token case.
- Make sure you explicitly select TLS version 1.2 (we don’t support older versions)
- in our use case, we are using self-signed certificates, so choose that option
- For the “CA files”, this the DPS-root-CA cert we captured from github earlier. (the baltimore root cert)
- For the Client Certificate file, this is the device certificate we created earlier
- For the Client Key file, this is the private key for the device cert that we generated earlier.
- Make sure and check the “PEM formatted” checkbox, as that’s the format our certs are in.
All the other tabs are just left default.
Click Ok to close this dialog. Click the “Connect” button to connect to DPS.
From this point on, you subscribe and publish exactly like you did in the previous article and/or as specified in the official DPS documentation here.
Enjoy – and as always, let me know if you run into any issue. Hit me up on Twitter (@BamaSteveB), email (steve.busby ( at ) microsoft.com) or in the comments below.