Cumulocity IoT Feedback Portal
One method to authenticate devices to the platform is certificate-based authentication. But to enhance security, a growing number of standards and best practise guides are encouraging device manufacturers to issue certificates for their devices with short validity periods - one year or less. This creates two issues:
During the period that devices are connected, their certificates can expire, meaning that they are no longer trusted by Cumulocity.
Some devices may only become connected to Cumulocity some time after they are manufactured or arrive in the field, and by that time, the certificate may have expired.
In case 1, it would be helpful if Cumulocity could be used (e.g. by issuing an operation) to push updated certificates to devices. Updated certificates would have to be pulled from an issuing CA, or generated and signed by the platform using a key provided for the purpose.
In case 2, we require a workflow similar to the existing Device Registration workflow, whereby a device can connect and present an out-of-date certificate, and by manual exception, an authorised user can issue a replacement.
Hi Nikolaus. Thanks for your response. We also raised this topic in outline with the thin-edge.io team, so very happy to discuss the detailed implementation including them.
On the first point, our main concern is that we avoid the need for the device to contact another platform or gateway than Cumulocity to refresh its certificate, becuase in a number of cases our devices won't be able to do this. This also applies to our instances of Cumulocity Edge, which in general won't have access to other endpoints on the internet than Cumulocity. I'm not an expert, but I think this means that Cumulocity would need to fulfil the role of a Registration Authority (RA) according to RFC 3647, but also go further and issue certificates to devices on the upstream CA's behalf. Is this what the EST protocol acheives? Do you envisage an EST CA being offered as a App/Service within Cumulocity, or would it need to be provisioned separately?
In the second case, I think you are suggesting that two certificates could be used - a long-lived one for a manually mediated enrolment, but a second shorter-lived one that is used for ongoing authentication - is that correct? I'm not confident I understand the pros/cons of this approach, but it certainly sounds like it could work.
Hi Neil, thanks a lot for your feedback. Indeed we are working together with our partner Nexus on making certificate management easier for our customers and we would be very happy to engage closer with you on the topic.
With regards to your first point: We believe that the device should automatically renew its certificates in the background without the platform needing to instruct the device to do so. Together with our partner Nexus, we have implemented a PoC with thin-edge.io using the EST protocol for certificate creation and renewal. As part of this proof of concept implementation, the device automatically updates its certificate and in addition can be manually instructed through a Cumulocity operation to do so. Let's closer engage on this topic!
With regards to your second point: Our current point of view ist that in this case a device should restart the enrolment process from the very beginning. Any other scenario we see difficult to solve in a both generic and secure manner. A very typical scenario that we observe in the IoT market is that devices are equipped with a long-lived (typically longer than the device lifetime) birth/factory certificate. This certificate is used to enrol the device into the platform.