This article is contributed. See the original author and article here.
Microsoft is updating Azure services in a phased manner to use TLS certificates from a different set of Certificate Authorities (CAs) beginning August 13, 2020 and concluding approximately on October 26, 2020. We expect that most Azure IoT customers will not be impacted; however, your application may be impacted if you explicitly specify a list of acceptable CAs (a practice known as “certificate pinning”). This change is limited to services in public Azure cloud and no sovereign cloud like Azure China.
This change is being made because the current CA certificates do not comply with one of the CA/Browser Forum Baseline requirements. This was reported on July 1, 2020 and impacts multiple popular Public Key Infrastructure (PKI) providers worldwide. Today, most of the TLS certificates used by Azure services are issued from the “Baltimore CyberTrust Root” PKI.
The following services used by Azure IoT devices will remain chained to the Baltimore CyberTrust Root*, but their TLS server certificates will be issued by new Intermediate Certificate Authorities (ICAs) starting October 5, 2020:
- Azure IoT Hub
- Azure IoT Hub Device Provisioning Service (DPS)
- Azure Storage Services
If any client application or device has pinned to an Intermediate CA or leaf certificate rather than the Baltimore CyberTrust Root, immediate action is required to prevent disruption of IoT device connectivity to Azure.
* Other Azure service TLS certificates may be issued by a different PKI.
Certificate Renewal Summary
The table below provides information about the certificates that are being rolled. Depending on which certificate your device or gateway clients use for establishing TLS connections, action may be needed to prevent loss of connectivity.
|
Certificate |
Current |
Post Rollover (Oct 5, 2020) |
Action |
|
Root |
Thumbprint: d4de20d05e66fc53fe1a50882c78db2852cae474 OU = CyberTrust |
Not Changing |
None |
|
Intermediates |
Thumbprints:
CN = Microsoft IT TLS CA 1 Thumbprint: 417e225037fbfaa4f95761d5ae729e1aea7e3a42 —————————————————- CN = Microsoft IT TLS CA 2 Thumbprint: 54d9d20239080c32316ed9ff980a48988f4adf2d —————————————————- CN = Microsoft IT TLS CA 4 Thumbprint: 8a38755d0996823fe8fa3116a277ce446eac4e99 —————————————————- CN = Microsoft IT TLS CA 5 Thumbprint: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7 —————————————————-
Expiration: Friday, May 20, 2016 5:52:38 AM OU = Microsoft IT O = Microsoft Corporation L = Redmond S = Washington C = US |
Thumbprints:
CN = Microsoft RSA TLS CA 01 Thumbprint: 417e225037fbfaa4f95761d5ae729e1aea7e3a42 —————————————————- CN = Microsoft RSA TLS CA 02 Thumbprint: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75 —————————————————-
Expiration: Tuesday, October 8, 2024 12:00:00 AM; O = Microsoft Corporation C = US |
Required |
|
Leaf (IoT Hub) |
Thumbprint: 8b1a359705188c5577cb2dcd9a06331807c0bb97 Subject Name: CN = *.azure-devices.net |
Thumbprint: Coming soon |
Required |
|
Leaf (DPS) |
Thumbprint: f568f692f3274ecbb479c94272d6f3344a3f0247 Subject Name: CN = *.azure-devices-provisioning.net |
Thumbprint: Coming soon |
Required |
Note: Both the intermediate and lea certificates are expected to change frequently. We recommend not taking dependencies on them and instead pinning the root certificate as it rolls less frequently.
Action Required
- If your devices depend on the operating system certificate store for getting these roots or use the device/gateway SDKs as provided, then no action is required.
- If your devices pin the Baltimore root CA among others, then no action is required related to this change.
- If your device interacts with other Azure services (e.g. IoT Edge -> Microsoft Container Registry), then you must pin additional roots as provided here.
- If your devices use a connection stack other than the ones provided in an Azure IoT SDK, and pin any intermediary or leaf TLS certificates instead of the Baltimore root CA, then immediate action is required:
- To continue without disruption due to this change, Microsoft recommends that client applications or devices pin the Baltimore root –
- Baltimore Root CA
(Thumbprint: d4de20d05e66fc53fe1a50882c78db2852cae474) - To prevent future disruption, client applications or devices should also pin the following roots:
- Microsoft RSA Root Certificate Authority 2017
(Thumbprint: 73a5e64a3bff8316ff0edccc618a906e4eae4d74) - Digicert Global Root G2
(Thumbprint: df3c24f9bfd666761b268073fe06d1cc8d4f82a4)
- Microsoft RSA Root Certificate Authority 2017
- Baltimore Root CA
- To continue pinning intermediaries, replace the existing certificates with the new intermediates CAs:
- Microsoft RSA TLS CA 01
(Thumbprint: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a) - Microsoft RSA TLS CA 02
(Thumbprint: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75) - To minimize future code changes, also pin the following ICAs:
- Microsoft Azure TLS Issuing CA 01
(Thumbprint: 2f2877c5d778c31e0f29c7e371df5471bd673173) - Microsoft Azure TLS Issuing CA 02
(Thumbprint: e7eea674ca718e3befd90858e09f8372ad0ae2aa) - Microsoft Azure TLS Issuing CA 05
(Thumbprint: 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5) - Microsoft Azure TLS Issuing CA 06
(Thumbprint: 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0)
- Microsoft Azure TLS Issuing CA 01
- Microsoft RSA TLS CA 01
- To continue without disruption due to this change, Microsoft recommends that client applications or devices pin the Baltimore root –
- If your client applications, devices, or networking infrastructure (e.g. firewalls) perform any sub root validation in code, immediate action is required:
- If you have hard coded properties like Issuer, Subject Name, Alternative DNS, or Thumbprint of any certificate other than the Baltimore Root CA, then you will need to modify this to reflect the properties of the newly pinned certificates.
- Note: This extra validation, if done, should cover all the pinned certificates to prevent future disruptions in connectivity.
Validation
We recommend performing some basic validation to mitigate any unintentional impact to your IoT infrastructure connecting to Azure IoT Hub and DPS. We will be providing a test environment for your convenience to try out before we roll these certificates in production environments. The connection strings for this test environment will be updated here soon.
A successful TLS connection to the test environment indicates a positive test outcome – that your infrastructure will work as is with these changes. The test connection strings contain invalid keys, so once the TLS connection has been established, any run time operations performed against these services will fail. This is by design since these resources exist solely for customers to validate their TLS connectivity. The test environment will be available until all public cloud regions have been updated.
Support
If you have any technical questions on implementing these changes, with the options below and a member from our engineering team will get back to you shortly.
- Issue Type: Technical
- Service: Internet of Things/IoT SDKs
- Problem type: Connectivity
- Problem subtype: Unable to connect
Additional Information
- IoT Show: To know more about TLS certificates and PKI changes related to Azure IoT, please check out the IoT Show:
- Microsoft wide communications: To broadly notify customers, Microsoft had sent a Service Health portal notification on Aug 3rd, 2020 and released a public document that include timelines, actions that need to be taken, and details regarding the upcoming changes to our Public Key Infrastructure (PKI).
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments