The certificates information type is optional for the product configuration file.

A device certificate is an important part of the product’s security because it provides it with an identity, that can be used to authenticate the device when connecting to a network or Cloud platform. You can define a certificate configuration object so that an X.509 certificate can be created by the Security Appliance for each device as they are provisioned.

To define a certificate configuration object you need a device certificate template. This template is similar to a standard X.509 certificate, with a two exceptions:

The Security Appliance generates a unique device certificate asymmetric key pair for each certificate being produced. The public part of this key pair is written into the device certificate. The private part is provisioned onto the device. Many of the values in the rest of the template are static and common to all device certificates. They are copied directly into the device certificate and are the same for all device certificates generated during the manufacturing run.

To define a certificate configuration object you also need a signing key, to sign the device certificate when the unique information is generated and written to the certificate. This signature authenticates the device’s identity. OrBIT currently supports two categories of signing keys, private asymmetric and self-signed.

A private asymmetric key of an intermediate certificate authority used in an OEM-specific Public Key Infrastructure (PKI) certificate chain will be used by the Security Appliance to sign the device certificate, linking the certificate to the OEM’s PKI infrastructure. Note that for products that require a Transport Layer Security (TLS)/Secure Socket Layer (SSL) connection, the full PKI chain might need to be provisioned to the device. In this situation, the OEM Root and Intermediate Certificates must be provisioned to the device, each as a dataBlock object, see Data blocks. This is the most robust way for ensuring product authenticity and is recommended for all users of the eSecIP Standard or Professional edition.

A self-signed key allows the device certificate to be signed with the device certificate’s own private key, that the Security Appliance generated when creating the device certificate. This provides a basic form of device identity, but the product will not have the robust attestation of a PKI infrastructure. Users of the eSecIP Basic edition, who can only use self-signed certificates, should be aware that this is intended only as a quick start. The OEM should consider upgrading to a full PKI infrastructure.

For all eSecIP editions, if production records are enabled, any device certificates are automatically added to the record along with the certificate’s public key as a separate entry.