Azure-docs: Certificate renewal

[Sdelausnay]

I'm looking for documentation how the IoT Edge handles certificates rolling. I have found this document How to roll X.509 device certificates explaining how certificate rolling is performed for IoT Devices. A last step explains that the device needs to re-provisioned trough catching "unauthorized" errors or using a direct method. I can see how this works for an IoT Devices but how is it handled by the IoT Edge. Does he check automatically when you just replace the certificates in the path without having to restart the IoT Edge?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: e84a6cee-1817-54dd-c976-4be73862ea5e
• Version Independent ID: 33ff214c-484e-4e65-388b-cc9db450d56f
• Content: Roll X.509 certificates in Azure IoT Hub Device Provisioning Service
• Content Source: articles/iot-dps/how-to-roll-certificates.md
• Service: iot-dps
• GitHub Login: @wesmc7777
• Microsoft Alias: wesmc

[mike-urnun-msft]

@Sdelausnay Thank you for your feedback! We will review and update as appropriate.

[asergaz]

Hello @Sdelausnay let me start by sharing the following documentation that is part of iot edge docs:

• Create and provision an IoT Edge device using X.509 certificates
• Understand how Azure IoT Edge uses certificates
• Manage certificates on an IoT Edge device
• Azure IoT Edge security manager
• Install production certificates

From first doc:

• "Device identity certificates are only used for provisioning the IoT Edge device and authenticating the device with Azure IoT Hub. They aren't signing certificates, unlike the CA certificates that the IoT Edge device presents to modules or leaf devices for verification."
• "The config.yaml file stores your certificate and key information as file URIs." "Always restart the security daemon after updating the config.yaml file."

From second doc:

• "The device CA certificate is generated from and signed by the final intermediate CA certificate in the process. This certificate is installed on the IoT Edge device itself, preferably in secure storage such as a hardware security module (HSM). In addition, a device CA certificate uniquely identifies an IoT Edge device. The device CA certificate can sign other certificates."

From third doc:

• "If you don't provide your own production certificates when you install and provision IoT Edge, the IoT Edge security manager automatically generates a device CA certificate... also generates a workload CA certificate..." "For these two automatically generated certificates, you have the option of setting the auto_generated_ca_lifetime_days flag in config.yaml to configure the number of days for the lifetime of the certificates."

From fourth doc:

• "When the signed token or certificate nears expiration, it's the responsibility of the module to request a new certificate."

Therefore, you will need to reboot security daemon each time you update config.yaml. If you replace the certificates on the path directly you should not need to reboot IoT Edge.

For renewing the identity_cert you should follow the same process as an IoT Device described on the doc you opened this issue at.

For renewing the device_ca_cert you can't do it today using DPS, it will be up to the modules or leaf devices to add the new device_ca_cert to the trusted certificate root.

PS: For better understanding the configs on config.yaml see here. It helps understand better what is a device_ca_cert and identity_cert.

Hope it helps.
Thanks!

[Sdelausnay]

Hi @asergaz,

Thanks for the very clear and extensive response.

In the mean time, I have also been looking a bit further into it and you are confirming some of my findings. Just wanted to summarize here to see if I got every:

1. Certificate to perform the TLS communication with IoT Hub: This is part of the Device SDK used by the IoT Edge. If this one expires (I have checks, this would be in 2025), I would need to update the the device SDK or IoT Edge?
2. Device certificates for internal use with modules, etc.: I would need to catch this in a module to check if this certificate expires and take the required actions to update the certificates on the device. If I just replace them with the same name as the old, I would not need to restart anything and all should be fine for internal communication with modules and downstream devices (if they off course also receive updates)
3. DPS (Optional): using the identity certificate - I follow the guide you provided (Doc. 1) to update everything

Thanks already for the help!

Kr

[asergaz]

You are welcome, thank you!

1) I believe you mean "Baltimore Cybertrust Root" certificate will expire in 2025? That certificate is on your device's Trusted Root Certification Authority or if using the c-sdk is placed here and yes you need to update it in order to trust the IoTHub. IoTEdge new releases will take care of that hopefully, you just need to keep your device up-to-date with latest version of IoTEdge.

2) Exactly, please think of certificate expiration as a moment to validate that you are still connecting to IoTEdge and not something standing in the middle...

3) Not sure what you mean "to update everything" though as I mentioned, you cannot use DPS to provision leaf devices or modules. If you believe that's a good to have feature please add it here: https://feedback.azure.com/forums/907045-azure-iot-edge

Was a pleasure to help you :)!

We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

[Sdelausnay]

Hi @asergaz,

Sorry again to ask a followup question, I was busy with some other stuff but now the request ended up back on my desk. We have a solutions which uses IoT Edge at a lot of devices which are located on remote places. So for the first two certificates we were looking for best practices to keep everything working:

1. It is almost impossible to physically update IoT Edge on every device. Do you have examples how this can be done remotely with limited downtime and organized from a central place like the IoT Hub?
2. The device certificates: do you have any examples on this? I cannot integrate code in every module which checks if connection is still OK. I was thinking of building a separate module to perform certificate renewal but then I would need to have a separate communication to e.g., Key Vault and what if the device is out for some time and comes back up and in the mean time the certificate has expired? Or do we just use certificates at installation which will have a expiration time longer then the expected device life time?

Has nobody else had the same issues/question we are asking ourselves?

Thanks again for your help. Really keeping us busy this issue.

Kr,

Steven