Setting up your own CA

When your devices connect to Device Management, they use a (Datagram) Transport Layer Security (TLS/DTLS) device certificate to prove they are linked to your Device Management account.

A certificate authority (CA) that your Device Management account trusts must generate and sign the device certificate.

You can sign your device certificates using the built-in CA services provided by Factory Configurator Utility (FCU), or you can use a third-party CA, with or without FCU.

Creating a CA certificate

CA certificate requirements

Device Management supports X.509 v3 CA certificates in PEM format.

Your CA certificate must have the following properties:

Note: If you use FCU with your own certificate authority, do not populate the X.509 properties in the certificate-authority section of the fcu.yml configuration file.

Example: Creating a CA certificate use OpenSSL

1. Create a private key:

   openssl ecparam -out CA_private.pem -name prime256v1 -genkey
   

2. Configure the CA certificate:

   (echo '[req]'; echo 'distinguished_name=dn'; echo 'prompt=no'; echo '[dn]'; echo 'CN=CA'; echo '[ext]'; echo 'basicConstraints=CA:TRUE') > ca.cnf
   

3. Create a self-signed certificate:

   openssl req -key CA_private.pem -new -sha256 -x509 -days 12775 -out CA_cert.pem -config ca.cnf -extensions ext
   

Warning: We've provided OpenSSL commands for reference only. You must adapt the commands to your own production setup and security requirements.

Creating device keys and certificates

If you use your own CA, you must ensure that all device keys and certificates are in the appropriate format and contain correct information.

Note: We recommend you always use FCU for generation of keys and certificates. You can use FCU as your CA without using it at other parts of the provisioning process.

Bootstrap device key and certificate requirements

Factory assigned device credentials (private key and certificate) that the device uses to authenticate to the bootstrap service, as required by the LwM2M 1.0 standard.

Notes

• The Common Name (CN) field of the certificate is the individual device's endpoint name (which is the device's unique identifier). It is provided in the endpoint-name parameter of the inject command, as explained in the Provisioning information section.
• For certificate chains, only the PEM format is supported.
• When using a certificate chain, the length of the chain stored on the device depends on the device-certificate-chain-depth configuration parameter.
• If FCU generates or signs the certificate, the certificate chain is derived from the FCU certificate chain.

Security mode

Device Management supports both LwM2M certificate-based security modes:

• Certificate (mode 2)

  In Certificate mode, the bootstrap server generates and provisions a LwM2M key and certificate to the device.

  Use this mode for code-size-constrained devices without Device Management client's EST feature enabled or for devices without a high-quality entropy source.

• Certificate with EST (mode 4)

  In Certificate with EST mode, the device generates its own LwM2M private key and corresponding Certificate Signing Request (CSR). The CA responsible for signing LwM2M credentials receives the CSR and returns the signed certificate to the device.

  Use this mode for devices with a true random number generator (TRNG) or equivalent for the enhanced security that comes from not having the private key leave the device.

The device requests a specific security mode through a custom field in its X.509 certificate's v3 extension section with the OID 1.3.6.1.4.1.4128.201:

For an example of how to set up Certificate with EST mode, see Example: Generating a CSR for Certificate with EST (mode 4) security mode using OpenSSL.

LwM2M device key and certificate requirements

Factory assigned device credentials (private key and certificate) that the device uses to authenticate to LwM2M management service, as required by the LwM2M 1.0 standard.

Notes

• The Common Name (CN) field of the certificate is the individual device's endpoint name (which is the device's unique identifier). It is provided in the endpoint-name parameter of the inject command, as explained in the Provisioning information section.
• Organizational Unit (OU): Matches the account ID related to the device (provided as part of the lwm2m-server-uri in the FCU configuration).
• For certificate chains, only the PEM format is supported.
• When using a certificate chain, the length of the chain stored on the device depends on the device-certificate-chain-depth configuration parameter.
• If FCU generates or signs the certificate, the certificate chain is derived from the FCU certificate chain.

Example: Creating a device key and certificate using OpenSSL

1. Create a private key:

   openssl ecparam -out BootstrapDevicePrivateKey.pem -name prime256v1 -genkey
   

2. Convert private key to DER format:

   openssl ec -in BootstrapDevicePrivateKey.pem -out BootstrapDevicePrivateKey.der -outform der
   

3. Create a certificate signing request for the private key:

   openssl req -key BootstrapDevicePrivateKey.pem -new -sha256 -out BootstrapDeviceCsr.pem
   	-subj /CN=device_endpoint_name
   

4. Sign the certificate signing request with the CA key and certificate:

   openssl x509 -req -in BootstrapDeviceCsr.pem -sha256 -out BootstrapDeviceCert.der
   	-outform der -CA CA_cert.pem -CAkey CA_private.pem -CAcreateserial -days 3650
   

Warning: We've provided OpenSSL commands for reference only. You should adapt them to your own production setup and security requirements.

Example: Creating a certificate chain and device keys using OpenSSL

1. Create configuration for adding CA extensions:

   (echo '[ req ]'; echo 'distinguished_name=dn'; echo 'prompt = no'; echo '[ ext ]'; echo "basicConstraints = CA:TRUE"; echo "keyUsage = digitalSignature, keyCertSign, cRLSign"; echo '[ dn ]') > ca_config.cnf
   

2. Create private keys:

   openssl ecparam -out root_key.pem -name prime256v1 -genkey
   openssl ecparam -out intermediate_key.pem -name prime256v1 -genkey
   openssl ecparam -out BootstrapDevicePrivateKey.pem -name prime256v1 -genkey
   

3. Create the root self-signed certificate:

   (cat ca_config.cnf; echo 'CN = ROOT_CA';) > root.cnf
   openssl req -key root_key.pem -new -x509 -days 7300 -sha256 -out root_cert.pem -config root.cnf -extensions ext
   

4. Create an intermediate certificate:

   (cat ca_config.cnf; echo 'CN = INT_CA';) > int.cnf
   openssl req -new -sha256 -key intermediate_key.pem -out intermediate_csr.pem  -config int.cnf
   openssl x509 -sha256 -req -in intermediate_csr.pem -out intermediate_cert.pem -CA root_cert.pem -CAkey root_key.pem -days 7300 -extfile ca_config.cnf -extensions ext -CAcreateserial
   cat intermediate_cert.pem root_cert.pem > intermediate_chain.pem
   

5. Create the device certificate:

   1. Create a certificate signing request for the private key:

      (echo '[ req ]'; echo 'distinguished_name=dn'; echo 'prompt = no'; echo '[ dn ]'; echo 'CN = device_endpoint_name';) > device.cnf
      openssl req -key BootstrapDevicePrivateKey.pem -new -sha256 -out device_csr.pem -config device.cnf
      

   2. Sign the certificate signing request with the certificate chain key and certificate:

      openssl x509 -sha256 -req -in device_csr.pem -out device_cert.pem -CA intermediate_cert.pem -CAkey intermediate_key.pem -days 7300 -extensions ext -CAcreateserial
      

   3. Verify the chain:

      openssl verify -verbose -CApath no-such-dir -CAfile intermediate_chain.pem device_cert.pem
      

   4. Create the device certificate with chain:

      cat device_cert.pem intermediate_chain.pem > BootstrapDeviceCert.pem
      

Warning: We've provided OpenSSL commands for reference only. You should adapt them to your own production setup and security requirements.

Example: Creating a certificate for Certificate with EST (mode 4) security mode using OpenSSL

1. Create private key:

   openssl ecparam -out BootstrapDevicePrivateKey.pem -name prime256v1 -genkey
   

2. Create a certificate signing request for the private key:

   openssl req -key BootstrapDevicePrivateKey.pem -new -sha256 -out BootstrapDeviceCsr.pem
   	-subj /CN=device_endpoint_name
   

3. Create configuration for adding X.509 v3 extensions:

   (echo '[ v3_req ]'; echo '1.3.6.1.4.1.4128.201 = ASN1:INTEGER:0x04000000') > extensions.cnf
   

4. Sign the certificate signing request with the CA key and certificate:

   openssl x509 -req -in BootstrapDeviceCsr.pem -sha256 -out BootstrapDeviceCert.der \
       -outform der -CA CA_cert.pem -CAkey CA_private.pem -CAcreateserial -days 3650 \
       -extfile ./extensions.cnf -extensions v3_req
   

Warning: We've provided OpenSSL commands for reference only. You should adapt them to your own production setup and security requirements.

Configuring FCU to work with externally-supplied certificates

To configure FCU to bundle your externally-supplied Bootstrap or LwM2M device keys and certificates:

1. Use your CA to generate a device key and certificate.
2. In the fcu.yml configuration file, set the device-key-generation-mode parameter to externally_supplied.
3. Place your DTLS keys and certificates in a folder of your choice. Make a note of that location; you need to provide this path as a parameter when provisioning devices, as explained in the Keys, certificates, and configurations section.

Uploading the CA certificate to Device Management

To use a third-party CA, you must upload the CA certificate to your Device Management account. The certificate is then considered a trusted certificate in your account. If you do not upload a trusted certificate to your account, devices with a device certificate signed by your CA will not be able to connect to Device Management.

You can provide a self-signed certificate as a trusted certificate, and you can also provide additional intermediate certificates as trusted certificates, as part of a certificate chain. You can upload up to 10 certificates to your Device Management account.

Certificate chains are only available for commercial accounts.

Tip: We recommend uploading the CA certificate to Device Management when you set up your factory process, before your production devices come online. This enables you to test and verify the factory setup.