Edit

Share via

X.509 certificate attestation

  • Article

This article describes the concepts involved when provisioning devices using X.509 certificate attestation in the Device Provisioning Service (DPS). This article is relevant to all personas involved in getting a device ready for deployment.

X.509 certificates can be stored in a hardware security module HSM.

Tip

We strongly recommend using an HSM with devices to securely store secrets, like the X.509 certificate, on your devices in production.

Understand the X.509 certificate chain

Using X.509 certificates as an attestation mechanism is an excellent way to scale production and simplify device provisioning. X.509 certificates are typically arranged in a certificate chain of trust in which each certificate in the chain is signed by the private key of the next higher certificate, and so on, terminating in a self-signed root certificate. This arrangement establishes a delegated chain of trust from the root certificate generated by a trusted certificate authority (CA) down through each intermediate certificate to the final certificate installed on a device. To learn more, see Device Authentication using X.509 CA Certificates.

Often the certificate chain represents a logical or physical hierarchy associated with devices. For example, a manufacturer might create the following certificate hierarchy:

  • A self-signed root CA certificate begins the certificate chain.
  • The root certificate generates a unique intermediate CA certificate for each factory.
  • Each factory's certificate generates a unique intermediate CA certificate for each production line in the factory.
  • The production line certificate generates a unique device (end-entity) certificate for each device manufactured on the line.

To learn more, see Conceptual understanding of X.509 CA certificates in the IoT industry.

Root certificate

A root certificate is a self-signed X.509 certificate that represents a certificate authority (CA). It is the terminus, or trust anchor, of the certificate chain. Root certificates can be self-issued by an organization or purchased from a root certificate authority. The root certificate can also be called a root CA certificate.

Intermediate certificate

An intermediate certificate is an X.509 certificate that has been signed by the root certificate (or by another intermediate certificate with the root certificate in its chain) and can also sign new certificates. The last intermediate certificate in a chain signs the leaf certificate. An intermediate certificate can also be called an intermediate CA certificate.

Intermediate certificates are used in various ways. For example, intermediate certificates can be used to group devices by product lines, customers purchasing devices, company divisions, or factories.

Imagine that Contoso is a large corporation with its own Public Key Infrastructure (PKI) using the root certificate named ContosoRootCert. Each subsidiary of Contoso has their own intermediate certificate that is signed by ContosoRootCert. Each subsidiary uses their intermediate certificate to sign their leaf certificates for each device. In this scenario, Contoso can use a single DPS instance where ContosoRootCert is a verified certificate. They can have an enrollment group for each subsidiary. This way each individual subsidiary doesn't have to worry about verifying certificates.

End-entity "leaf" certificate

A leaf certificate, or end-entity certificate, identifies a certificate holder. It has the root certificate in its certificate chain and zero or more intermediate certificates. A leaf certificate is not used to sign any other certificates. It uniquely identifies a device to the provisioning service and is sometimes referred to as a device certificate. During authentication, a device uses the private key associated with its certificate to respond to a proof of possession challenge from the service.

Prepare certificates

Devices use two different types of certificates when they connect to IoT Hub through DPS. When preparing your device, make sure you have all the proper certificates created and added to the device before connecting.

  • Public root certificates: All devices need a copy of the public root certificates that IoT Hub, IoT Central, and Device Provisioning Service use to authorize connections.
  • Authentication certificates: X.509 certificates are the recommended method for authenticating a device identity.

Required public root certificates

Azure IoT devices use TLS to verify the authenticity of the IoT hub or DPS endpoint they're connecting to. Each device needs a copy of the root certificate that IoT Hub and DPS use. We recommend that all devices include the following root CAs in their trusted certificate store:

  • DigiCert Global G2 root CA
  • Microsoft RSA root CA 2017

For more information about recommended certificate practices, see TLS support.

Authentication using X.509 certificates

The provisioning service exposes two enrollment types that you can use to control device access with the X.509 attestation mechanism:

  • Individual enrollment entries are configured with the device certificate associated with a specific device. These entries control enrollments for specific devices.
  • Enrollment group entries are associated with a specific intermediate or root CA certificate. These entries control enrollments for all devices that have that intermediate or root certificate in their certificate chain.

