The risk of pinning TLS certificates in IoT solutions and why your awareness is needed

Do you have cloud-connected IoT devices to the Azure IoT Hub and have you specified the specific public ‘Baltimore’ TLS certificate currently in use by the IoT Hub? Do you know customers having (low-powered) devices connected to Azure IoT and possibly pinned that certificate?

Then, please be aware of the following message.

Devices that want to set up any TLS/SSL connection with a (public) service will secure the connection on the transport level via a public certificate.

So, any device needs to have such a public certificate in their local certificate store.

Microsoft secures the IoT Hub traffic for IoT devices too. This is down with this ‘Baltimore’ certificate.

and this is a good thing.

The time has come to replace that certificate after years of service, next year February because it expires eventually.

This is not a bug or indifference; this is how the internet works.

Normally this is not a problem: Operating systems like Windows and Linux just try to download the correct/new certificate for the TLS connection, your application will never know the difference.

If this is the case with your solution, you are good to go.

If you are using any of the Azure IoT Device SDKs, this problem is probably taken care of too.

However, devices that specifically use this one Baltimore certificate and cannot replace it will no longer function after February 15, 2023.

And indeed there are devices where the Baltimore certificate is placed on the device eg. as part of the firmware installment instead of fetching it dynamically from another resource.

These devices will eventually stop sending telemetry to the cloud!


When in doubt, contact your manager, that technical guy who programmed it, or connect with your customer so they are aware of the risk of pinning. Better to be safe than to say sorry.

As an example, I recently published this GitHub with the example code of connecting a device to the IoT Hub without SDK. There I specifically specify (and distribute) the certificate.

In my case, it’s just a demonstration application so I deliberately keep it this way. But, as seen in both the comments and the readme this needs the attention of the reader.

More background information about the challenges, how to test for the possible issue, and the resolution is found here in this Microsoft blog post.

Een gedachte over “The risk of pinning TLS certificates in IoT solutions and why your awareness is needed

Reacties zijn gesloten.