Azure Storage TLS: Critical changes are almost here! (…and why you should care)

This blog contains important information about TLS certificate changes for Azure Storage endpoints that may impact client connectivity.  

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 Storage, remained on TLS certificates issued by the Baltimore CyberTrust Root. The time has now come for Azure Storage to switch from the Baltimore CyberTrust CA Root to the DigiCert Global G2 CA Root*. The migration will start in July 2022, and finish by end of October 2022.  

We expect that most Azure Storage customers will not be impacted; however, your application may be impacted if you explicitly specify a list of acceptable CAs (a practice known as “certificate pinning”). In scope Azure Storage services include Blob, File, Table, Queue, Static Website, ADLS Gen2. This change is limited to public Azure cloud and US Government cloud. There are no changes in other sovereign clouds like Azure China. 

This change is being made because the current "Baltimore CyberTrust Root" will expire in May 2025.   

If any client 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 to connectivity to Azure Storage.  

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

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 February 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 February 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). 
• Make sure SHA384 for Server certificate processing is enabled on the device.

How to check 

1. 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:  

• To continue without disruption due to this change, Microsoft recommends that client applications or devices trust the root CA – DigiCert Global Root G2: 

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 allowlist 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 completed the step 1 and need to validate your changes, we can provide a test environment on demand for your convenience to verify prior to July 2022. To request a test storage account, please open a support request with the options below and a member from our engineering team will get back to you. 

• For Issue type, select Technical.
• For Subscription, select your subscription. 
• For Service, select My Services, then select Blob Storage.
• For Resource, select your resource. 
• For Summary, enter #storagecertificatetest. 
• For Problem type, select Connectivity. 
• For Problem subtype, select Dropped or terminated connections. 

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 loss of connectivity.