Azure SSL/TLS certificate changes

From Microsoft Corporation

MC226863, Prevent or Fix Issues, Published date: Nov 16, 2020
Admin impact

In early November, DigiCert replaced the certificate of an Intermediate Certificate Authority (ICA) which issues SSL/TLS certificates used by Azure Active Directory (Azure AD) services, such as Microsoft 365 and Dynamics 365, in the Public and US Government Clouds. In most cases, no action is required. However, if you explicitly hard code (i.e. “pin”) the ICA certificates to be trusted or have custom solutions that depend on storing ICA certificates in a trust store, you will need to take action as soon as possible in order to avoid service disruptions.

What is changing?
DigiCert replaced the certificate of the ICA “DigiCert SHA2 Secure Server CA”. This certificate links the SSL/TLS certificates used by some Azure AD services in the Public and US Government Clouds to a trusted root DigiCert certificate. The change made by DigiCert will affect service certificates that are newly issued or re-issued after 2 Nov 2020. Previously issued certificates will remain unaffected, as DigiCert does not intend to remove the existing ICA certificate until all those previously issued certificates have expired.

For specific information on the existing and new certificates see the entries for “DigiCert SHA2 Secure Server CA” under CAs used by Azure AD Identity services.
For more details about the DigiCert changes see the DigiCert documentation.

When will this change occur?
Azure AD services intend to limit re-issuing SSL/TLS certificates from DigiCert SHA2 Secure Server CA until after the 2020 holiday season; however, certificates may need to be re-issued sooner if any security-related concerns arise. For that reason, it is important that you prepare for re-issued certificates as soon as possible.

Will this change affect me?
We expect that most customers will not be impacted. You may be impacted, however, if you have applications that explicitly specify a list of trusted ICAs, either by hard coding them (“certificate pinning”) or by operating a trust store.

Here are some ways to detect if your applications will be impacted:

  • Check if you have Azure AD hybrid agents installed on-premises that have hardened environments with a fixed list of trusted certificate issuers.
  • For third party applications that integrate with Azure services, check with the application vendor.
  • For your own applications, search your source code for the Thumbprint, Common Name, and other certificate properties of the old “DigiCert SHA2 Secure Server CA” certificate.

What do I need to do if I’m impacted?
When deciding how to address the DigiCert ICA certificate change, take into account that DigiCert is doing this to promote ICA replacement agility by reducing the likelihood of applications that explicitly specify a list of trusted CAs. For more information see the DigiCert documentation.

If you cannot avoid having to explicitly specify a list of trusted CAs, then make sure that your list includes all the CAs used by Azure AD Identity services; specifically, include both entries for “DigiCert SHA2 Secure Server CA”.

Different operating systems and language runtimes that communicate with Azure services may require additional steps to correctly build the certificate chain with the new ICA certificate:

  • 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 required CAs.
  • Windows running in disconnected environments: Systems running in disconnected environments will need to have the new intermediate CA certificate 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.