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. This article explains the responsibility of a device to send a certificate signing request (CSR), how Azure Device Registry (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 Azure Device Registry integration and Microsoft-backed X.509 certificate management is in public preview and isn't recommended for production workloads. For more information, see 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 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.
Upon successful validation of the onboarding credential, the device identity is created in ADR and is allocated to the appropriate IoT Hub based on the enrollment configuration.
DPS forwards the CSR to the certificate authority (CA) that you created in ADR and referenced in the DPS enrollment. The CA validates the request and then issues a signed X.509 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. For implementation guidance, see Unified Azure IoT SDKs (preview) for IoT Hub and Azure Device Registry.
Cryptographic algorithms
Certificate authorities you create in Azure Device Registry use the following cryptographic standards for all certificates they issue:
| 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 CA sync
For a device to authenticate with IoT Hub using its issued certificate, IoT Hub must trust the intermediate CA that signed the device certificate. When you create the CA, ADR automatically pushes the public CA certificate to your linked IoT Hubs. IoT Hub stores the intermediate CA certificate and uses it to validate the certificate chain that your devices present during TLS authentication.
Get started with device certificate issuance
IoT devices can request device certificates from ADR by using standard device workflows. To get started, see Unified Azure IoT SDKs (preview) for IoT Hub and Azure Device Registry.
