Certificate authority options

Tip: If you are still in development, please see the developer certificate section.

Certificates and keys in Device Management

Certificates carry a signature that proves their source, a public key and identity information. If you trust the source, then you can trust the public key and identity.

We use certificates to establish identity trust, so your device can prove it is allowed to access your Device Management account, and your Device Management account can prove it is allowed to access the device. We also use certificates to verify that data (such as a firmware update) came from a trusted source.

Establishing trust between Device Management and devices

In order for your IoT device to communicate with Device Management, not only does your device need to trust Device Management, but Device Management needs to trust your device. To create this trust relationship, you will need to install certificates on both Device Management and the device. The following sections explain which certificates you need to use and when they should be used.

We consider devices using:

• Bootstrap mode where the device initially communicates with the bootstrap server (recommended).
• LwM2M mode where the device initially communicates with the LwM2M server.

For more information about these two modes, see the section about device onboarding and connection options.

Device initially communicates with bootstrap ("bootstrap mode")

In the factory, to allow:

• Device Management to trust the device during the bootstrap flow, give the device a certificate the FCU private key signed. Upload the FCU certificate or certificate chain, which signs the device bootstrap certificate, to your Device Management account using either the APIs or the portal. If the device was injected with a certificate chain, upload the rest of the chain, which signs the device certificate chain.
• The device to trust Device Management during bootstrap flow, give the device the bootstrap server CA certificate.

Note: You can use your private key and certificate, instead of the FCU private key. See the Setting up your own CA section of the Pelion Device Management Factory Provisioning documentation site.

During the bootstrap flow, to allow:

• Device Management to trust the device for the LwM2M flow. The device gets a new private LwM2M key, with a certificate signed by Device Management (which is implicitly trusted).
• The device to trust Device Management for LwM2M flow. The device gets the LwM2M Server CA certificate.

Note You can get the private LwM2M key signed by your third-party CA, instead of Device Management. See 3rd party CA for details.

Device initially communicates with LwM2M directly ("LwM2M mode")

If you have devices that use LwM2M mode, this section describes the certificates to use to establish trust between Device Management and the device. We recommend, where possible, to use the bootstrap mode instead.

In the factory, to allow:

• Device Management to trust the device for LwM2M mode, the device gets a private LwM2M key with a certificate signed by the FCU private key. Upload the FCU certificate or certificate chain, which signs the device LwM2M certificate, to your Device Management account using either the APIs or the portal. If the device was injected with a certificate chain, upload the rest of the chain, which signs the device certificate chain.
• The device to trust Device Management for LwM2M flow, the device gets the LwM2M Server CA certificate.

Note: You can use your own private key and certificate, instead of the FCU private key. See the Setting up your own CA section of the Pelion Device Management Factory Provisioning documentation site.

Establishing trust for the Update service

The device uses the Update authenticity certificate to verify the source of firmware images in update campaigns.

For more information, see the Update section.