Azure Instance Metadata Service-Attested data TLS: Critical changes are here!

In 2020 most Azure services were updated to use TLS certificates from Certificate Authorities (CAs) that chain up to the DigiCert Global G2 root. However, Azure Instance Metadata Service -Attested data certificate, remained on TLS certificates issued by the Baltimore CyberTrust Root. The time has now come Azure Instance Metadata Service -Attested data to switch from the Baltimore CyberTrust CA Root to the DigiCert Global G2 CA Root*. The migration is started, will be finished by end of June 2022.  

We expect that most Azure Instance Metadata Service customers will not be impacted; however, if you use the Attested data endpoint in your application, you or your customers may be impacted if you explicitly specify a list of acceptable CAs (a practice known as “certificate pinning”). 

This change is limited to public Azure cloud and US Government cloud. There are no changes in other sovereign clouds like Azure China. 

If your application has pinned to the root CA Baltimore CyberTrust Root or current intermediate CAs listed in the table below, immediate action is required to prevent disruption in applications using Instance Metadata Service Attested Data endpoint.

* Other Azure service TLS certificates may be issued by a different PKI. 

Overview of Action Required

• If your client application has pinned to the Baltimore CyberTrust Root CA, in addition to Baltimore, add the DigiCert Global Root G2 to your trusted root store before end of June 2022. 
• If your client application has pinned to the intermediate CAs, in addition to Microsoft RSA TLS CAs, add the Microsoft Azure TLS Issuing CAs to your trusted root store before end of June 2022. 
• Keep using the current root or intermediate CAs in your applications or devices until the transition period is completed (necessary to prevent connection interruption). 

How to check if your application is impacted

If your client application has pinned to  

• Root CA: Baltimore CyberTrust Root CA or,  
• Intermediate CA:  Microsoft RSA TLS CA 01 
• Intermediate CA:  Microsoft RSA TLS CA 02   

detailed in the table below, then search your source code for the thumbprint, Common Name, and other cert properties of any of the root CA or intermediate CAs. If there is a match, then your application will be impacted, immediate action is required.

Action Required 

1. To continue without disruption due to this change, Microsoft recommends that client applications or devices trust the root CA – DigiCert Global Root G2  (Thumbprint: df3c24f9bfd666761b268073fe06d1cc8d4f82a4) 

• Intermediate certificates are expected to change more frequently than root CA. Customers who use certificate pinning are recommended to NOT taking dependencies on them and instead pin to the root certificate, as it rolls less frequently.
  If you are currently pinning to the intermediate CAs and have a requirement to continue pinning to intermediate CAs, to prevent disruption due to this change, you should update the source code to add the intermediate Microsoft Azure TLS Issuing CAs listed in the table below to the trusted store. 

2. To prevent future disruption, you should also add the following roots to the trusted store. This will save you from the allow list effort in near future if you add the recommended root CAs now: 

• DigiCert Global Root G3 
  (Thumbprint: 7e04de896a3e666d00e687d33ffad93be83d349e) 
• Microsoft RSA Root Certificate Authority 2017 
  (Thumbprint: 73a5e64a3bff8316ff0edccc618a906e4eae4d74) 
• Microsoft ECC Root Certificate Authority 2017 
  (Thumbprint: 999a64c37ff47d9fab95f14769891460eec4c3c5) 

Note: If you have a requirement to pin to intermediate CAs, to prevent future disruption, you should also add the intermediate Microsoft Azure ECC TLS CAs listed in the table below to the trusted store.

3. If you have an application that integrates with Azure services, or if you get your VM images from Azure marketplace, and you are unsure if it uses certificate pinning with Azure Instance Metadata Service Attested data, check with the application/image owner.

4. It is also recommended to create a fallback logic with the certificate pinning process to minimize the future impact of certificate changes. 

Certificate Renewal Summary 

The table below provides information about the certificates that are being rolled. Depending on which certificate your service uses for establishing TLS connections, action may be needed to prevent disruption in applications using Instance Metadata Service Attested Data endpoint.

For additional information about Azure certificate Authority, see Azure Certificate Authority details | Microsoft Docs

Help and Support

If you have questions, get answers from community experts here Azure Instance Metadata Service Attested data certificate changes FAQ - Microsoft Q&A.

If you have a support plan and you need technical help, please create a support request:

1. Select the appropriate virtual machine type:

Virtual Machine running Linux

Virtual Machine running SUSE

Virtual Machine running RedHat

Virtual Machine running Ubuntu

Virtual Machine running Windows

2. For Summary, type a description of your issues

3. After Issue type automatically populates, for Subscription, select your subscription

4. After Service and Service type automatically populate, for Resource, select the resource you need help with.

5. After Problem type and Problem subtype automatically populate, select Next.