Certificate renewal process

Process overview

The process of renewing device certificates involves Pelion Device Management and Device Management Client. You can trigger the process by calling the Device Management API from the Device Management Portal, or from your device.

As part of this process, the device generates a new key in PKCS10 format, creates a certificate signing request (CSR) based on the existing certificate, and sends the CSR to Device Management.

Device Management sends the CSR to be signed by your third-party certificate authority (CA). By default, the internal Device Management CA signs LwM2M certificates; however, a third-party CA can also sign LwM2M certificates.

Device Management then sends the signed certificate back to the device in the field, or if a gateway is used, Device Management sends the signed certificate to the gateway device. If you use a third-party CA that supports providing a chain of trust, your device is provisioned with the full chain of trust.

For more details about the service- and device-initiated certificate renewal processes, see the certificate renewal tutorial.

Prerequisites

To enable certificate renewal, you must:

• Provision your devices with a key and certificate.
• Set up a third-party CA.
• Register your device.

Provisioning keys and certificates during device manufacture

You can provision several certificates to a device during device manufacture.

By default, during the factory provisioning process, you place a key and certificate on your device to enable TLS encryption during the bootstrap flow, as part of which the device connects to Device Management and gets its LwM2M service credentials.

In the field, you can renew:

• LwM2M certificates.

• Custom keys and certificates that you provision in the factory, including:

  • A custom generated certificate key pair.

  • A combination of custom certificate; private key; and, optionally, an externally-supplied public key configured with the same certificate name:

    • If you use FCU, you must set the same value for the name attribute of the certificate, private key, and (optional) public key, as shown in the example below:

        custom-properties:
        -
          type: certificate
          name: dlms
          data-file: <%= ENV['FCU_RESOURCES_DIR'] %>/dlms-cert.crt
        -
          type: private-key
          name: dlms
          data-file: <%= ENV['FCU_RESOURCES_DIR'] %>/dlms-priv.pem
        -
          type: public-key
          name: dlms
          data-file: <%= ENV['FCU_RESOURCES_DIR'] %>/dlms-pub-key.der
      

    • If you use the KCM kcm_item_store() API, you must set the same value for private_key_name, public_key_name, and custom_certificate_name.

Note: The name used for your custom certificates must adhere to the certificate name restrictions.

Setting up a third-party CA

To renew your own certificates - for example, DLMS or WiSUN - you must integrate with a third-party CA and configure it to use your custom certificate name.

Note: The name that you use for your custom certificates must match the certificate name defined during factory provisioning.

LwM2M certificates are available in Device Management Client and Edge. You don't have to configure a third-party CA for LwM2M certificates because Device Management uses its internal CA for them by default.

Notes:
• If you use a third-party CA for LwM2M certificates, you must also upload the CA certificate as a trusted certificate.
• You might also have to provide third-party CA certificate to other third-party services to which your device connects (like DLMS or WiSUN).

Registering your device

You must register the device to Device Management through the bootstrap process.