Embedded devices fail to connect to blob.core.windows.net after certificate chain change. Is IoT Hub next?

Hello Kristoffer Wilhelmsson,

Please let me know if the issue persists after these checks. If you have any remaining questions or need additional details, I’ll be glad to provide further clarification or guidance. If the above steps resolve your issue, kindly confirm.

Thankyou!

So the question was if this new longer certificate chain will be deployed to IoT Hub as well. Will it?

It's not guaranteed that IoT Hub will follow the exact same chain-length change as Azure Storage. But certificate chain changes (especially intermediate updates) can happen over time as part of normal service operations

Recommended approach:

• Ensure devices trust the required root CA (DigiCert Global Root G2)
• Avoid strict limits on certificate chain depth or handshake size
• Avoid certificate pinning to intermediate certs

This will help keep devices resilient even if similar updates happen in the future.

Please confirm whether it's alright to close this thread?

Thankyou!

Am I then correct in understanding that there is no guarantee that Azure IoT Hub will not also deploy a certificate chain of this size??

Your recommended approach of "Avoid strict limits on certificate chain depth or handshake size" is basically saying "avoid small IoT devices", which is excatly what Azure IoT Hub is supposed to be used for.

Let's take the nrf9160 as an example, it is probably the most widely deployed MCU for IoT purposes. It's modem has a 4KB limit on the chain size and the chain now deployed on the blob storage is more than 2x that.

So if we, and many others, are to keep deploying embedded devices in the field connected to Azure IoT Hub I think some guarantees here are very needed.

Hello Kristoffer Wilhelmsson,

I completely understand your concern here, and you are raising a very practical point from a real world IoT deployment perspective.

there is currently no public guarantee that Azure IoT Hub will not adopt a similar certificate chain size in the future. Certificate chains can change over time as part of normal security updates, such as changes in certificate authorities or cryptographic requirements. These updates are applied to improve security, and they are not always fixed in size or structure.

At the same time, it is important to note that Azure IoT Hub and Azure Storage are independent services. Today, IoT Hub is still operating with a certificate chain that works with many constrained devices, and there is no confirmation that it will move to the same chain size as Blob endpoints. Changes like this are service specific and not always applied across all services at the same time.

Your concern about devices like the nrf9160 is absolutely valid. Devices with strict limits, such as a 4 KB certificate chain size, can face issues when certificate chains grow beyond those limits. This is a known challenge in the IoT space, especially with modern security requirements increasing over time.

The recommendation to avoid strict limits is not meant to say avoid small IoT devices. Instead, it is to highlight a design risk. If a device has a hard limit on TLS handshake or certificate size, then any future update from any cloud provider can potentially break connectivity. This is not specific to Azure and applies across cloud services in general.

In practical deployments, teams usually handle this in a few ways.

One common approach is architectural separation. Devices connect only to IoT Hub, and all interaction with other services like Blob Storage is handled by backend services. This reduces the exposure of devices to different endpoints and certificate changes.

Another approach is firmware and modem updates. Sometimes vendors release updates that improve TLS handling or certificate validation, which can help support larger chains.

Regular validation is also important. Testing device connectivity against endpoints periodically helps detect such issues early before deploying at scale.

From a platform point of view, Azure IoT Hub is designed for IoT scenarios and continues to support a wide range of constrained devices. However, like any secure service, it must evolve with security standards, and that means certificate configurations can change in the future.

In short, there is no strict guarantee on certificate chain size remaining the same. IoT Hub is currently compatible with many embedded devices, but future changes cannot be ruled out. So, designing devices or system architecture to handle some flexibility is the safest long-term approach.

I hope this gives you a clearer picture, please confirm whether it's alright to close this thread?

Thankyou!