You notice that some of your Azure services which depend on TLS certificate authentication for securing their traffic are failing. You need to review the Microsoft Azure certificate authority CA changes documents. This article provides high level guidance on how to mitigate the Microsoft Azure Certificate Authority CA changes.
Microsoft uses TLS certificates from the set of Root Certificate Authorities (CAs) that adhere to the CA/Browser Forum Baseline Requirements. All Azure TLS/SSL endpoints contain certificates chaining up to the Root CAs provided by Microsoft at https://learn.microsoft.com/en-us/azure/security/fundamentals/tls-certificate-changes. Changes to Azure endpoints began transitioning in August 2020, with some services completing their updates in 2022. All newly created Azure TLS/SSL endpoints contain updated certificates chaining up to the new Root CAs. All Azure services are impacted by this change.
You need to ensure that all your on-premises and Azure endpoints and services trust the newly adopted Certificate Authority Root certificates and intermediate (subordinate) certificates. The following tables list the newly trusted CAs in Microsoft Azure. After the change, TLS certificates used by Azure services will chain up to one of the following Root CAs:
|Common name of the CA||Thumbprint (SHA1)|
|DigiCert Global Root G2||df3c24f9bfd666761b268073fe06d1cc8d4f82a4|
|DigiCert Global Root CA||a8985d3a65e5e5c4b2d7d66d40c6dd2fb19c5436|
|Baltimore CyberTrust Root||d4de20d05e66fc53fe1a50882c78db2852cae474|
|D-TRUST Root Class 3 CA 2 2009||58e8abb0361533fb80f79b1b6d29d3ff8d5f00f0|
|Microsoft RSA Root Certificate Authority 2017||73a5e64a3bff8316ff0edccc618a906e4eae4d74|
|Microsoft ECC Root Certificate Authority 2017||999a64c37ff47d9fab95f14769891460eec4c3c5|
The following items are tips provided by Microsoft for any service provider or customer running their apps in hybrid mode or in Azure.
If your application explicitly specifies a list of acceptable CAs, your application is likely impacted. This practice is known as certificate pinning. Review the Microsoft Tech Community article on Azure Storage TLS changes for more information on how to determine if your services were impacted and next steps.
Here are some ways to detect if your application was impacted:
- Search your source code for the thumbprint, Common Name, and other cert properties of any of the Microsoft IT TLS CAs in the Microsoft PKI repository. If there’s a match, then your application will be impacted. To resolve this problem, update the source code include the new CAs. As a best practice, ensure that CAs can be added or edited on short notice. Industry regulations require CA certificates to be replaced within seven days of the change and hence customers relying on pinning need to react swiftly.
- If you have an application that integrates with Azure APIs or other Azure services and you’re unsure if it uses certificate pinning, check with the application vendor.
- Different operating systems and language runtimes that communicate with Azure services may require more steps to correctly build the certificate chain with these new roots:
- Linux: Many distributions require you to add CAs to /etc/ssl/certs. For specific instructions, refer to the distribution’s documentation.
- Java: Ensure that the Java key store contains the CAs listed above.
- Windows running in disconnected environments: Systems running in disconnected environments will need to have the new roots added to the Trusted Root Certification Authorities store, and the intermediates added to the Intermediate Certification Authorities store.
- Android: Check the documentation for your device and version of Android.
- Other hardware devices, especially IoT: Contact the device manufacturer.
- If you have an environment where firewall rules are set to allow outbound calls to only specific Certificate Revocation List (CRL) download and/or Online Certificate Status Protocol (OCSP) verification locations, you’ll need to allow the following CRL and OCSP URLs. For a complete list of CRL and OCSP URLs used in Azure, see the Azure CA details article.