At a glance

The technology industry is retiring trust in an older root certificate - the DigiCert Global Root G1. As operating systems, firmware images, and CA certificate bundles update over time, some clients may stop trusting this older root. This can affect both your Azure IoT devices and the applications that connect to Azure IoT service APIs. If those devices or application hosts run on Linux or rely on a system trust store that receives periodic updates, this post explains what you might see and the simple steps to stay connected.

This guidance is relevant only for a subset of Azure IoT customers using Azure Government (Fairfax) or Azure China (Mooncake) environments, and only if devices or applications adopt operating system, firmware, or trust-store updates that remove trust for the DigiCert Global Root G1 certificate.  Azure public cloud customers are not affected because Azure IoT public cloud endpoints already use newer certificate chains.  This is a client-side trust-store change, not a security incident, service outage, or certificate expiration event.

Scope: Azure public cloud customers are not affected. This guidance applies only to specific Azure Government (Fairfax) and Azure China (Mooncake) scenarios where updated client trust stores no longer trust DigiCert Global Root G1.

Could this affect my deployment?

For most Azure IoT customers, the answer is no. If you use Azure IoT in the Azure public (commercial) cloud, you are not affected by this change. Azure IoT public cloud endpoints already use newer certificate chains and do not rely on the DigiCert Global Root G1 certificate.

This guidance is relevant only for a subset of customers using Azure Government (Fairfax) or Azure China (Mooncake) environments, and only if:

• Your devices or applications rely on operating system trust stores.
• You recently applied Linux operating system, firmware, container image, OpenSSL, NSS, or CA certificate bundle updates.
• You began seeing TLS connectivity or provisioning errors after those updates were installed.

If your devices continue to connect normally and you have not observed any TLS-related issues following recent updates, no action is required at this time

What should I do?

If your devices and applications are connecting normally, no action is required.

If you manage Linux-based devices or applications that rely on operating system trust stores, we recommend validating OS, firmware, and CA bundle updates in a test environment before production rollout. If connectivity issues appear following a trust-store update, contact Microsoft Support for assistance.

What you may observe

After an operating system, firmware, or CA-certificate-bundle update, an affected device or application may show the symptoms below. These typically appear first in test or QA environments, because fleets and application environments usually stage updates before production.

• Failure to connect to Azure IoT during the TLS handshake.
• A certificate trust, “untrusted root,” or “unknown CA” error.
• Telemetry, provisioning, or service-API calls stop, while clients still running the previous trust store keep working normally.

Why it could happen

Your device or application validates the Azure IoT server certificate against the list of trusted root certificates in its local trust store. As updates remove the older DigiCert Global Root G1 from that store, a client that still expects it may reject the connection - even though the server certificate is valid. The change is on the client side, in the trust store, not in the Azure service.

What you should check

If you see connectivity or provisioning failures, confirm the following:

• Was there a recent OS, firmware, or CA-bundle update on the affected devices or application hosts?
• Do clients still running the previous trust store continue to connect? If so, the cause is a trust-store change.
• Is the error a certificate or trust error rather than an authentication error?

What we recommend

A few simple steps keep your devices and applications connected through this change:

• Validate firmware and OS updates in a test ring before production rollout, the single most effective way to catch trust-store changes early.
• If clients begin failing after such an update, pause the rollout and, where feasible, roll back the update on the affected device or application host to restore connectivity.
• Contact Microsoft Support if you see connectivity or provisioning failures following an OS, firmware, or CA-bundle update. Support can confirm the cause and guide you through the appropriate next steps for your configuration.

Questions

If you have questions, contact Microsoft Support or your Microsoft account team.