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

Update September 2023:

Starting in July 2023, Microsoft began introducing certificates issued by new Subordinate Certificate Authorities (Sub CAs). These new Sub CAs will replace the current ones, which will expire in 2024. Starting January 2024, the Azure Instance Metadata Service will start using these new certificates.

If you use the Attested data endpoint in your application and explicitly specify a list of acceptable CAs (a practice known as "certificate pinning"), you or your customers may be impacted. If your application pins Sub CAs, you must update it to use the new Sub CAs by December 31, 2023 to ensure uninterrupted access to the Attested data endpoints. For the full list of CA certificates used by Azure services, see Azure Certificate Authority details.

We recommend that you evaluate the cost benefit of certificate pinning and discontinue this practice. For further guidance, see Certificate pinning - Certificate pinning and Azure services. Please note that the Azure Instance Metadata Service will no longer offer notifications for future Certificate Authority changes. Instead, we recommend that you follow the Azure Certificate Authority details article for all future updates.

If you are not the application or the marketplace image owner, check the updates from application or image owners, who are responsible to determine whether the application or image licensing is impacted. 

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.