This article outlines the specific root and subordinate Certificate Authorities (CAs) that are employed by Azure's service endpoints. It is important to note that this list is distinct from the trust anchors provided on Azure VMs and hosted services, which leverage the trust anchors provided by the operating systems themselves. The scope includes government and national clouds. The minimum requirements for public key encryption and signature algorithms, links to certificate downloads and revocation lists, and information about key concepts are provided below the CA details tables. The host names for the URIs that should be added to your firewall allowlists are also provided.
Certificate Authority details
Any entity trying to access Microsoft Entra identity services via the TLS/SSL protocols will be presented with certificates from the CAs listed in this article. Different services may use different root or intermediate CAs. The following root and subordinate CAs are relevant to entities that use certificate pinning.
How to read the certificate details:
The Serial Number (top string in the table) contains the hexadecimal value of the certificate serial number.
The Thumbprint (bottom string in the table) is the SHA1 thumbprint.
CAs listed in italics are the most recently added CAs.
The CAs used by Azure are compatible with the following OS versions:
Windows
Firefox
iOS
macOS
Android
Java
Windows XP SP3+
Firefox 32+
iOS 7+
OS X Mavericks (10.9)+
Android SDK 5.x+
Java JRE 1.8.0_101+
Review the following action steps when CAs expire or change:
Update to a supported version of the required OS.
If you can't change the OS version, you may need to manually update the trusted root store to include the new CAs. Refer to documentation provided by the manufacturer.
If your scenario includes disabling the trusted root store or running the Windows client in disconnected environments, ensure that all root CAs are included in the Trusted Root CA store and all sub CAs listed in this article are included in the Intermediate CA store.
Many distributions of Linux require you to add CAs to /etc/ssl/certs. Refer to the distribution’s documentation.
Ensure that the Java key store contains the CAs listed in this article. For more information, see the Java applications section of this article.
If your application explicitly specifies a list of acceptable CAs, check to see if you need to update the pinned certificates when CAs change or expire. For more information, see Certificate pinning.
Public key encryption and signature algorithms
Support for the following algorithms, elliptical curves, and key sizes are required:
Signature algorithms:
ES256
ES384
ES512
RS256
RS384
RS512
Elliptical curves:
P256
P384
P521
Key sizes:
ECDSA 256
ECDSA 384
ECDSA 521
RSA 2048
RSA 3072
RSA 4096
Certificate downloads and revocation lists
The following domains may need to be included in your firewall allowlists to optimize connectivity:
AIA:
cacerts.digicert.com
cacerts.digicert.cn
cacerts.geotrust.com
www.microsoft.com
CRL:
crl3.digicert.com
crl4.digicert.com
crl.digicert.cn
cdp.geotrust.com
www.microsoft.com
OCSP:
ocsp.digicert.com
ocsp.digicert.cn
oneocsp.microsoft.com
status.geotrust.com
Certificate Pinning
Certificate Pinning is a security technique where only authorized, or pinned, certificates are accepted when establishing a secure session. Any attempt to establish a secure session using a different certificate is rejected. Learn about the history and implications of certificate pinning.
How to address certificate pinning
If your application explicitly specifies a list of acceptable CAs, you may periodically need to update pinned certificates when Certificate Authorities change or expire.
To detect certificate pinning, we recommend the taking the following steps:
If you're an application developer, search your source code for references to certificate thumbprints, Subject Distinguished Names, Common Names, serial numbers, public keys, and other certificate properties of any of the Sub CAs involved in this change.
If there's a match, update the application to include the missing CAs.
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.
Java Applications
To determine if the Microsoft ECC Root Certificate Authority 2017 and Microsoft RSA Root Certificate Authority 2017 root certificates are trusted by your Java application, you can check the list of trusted root certificates used by the Java Virtual Machine (JVM).
Look for the Microsoft RSA Root Certificate Authority 2017 in the output. It should look something like this:
If the Microsoft ECC Root Certificate Authority 2017 and Microsoft RSA Root Certificate Authority 2017 root certificates are trusted, they should appear in the list of trusted root certificates used by the JVM.
If it's not in the list, you'll need to add it.
The output should look like the following sample:
Bash
...
Microsoft ECC Root Certificate Authority 2017, 20-Aug-2022, Root CA,
Microsoft RSA Root Certificate Authority 2017, 20-Aug-2022, Root CA,
...
To add a root certificate to the trusted root certificate store in Java, you can use the keytool utility. The following example adds the Microsoft RSA Root Certificate Authority 2017 root certificate:
In this example, microsoft-ecc-root-ca.crt and microsoft-rsa-root-ca.crt are the names of the files that contain the Microsoft ECC Root Certificate Authority 2017 and Microsoft RSA Root Certificate Authority 2017 root certificates, respectively.
Past changes
The CA/Browser Forum updated the Baseline Requirements to require all publicly trusted Public Key Infrastructures (PKIs) to end usage of the SHA-1 hash algorithms for Online Certificate Standard Protocol (OCSP) on May 31, 2022. Microsoft updated all remaining OCSP Responders that used the SHA-1 hash algorithm to use the SHA-256 hash algorithm. View the Sunset for SHA-1 OCSP signing article for additional information.
Microsoft updated Azure services to use TLS certificates from a different set of Root Certificate Authorities (CAs) on February 15, 2021, to comply with changes set forth by the CA/Browser Forum Baseline Requirements. Some services finalized these updates in 2022. View the Azure TLS certificate changes article for additional information.
Article change log
October 8, 2024: Removed the following CAs and CDP endpoints: crl.microsoft.com, mscrl.microsoft.com, and ocsp.msocsp.com.