A certificate can be specified in only one enrollment entry in your DPS instance.

Mutual TLS support

When DPS enrollments are configured for X.509 attestation, mutual TLS (mTLS) is supported by DPS.

DPS encryption algorithm requirements

The Device Provisioning Service only accepts X.509 certificates that use either the Rivest-Shamir-Adleman (RSA) algorithm or the Elliptic Curve Cryptography (ECC) algorithm for encryption. ECC and RSA provide equivalent levels of encryption strength, but ECC uses a shorter key length.

If you use ECC methods to generate X.509 certificates for device attestation, we recommend the following elliptic curves:

  • nistP256
  • nistP384
  • nistP521

DPS certificate naming requirements

Leaf certificates used with individual enrollment entries must have the subject common name (CN) set to the registration ID. The registration ID identifies the device registration with DPS and must be unique to the DPS instance (ID scope) where the device registers.

For enrollment groups, the subject common name (CN) sets the device ID that is registered with IoT Hub. The device ID will be shown in the Registration Records for the authenticated device in the enrollment group. For individual enrollments, the device ID can be set in the enrollment entry. If it's not set in the enrollment entry, then the subject common name (CN) is used.

To learn more, see Authenticate devices signed with X.509 CA certificates.

DPS device chain requirements

When a device is attempting registration through DPS using an enrollment group, the device must send the certificate chain from the leaf certificate to a verified certificate. Otherwise, authentication fails.

For example, if only the root certificate is verified and an intermediate certificate is uploaded to the enrollment group, the device should present the certificate chain from leaf certificate all the way to the verified root certificate. This certificate chain would include any intermediate certificates in-between. Authentication fails if DPS cannot traverse the certificate chain to a verified certificate.

For example, consider a corporation that uses the following device chain for a device.

Diagram that shows an example device certificate chain.

In this example, the root certificate is verified with DPS, and intermediate2 certificate is uploaded on the enrollment group.

Diagram that highlights the root and intermediate 2 certificates as being uploaded to DPS.

If the device only sends the following device chain during provisioning, authentication fails. Because DPS can't attempt authentication assuming the validity of intermediate1 certificate.

Diagram that shows a certificate chain failing authentication because it doesn't chain to the root.

If the device sends the full device chain as follows during provisioning, then DPS can attempt authentication of the device.

Diagram that shows a successful device certificate chain.

DPS order of operations with certificates

When a device connects to the provisioning service, the service walks its certificate chain beginning with the device (leaf) certificate and looks for a corresponding enrollment entry. It uses the first entry that it finds in the chain to determine whether to provision the device. That is, if an individual enrollment for the device certificate exists, the provisioning service applies that entry. If there isn't an individual enrollment for the device, the service looks for an enrollment group that corresponds to the first intermediate certificate. If it finds one, it applies that entry; otherwise, it looks for an enrollment group for the next intermediate certificate, and so on, down the chain to the root.

The service applies the first entry that it finds, such that:

  • If the first enrollment entry found is enabled, the service provisions the device.
  • If the first enrollment entry found is disabled, the service doesn't provision the device.
  • If no enrollment entry is found for any of the certificates in the device's certificate chain, the service doesn't provision the device.

Each certificate in a device's certificate chain can be specified in an enrollment entry, but it can be specified in only one entry in the DPS instance.

This mechanism and the hierarchical structure of certificate chains provides powerful flexibility in how you can control access for individual devices and groups of devices. For example, imagine five devices with the following certificate chains:

  • Device 1: root certificate -> certificate A -> device 1 certificate
  • Device 2: root certificate -> certificate A -> device 2 certificate
  • Device 3: root certificate -> certificate A -> device 3 certificate
  • Device 4: root certificate -> certificate B -> device 4 certificate
  • Device 5: root certificate -> certificate B -> device 5 certificate

Initially, you can create a single enabled group enrollment entry for the root certificate to enable access for all five devices. If certificate B later becomes compromised, you can create a disabled enrollment group entry for certificate B to prevent Device 4 and Device 5 from enrolling. If still later Device 3 becomes compromised, you can create a disabled individual enrollment entry for its certificate. This revokes access for Device 3, but still allows Device 1 and Device 2 to enroll.