Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Device certificate issuance is the process by which devices request and receive a certificate as part of provisioning. Azure Device Registry (ADR) generates and issues a new X.509 certificate to your IoT devices during provisioning. This article explains the responsibility of a device to send a Certificate Signing Request (CSR), how ADR and Device Provisioning Service (DPS) work together to issue certificates at scale, and how IoT Hub trusts the issued certificates.
Important
Azure IoT Hub with ADR integration and Microsoft-backed X.509 certificate management is in public preview and isn't recommended for production workloads. For more information, see the FAQ: What is new in IoT Hub?
How device certificate issuance works
The following steps describe the end-to-end issuance flow:
- The IoT device connects to the DPS endpoint and authenticates by using its pre-configured onboarding credential, such as a symmetric key, X.509 certificate, or Trusted Platform Module (TPM). As part of this registration call, the device sends a certificate signing request (CSR) that includes the device's public key and its registration ID.
- DPS assigns the IoT device to an IoT Hub based on the enrollment configuration.
- The device identity is created in IoT Hub and registered to the ADR namespace. The CSR is forwarded to the unique PKI assigned to the ADR Namespace. The PKI validates the request and forwards it to the policy linked to the DPS enrollment.
- The policy's issuing CA signs and issues the operational certificate.
- DPS returns the issued certificate and IoT Hub connection details to the device.
- The device authenticates with IoT Hub by presenting its full certificate chain.
Certificate signing request requirements
When a device provisions or reprovisions, it sends a CSR to DPS. DPS expects the CSR to meet the following requirements:
- Format: Base64-encoded distinguished encoding rules (DER) following the public key cryptography standards (PKCS) #10 specification. Privacy-enhanced mail (PEM) headers and footers can't be included.
- Common name (CN): The CN field must exactly match the device's DPS registration ID.
- Key algorithm: Elliptic curve (EC) key using the NIST P-384 curve. RSA keys aren't supported in the current preview.
For implementation examples, see DPS device SDK samples.
Cryptographic algorithms
Certificate management uses the following cryptographic standards for all certificates issued by a policy:
| Property | Value |
|---|---|
| Key algorithm | ECC (ECDSA) |
| Curve | NIST P-384 (secp384r1) |
| Hash algorithm | SHA-384 |
| Key storage | Azure Managed HSM |
ECC with P-384 offers equivalent security to RSA at much smaller key sizes. This algorithm produces smaller certificates, faster TLS handshakes, and lower power consumption on constrained IoT devices.
IoT Hub trust and credential sync
For a device to authenticate with IoT Hub by using its issued certificate, IoT Hub must trust the issuing CA that signed the device certificate. ADR manages this trust through credential sync, which pushes the issuing CA certificate from ADR to your linked IoT Hubs.
To run credential sync manually, use the following Azure CLI command:
az iot adr ns credential sync --namespace <namespace> -g <resource-group>
IoT Hub stores the issuing CA certificate and uses it to validate the certificate chain that your devices present during TLS authentication.