This article is contributed. See the original author and article here.
Microsoft is updating Azure services in a phased manner to use TLS certificates from a different set of Certificate Authorities (CAs) beginning August 13, 2020 and concluding approximately on October 26, 2020. 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”). This change is limited to services in 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 CA certificates do not comply with one of the CA/Browser Forum Baseline requirements. This was reported on July 1, 2020 and impacts multiple popular Public Key Infrastructure (PKI) providers worldwide. Today, most of the TLS certificates used by Azure services are issued from the “Baltimore CyberTrust Root” PKI.
Azure Storage services will remain chained to the Baltimore CyberTrust Root*, but the TLS server certificates will be issued by new Intermediate Certificate Authorities (ICAs) starting October 26, 2020.
If any client application has pinned to an Intermediate CA rather than the Baltimore CyberTrust Root, immediate action is required to prevent disruption to connectivity to Azure Storage.
* Other Azure service TLS certificates may be issued by a different PKI.
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.
Certificate |
Current |
Post Rollover (Oct 26, 2020) |
Action |
|
Root |
Thumbprint: d4de20d05e66fc53fe1a50882c78db2852cae474 OU = CyberTrust |
Not Changing |
None |
|
Intermediates |
Thumbprints:
CN = Microsoft IT TLS CA 1 Thumbprint: 417e225037fbfaa4f95761d5ae729e1aea7e3a42 —————————————————————-—————– CN = Microsoft IT TLS CA 2 Thumbprint: 54d9d20239080c32316ed9ff980a48988f4adf2d —————————————————————-—————– CN = Microsoft IT TLS CA 4 Thumbprint: 8a38755d0996823fe8fa3116a277ce446eac4e99 —————————————————————-—————– CN = Microsoft IT TLS CA 5 Thumbprint: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7 —————————————————————-—————–
Expiration: Friday, May 20, 2024 5:51:28 AM Subject Name: OU = Microsoft IT O = Microsoft Corporation L = Redmond S = Washington C = US |
Thumbprints:
CN = Microsoft RSA TLS CA 01 Thumbprint: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a —————————————————————-—————- CN = Microsoft RSA TLS CA 02 Thumbprint: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75 —————————————————————-—————-
Expiration: Tuesday, October 8, 2024 12:00:00 AM; O = Microsoft Corporation C = US |
Required |
Note: Intermediate certificates are expected to change frequently. We recommend not taking dependencies on them and instead pinning the root certificate as it rolls less frequently.
Action Required
- Search your source code for the thumbprint, Common Name, and other cert properties of any of the 4 Microsoft IT TLS CAs listed above. here. If there is a match, then your application will be impacted, immediate action is required:
- To resolve this problem, update the source code to include the new intermediate CAs. To continue pinning intermediaries, replace the existing certificates with the new intermediates CAs:
- Microsoft RSA TLS CA 01
(Thumbprint: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a) - Microsoft RSA TLS CA 02
(Thumbprint: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75)
- Microsoft RSA TLS CA 01
- To resolve this problem, update the source code to include the new intermediate CAs. To continue pinning intermediaries, replace the existing certificates with the new intermediates CAs:
Validation
We recommend performing some basic validation to mitigate any unintentional impact to your application. We will provide a test environment on demand for your convenience to try out before we roll these certificates in production environments.
Support
If you have any technical questions on implementing these changes or help in performing validation in the test environment, please open a support request with the options below and a member from our engineering team will get back to you shortly.
- Issue Type: Technical
- Service: Azure Storage
- Problem type: Connectivity
- Problem subtype: Dropped or terminated connections
Additional Information
Microsoft wide communications: To broadly notify customers, Microsoft had sent a Service Health portal notification on Aug 3rd, 2020 and released a public document that includes timelines, actions that need to be taken, and details regarding the upcoming changes to our Public Key Infrastructure (PKI).
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments