Certificate use with Azure Sphere

[PennyO]

Updated 6 Jan 2023 –  As per 'Azure IoT TLS: Critical changes are almost here!', the Baltimore certificate migrations affecting Azure IoT services (Hub, DPS, Central) are going ahead in 2023-2024. Azure Sphere devices already have the DigiCert Global G2 root certificate, so no customer action is needed in relation to this.

As you’re probably aware, Microsoft is in the process of updating Azure services to use TLS certificates from a different set of root certificate authorities (root CAs). Azure TLS Certificate Changes provides details about these updates. Some of these changes affect Azure Sphere, but in most cases no action is required for Azure Sphere customers.

This post provides a primer about the Azure Sphere certificate “landscape”: the types of certificates that the various Azure Sphere components use, where they come from, where they’re stored, how they’re updated, and how to access them when necessary. Furthermore, it also describes how the Azure Sphere OS, SDK, and services make certificate management easier for you. We assume you have a basic familiarity with certificate authorities and the chain of trust. If this is all new to you, we suggest starting with Certificate authority - Wikipedia or other internet sources.

Azure Sphere Devices

Every Azure Sphere device relies on the Trusted Root Store, which is part of the Azure Sphere OS. The Trusted Root Store contains a list of root certificates that are used to validate the identity of the Azure Sphere Security Service when the device connects for device authentication and attestation (DAA), over-the-air (OTA) update, or error reporting. These certificates are provided with the OS.

When daily attestation succeeds, the device receives two certificates: an update certificate and a customer certificate. The update certificate enables the device to connect to the Azure Sphere Update Service to get software updates and to upload error reports; it is not accessible to applications or through the command line. The customer certificate, sometimes called the DAA certificate, can be used by applications to connect to third-party services such wolfSSL that use transport layer security (TLS). This certificate is valid for about 25 hours. Applications can retrieve it programmatically by calling the DeviceAuth_GetCertificatePath function.

Devices that connect to Azure-based services such as Azure IoT Hub, IoT Central, IoT Edge must present their Azure Sphere tenant CA certificate to authenticate their Azure Sphere tenant. The azsphere ca-certificate download command in the CLI returns the tenant CA certificate for such uses.

 

EAP-TLS network connections

Devices that connect to an EAP-TLS network need certificates to authenticate with the network’s RADIUS server. To authenticate as a client, the device must pass a client certificate to the RADIUS. To perform mutual authentication, the device must also have a root CA certificate for the RADIUS server so that it can authenticate the server. Microsoft does not supply either of these certificates; you or your network administrator is responsible for ascertaining the correct certificate authority for your network’s RADIUS server and then acquiring the necessary certificates from the issuer.

To obtain the certificates for the RADIUS server, you’ll need to authenticate to the certificate authority. You can use the DAA certificate, as previously mentioned, for this purpose. After acquiring the certificates for the RADIUS server, you should store them in the device certificate store. The device certificate store is available only for use in authenticating to a secured network with EAP-TLS. (The DAA certificate is not kept in the device certificate store; it is kept securely in the OS.) The azsphere device certificate command in the CLI lets you manage the certificate store from the command line. Azure Sphere applications can use the CertStore API to store, retrieve, and manage certificates in the device certificate store. The CertStore API also includes functions to return information about individual certificates, so that apps can prepare for certificate expiration and renewal.

See Use EAP-TLS in the online documentation for a full description of the certificates used in EAP-TLS networking, and see Secure enterprise Wi-Fi access: EAP-TLS on Azure Sphere on Microsoft Tech Community for additional information.

 

Azure Sphere Applications

Azure Sphere applications need certificates to authenticate to web services and some networks. Depending on the requirements of the service or endpoint, an app may use either the DAA certificate or a certificate from an external certificate authority.

Apps that connect to a third-party service using wolfSSL or a similar library can call the DeviceAuth_GetCertificatePath function to get the DAA certificate for authentication. This function was introduced in the deviceauth.h header in the 20.10 SDK.

The Azure IoT library that is built into Azure Sphere already trusts the necessary Root CA, so apps that use this library to access Azure IoT services (IoT Hub, IoT Central, DPS) do not require any additional certificates.

If your apps use other Azure services, check with the documentation for those services to determine which certificates are required.

 

Azure Sphere Public API

The Azure Sphere Public API (PAPI) communicates with the Azure Sphere Security Service to request and retrieve information about deployed devices. The Security Service uses a TLS certificate to authenticate such connections. This means that any code or scripts that use the Public API, along with any other Security Service clients such as the Azure Sphere SDK (including both the v1 and v2 azsphere CLI), must trust this certificate to be able to connect to the Security Service. The SDK uses the certificates in the host machine’s system certificate store for Azure Sphere Security Service validation, as do many Public API applications.

On October 13, 2020 the Security Service updated its Public API TLS certificate to one issued from the DigiCert Global Root G2 certificate. Both Windows and Linux systems include the DigiCert Global Root G2 certificate, so the required certificate is readily available. However, as we described in an earlier blog post, only customer scenarios that involved subject, name, or issuer (SNI) pinning required changes to accommodate this update.

 

Azure Sphere Security Service

Azure Sphere cloud services in general, and the Security Service in particular, manage numerous certificates that are used in secure service-to-service communication. Most of these certificates are internal to the services and their clients, so Microsoft coordinates updates as required. For example, in addition to updating the Public API TLS certificate in October, the Azure Sphere Security Service also updated its TLS certificates for the DAA service and Update service. Prior to the update, devices received an OTA Update to the Trusted Root Store which included the new required root certificate. No customer action was necessary to maintain device communication with the Security Service.

 

How does Azure Sphere make certificate changes easier for customers?

Certificate expiration is a common cause of failures for IoT Devices that Azure Sphere can prevent.

Because the Azure Sphere product includes both the OS and the Security Service, the certificates used by both these components are managed by Microsoft. Devices receive updated certificates through the DAA process, OS and application updates, and error reporting without requiring changes in applications. When Microsoft added the DigiCert Global Root G2 certificate, no customer changes were required to continue DAA, updates, or error reporting. Devices that were offline at the time of the update received the update as soon as they reconnected to the internet.

The Azure Sphere OS also includes the Azure IoT library, so if Microsoft makes further changes to certificates that the Azure IoT libraries use, we will update the library in the OS so that your applications won’t need to be changed. We’ll also let you know through additional blog posts about any edge cases or special circumstances that might require modifications to your apps or scripts.

Both of these cases show how Azure Sphere simplifies application management by removing the need for maintenance updates of applications to handle certificate changes. Because every device receives an update certificate as part of its daily attestation, you can easily manage the update of any locally-managed certificates your devices and applications use. For example, if your application validates the identity of your line-of-business server (as it should), you can deploy an updated application image package that includes updated certificates. The application update services provided by the Azure Sphere platform delivers those updates, removing the worry that the update service itself will incur a certificate expiry issue.

 

For more information

• Best practices for implementing seven properties in Azure Sphere
• Azure Sphere Device Authentication and Attestation Service
• Additional certificate updates for Azure Sphere
• Azure TLS Certificate Changes
• Azure IoT TLS: Changes are coming! (…and why you should care)