For testing, demo and development reasons, it can be useful (and a fair amount cheaper!) to use self-signed X.509 certificates when using the Azure Device Provisioning Service.
This guide is only for testing and demo purposes…
Please don’t use Self-Signed X.509 certificates in production!
This can involve a few steps and comes with a few pitfalls… This guide will hopefully help you navigate your way through that and get your Azure Device Provisioning (DPS) setup and IoT Devices provisioning nicely!
What we’re going to do is create some self signed X.509 certificates, create an Azure DPS instance and Group Enrolment, create a simulated device, provision it through our DPS and finally have it connect to an IoT Hub.
A word of caution… This is a long series of posts with lots of steps… However, there will also be a script available to just run for those who just want to get it done, rather than to learn why and how.
Contents:
- A Primer on DPS (This post!)
- Creating DPS and IoT Hub Instances and Linking Them
- Creating X.509 Certificates with OpenSSL
- Uploading to the Cloud
- Verifying X.509 Certificates (Proof of Possession)
- Creating X.509 Enrollment Groups
- Setting up a Simulated IoT Device (C#)
A Primer on Azure Device Provisioning Service (DPS)
What is Device Provisioning Service?
Let’s start with the basics… Before we write code or create Azure resources, you need to understand what DPS does and why it matters for your IoT deployment.
Azure IoT Hub Device Provisioning Service (DPS) is a helper service for IoT Hub that enables zero-touch, just-in-time provisioning to the correct IoT Hub without requiring human intervention.
The allocation of devices can be based on a set of rules including geographical location for latency, an evenly weighted distribution, a static configuration or a custom allocation based on pattern matching.
Why Use DPS?
You might be wondering: “Can’t I just register devices manually in IoT Hub?” You can, but let’s see why that doesn’t scale:
Traditional Approach (Manual Registration)
- Register each device manually in IoT Hub
- Hardcode connection strings in device firmware
- Difficult to reassign devices to different hubs
- Doesn’t scale beyond a few devices
DPS Approach (Zero-Touch Provisioning)
- Devices automatically register themselves
- No connection strings hardcoded
- Devices can be reassigned dynamically
- Scales to millions of devices
Key Benefits
Now that you understand the difference, here are the concrete advantages of using DPS;
- Scale: Provision thousands or millions of devices without manual intervention. Devices can self-register when they first come online.
- Security: No connection strings hardcoded in device firmware. Devices use cryptographic attestation (symmetric keys, TPM, or X.509 certificates) to prove identity.
- Flexibility: Devices can be reassigned to different IoT Hubs based on business logic, geolocation, or load balancing.
- Multi-tenancy: Different devices can automatically be directed to different IoT Hubs based on enrollment configuration.
Attestation Methods
Attestion is how devices prove their identity to DPS. Think of it like showing ID before boarding a flight. DPS supports three different “ID types”:
DPS supports three attestation mechanisms:
1. Symmetric Key
- Simplest method
- Uses shared secret (enrollment group key)
- Good for development and testing
- Less secure than certificate-based methods
2. TPM (Trusted Platform Module)
- Uses hardware security module
- Very secure
- Requires TPM chip on device
- Unique per device
3. X.509 Certificate (This is what we’ll focus on)
- Uses public key infrastructure (PKI)
- Industry standard for security
- Supports certificate rotation
- Scalable with enrollment groups
High-Level Provisioning Flow
┌──────────┐
│ Device │
└────┬─────┘
│
│ 1. Initial connection with attestation
│
▼
┌─────────────────┐
│ DPS │ 2. Validates attestation
│ │ 3. Determines target IoT Hub
└────┬────────────┘
│
│ 4. Returns assignment
│
▼
┌──────────┐
│ Device │ 5. Connects to assigned IoT Hub
└────┬─────┘
│
▼
┌─────────────┐
│ IoT Hub │ 6. Device is registered and ready
└─────────────┘
When to Use DPS
Use DPS when:
- Deploying many devices
- Devices need to be reassigned between hubs
- You want zero-touch provisioning
- Security is important (no hardcoded secrets)
- You need multi-tenancy support
Skip DPS when:
- Only a few devices (< 10)
- Devices never move between hubs
- Prototyping with connection strings is acceptable
- You don’t need automated provisioning
Next Steps
In the following sections, we’ll:
- Create DPS and IoT Hub instances
- Set up a complete X.509 certificate hierarchy
- Configure DPS to trust our certificates
- Create an enrollment group
- Provision a device using X.509 attestation
Next: Creating DPS and IoT Hub Instances >
The post Using Azure Device Provisioning Service with Self Signed X.509 Certificates – Part 1 first appeared on Pete Codes.
The post Using Azure Device Provisioning Service with Self Signed X.509 Certificates – Part 1 appeared first on Pete Codes.


