Azure TLS certificate changes


This article was published concurrent with the TLS certificate change, and is not being updated. For up-to-date information about CAs, see Azure Certificate Authority details.

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:

What changed?

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

Common name of the CA Thumbprint (SHA1)
Baltimore CyberTrust Root d4de20d05e66fc53fe1a50882c78db2852cae474

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

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.


Next steps

If you have questions, contact us through support.