How to mitigate the Microsoft Azure Certificate Authority CA changes

Case #

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.

Solution #

You need to know 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 CAThumbprint (SHA1)
DigiCert Global Root G2df3c24f9bfd666761b268073fe06d1cc8d4f82a4
DigiCert Global Root CAa8985d3a65e5e5c4b2d7d66d40c6dd2fb19c5436
Baltimore CyberTrust Rootd4de20d05e66fc53fe1a50882c78db2852cae474
D-TRUST Root Class 3 CA 2 200958e8abb0361533fb80f79b1b6d29d3ff8d5f00f0
Microsoft RSA Root Certificate Authority 201773a5e64a3bff8316ff0edccc618a906e4eae4d74
Microsoft ECC Root Certificate Authority 2017999a64c37ff47d9fab95f14769891460eec4c3c5

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.
    • http://crl3.digicert.com
    • http://crl4.digicert.com
    • http://ocsp.digicert.com
    • http://oneocsp.microsoft.com
    • http://ocsp.msocsp.com

Sources on how to mitigate the Microsoft Azure Certificate Authority CA changes #

https://learn.microsoft.com/en-us/azure/security/fundamentals/tls-certificate-changes

https://learn.microsoft.com/en-us/azure/security/fundamentals/azure-ca-details?source=recommendations

https://www.microsoft.com/pkiops/docs/repository.htm

Powered by BetterDocs