IoT certificate manager

Overview

IoT certificate manager provides complete control of the x.509 device certificate lifecycle removing the headaches of manually managing the renewal of the credentials on thousands of devices.

It leverages the Root of Trust in the u-blox module and a secure dedicated channel to automate all of the operations necessary  to maintain fresh, valid device authentication for IoT platforms, even in challenging scenarios where credential replacement is required every month in big fleets.

Designed and optimized for IoT environments, it removes the errors that can occur when manually operating on large IoT deployments, freeing resources for other activities.

Managing the lifecycle

u-blox Zero Touch Provisioning (ZTP)  provides an enormous advantage at the beginning of device life by simplifying and automating the tasks required to create and inject credentials in the device. While traditionally these operations are done on production line, causing additional costs due to maintenance of dedicated systems and error recovery, u-blox ZTP performs all the steps for X.509 device certificate generation (public and private key generation, certificate generation and signature with Root CA and finally the Over the Air provisioning) autonomously when the device is in the field. Of course It can be done during production line as well if internet connectivity is provided to the module.

ZTP provides up to 15 private Certificate Authorities for each Thingstream domain without the upfront investment and ongoing maintenance costs of operating your own private CA. It allows customers to be more agile by providing APIs and automatic functions to generate and deploy private certificates programmatically to address every scenario using different validity periods.

During the device lifetime, to keep an adequate level of security for the device authentication and for the integrity of your data in motion, you need to maintain the device credentials (certificates) to connect to your preferred IoT platform.

The u-blox IoT certificate manager  service lets you easily address all the related operations that would otherwise become very complex and time consuming even for few tens of devices.

It provides full visibility and lifecycle control over all digital certificates and keys in your IoT environment. It automatically keeps tracks of  each device certificate expiration, renewing it in advance without any manual action avoiding service interruption.

Ten years of device life is a very long time during which a security incidents could happen because of the increasing number and complexity of attacks. For this reason it is important to support your business  with a solution that allows you to :

u-blox's smart approach  allows speed, flexibility, and scale for securing today's complex IoT environments while future-proofing your business against future threats. 

Pre-requisites

To use the IoT certificate manager service  you need:

Note: the IoT Certificate Manager is applicable to X.509 certificates generated using the u-blox Zero Touch Provisioning feature and not for certificates generated through third party tools or software.  Before using the IoT Certificate Manager service the device certificate must be generated and provisioned using u-blox Zero Touch Provisioning.

Service activation and billing

The first action is to activate the service using the Security Service section of the Thingstream portal.  You can activate the service by selecting the proper plan either at Device Profile level or at Thing level. 

Details of the available price plans can be found on our pricing page.

For initial testing we suggest to use  IoT certificate manager developer plan.  Once you are ready for the deployment in production, you can simply switch to one of the commercial plans.

Use cases

Certificate renewal

When an X.509 certificate is created, you shall define the validity period. The recommended validity period  of a device certificate has dramatically changed in the last years. While in the past a validity period of 10 years was acceptable with the main purpose to decrease the operational effort to renew it, nowadays because of the tremendous increase in cyber attacks,  it is widely recognized by security experts that validity should not exceed 1 year, even for businesses that are not dealing with sensitive data. Regulation authorities are now moving to even shorter periods, close to 3 months, to further improve security levels. 

With these recommendations,  constantly extending the certificate validity on each device is a tremendous effort that cannot be addressed manually even for small fleets of hundreds of devices with a validity period of 12 months.

With IoT Certificate Manager you can:

Note: with renewal the  new certificate use the same key pair (private and public keys, that are unique for each device) generated during the initial Zero Touch Provisioning. If you also want to replace the key pair, you need to update the certificate as explained in the next section.

The certificate renewal API implements generation, signature and provisioning in the device of the new certificate. If you are using Azure or AWS and the configurations suggested in our guides, the re-provisioning of the new certificate in those platforms happens automatically at every renewal without the need to implement any additional logic.

The previous certificate is automatically removed from the device but not from the IoT platform.

Each certificate renewal is counted as a billing event, only when the renewal effectively happens in the device, and is charged accordingly to your plan.

Note: if you need to manually force the certificate renewal triggering a security heartbeat on the device (after having issued the /ztp/devicecertificate/renew),  it is suggested to wait at least 5 mins before checking the new certificate because of the protection mechanism implemented to prevent flooding (see Security Heartbeat section on Getting started guide)

Update certificate

If your device certificate has been compromised or you want an enhanced level of security, you can update the device certificate with /ztp/devicecertificate/update API that triggers the automatic generation of:

The API can be applied to a list of devices at the same time, and triggers the whole re-provisioning process as described for certificate renewal.  

Note: the update procedure needs two Security Heartbeat. The new certificate is provisioned after the second Heartbeat 

Note: as for the  certificate renewal  it is suggested to wait at least 5 mins , before checking the new certificate, in case you need to manually force the certificate renewal with a a security heartbeat on the device(see Security Heartbeat section on Getting started guide)

Each certificate update is counted as a billing event, only when the update effectively happens in the device, and is charged accordingly to the selected plan.

Delete certificate

If you no longer need the certificate in the device, you can maintain security by removing it for free, using the /ztp/devicecertificate/delete API. 

NOTE: this action does not remove the certificate from the IoT platform (Azure, AWS, etc.).

Replace Root CA certificate

There are some use cases where it is necessary to replace the Root CA certificate used to sign the device certificate.  For example:

This action can be extremely complex and time consuming if performed on a significant number of devices, or when continuously done as part of a test-deployment process, because you need to repeat the whole process of certificate generation, signing and provisioning. 

By using the /ztp/devicecertificate/rootca/transfer API you can automate the entire procedure specifying the list of devices (using the RoTPublicUID identifier) that needs to be moved.

Each certificate transfer is counted as a billing event, only when the transfer effectively happens in the device, and is charged accordingly to the selected plan.

Certificate revocation

Certificate revocation is the action of invalidating the certificate before the scheduled expiration date so that it can no longer used by the device for authentication and (D)TLS sessions. A certificate should be revoked immediately when its private key shows signs of being compromised. It should also be revoked when the domain for which it was issued is no longer operational.

If you are using the certificate in sensitive business applications you may want a way to revoke that certificate to invalidate it immediately if you have the feeling that it is misused.  

To revoke a certificate

NOTE: certificate revocation does not remove the certificate in the device. This action can be performed using the previously described API.

Certificate revocation is not charged.

Certificate Revocation List

A Certificate Revocation List (CRL) is a list of digital certificates that have been revoked by the issuing Certificate Authority (CA) before their scheduled expiration date and should no longer be trusted. CRL is a sort of backlist for certificates and is used by various endpoints (for example your IoT platform) to verify whether a certificate is valid and trustworthy.  

You can use the /ztp/rootca/crl/get API to get a list of the certificates revoked using the certificate revocation API. 

CRL is not subject to charging

Notifications

To keep device certificate lifecycle status under control  you can subscribe to the main events, like certification expiration and renewal,  using the dedicated webhook  /notification/webhook/create.

Notifications are not subject to charging

Invoicing

Invoices are raised on the 1st of each month and will include usage for any services configured via the Thingstream platform. Only completed subscriptions will be included so a plan which starts on 5th May, renewing on 5th June, would be included in the invoice raised on 1st July.  Any usage from the renewed plan would not be invoiced until 1st August.

Invoices are sent by email from accounts@thingstream.io.  Please add this address to your safe senders list to avoid invoices being lost in your junk folder.

Availability

IoT certificate manager service is available from the following FW version an subsequent releases:


Reference documentation