Azure TLS certificate 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 in this article. 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. Details for some services are listed below:

• Microsoft Entra ID (Microsoft Entra ID) services began this transition on July 7, 2020.
• Azure Cosmos DB began this transition in July 2022 with an expected completion in October 2022.
• Details on Azure Storage TLS certificate changes can be found in this Azure Storage blog post.
• Azure Cache for Redis is moving away from TLS certificates issued by Baltimore CyberTrust Root starting May 2022, as described in this Azure Cache for Redis article
• Azure Instance Metadata Service has an expected completion in May 2022, as described in this Azure Governance and Management blog post.

What changed?

Prior to the change, most of the TLS certificates used by Azure services chained up to the following Root CA:

After the change, TLS certificates used by Azure services will chain up to one of the following Root CAs:

Was my application impacted?

If your application explicitly specifies a list of acceptable CAs, your application was 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.

  • http://crl3.digicert.com
  • http://crl4.digicert.com
  • http://ocsp.digicert.com
  • http://crl.microsoft.com
  • http://oneocsp.microsoft.com
  • http://ocsp.msocsp.com

Next steps

If you have questions, contact us through support.