What's New in Azure Cache for Redis
Azure TLS Certificate Change
Microsoft is updating Azure services to use TLS server certificates from a different set of Certificate Authorities (CAs). This change is rolled out in phases from August 13, 2020 to October 26, 2020 (estimated). Azure is making this change because the current CA certificates don't comply with one of the CA/Browser Forum Baseline requirements. The problem was reported on July 1, 2020 and applies to multiple popular Public Key Infrastructure (PKI) providers worldwide. Most TLS certificates used by Azure services today come from the Baltimore CyberTrust Root PKI. The Azure Cache for Redis service will continue to be chained to the Baltimore CyberTrust Root. Its TLS server certificates, however, will be issued by new Intermediate Certificate Authorities (ICAs) starting on October 12, 2020.
This change is limited to services in public Azure regions. It excludes sovereign (e.g., China) or government clouds.
Does this change affect me?
We expect that most Azure Cache for Redis customers aren't affected by the change. Your application may be impacted if it explicitly specifies a list of acceptable certificates, a practice known as “certificate pinning”. If it's pinned to an intermediate or leaf certificate instead of the Baltimore CyberTrust Root, you should take immediate actions to change the certificate configuration.
The following table provides information about the certificates that are being rolled. Depending on which certificate your application uses, you may need to update it to prevent loss of connectivity to your Azure Cache for Redis instance.
|CA Type||Current||Post Rolling (Oct 12, 2020)||Action|
Expiration: Monday, May 12, 2025, 4:59:00 PM
CN = Baltimore CyberTrust Root
OU = CyberTrust
O = Baltimore
C = IE
CN = Microsoft IT TLS CA 1
CN = Microsoft IT TLS CA 2
CN = Microsoft IT TLS CA 4
CN = Microsoft IT TLS CA 5
Expiration: Friday, May 20, 2024 5:52:38 AM
OU = Microsoft IT
O = Microsoft Corporation
L = Redmond
S = Washington
C = US
CN = Microsoft RSA TLS CA 01
CN = Microsoft RSA TLS CA 02
Expiration: Tuesday, October 8, 2024 12:00:00 AM;
O = Microsoft Corporation
C = US
What actions should I take?
If your application uses the operating system certificate store or pins the Baltimore root among others, no action is needed. On the other hand, if your application pins any intermediate or leaf TLS certificate, we recommend that you pin the following roots:
|Baltimore Root CA||d4de20d05e66fc53fe1a50882c78db2852cae474|
|Microsoft RSA Root Certificate Authority 2017||73a5e64a3bff8316ff0edccc618a906e4eae4d74|
|Digicert Global Root G2||df3c24f9bfd666761b268073fe06d1cc8d4f82a4|
Both the intermediate and leaf certificates are expected to change frequently. We recommend not to take a dependency on them. Instead pin your application to a root certificate since it rolls less frequently.
To continue to pin intermediate certificates, add the following to the pinned intermediate certificates list, which includes few additional ones to minimize future changes:
|Common name of the CA||Thumbprint|
|Microsoft RSA TLS CA 01||703d7a8f0ebf55aaa59f98eaf4a206004eb2516a|
|Microsoft RSA TLS CA 02||b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75|
|Microsoft Azure TLS Issuing CA 01||2f2877c5d778c31e0f29c7e371df5471bd673173|
|Microsoft Azure TLS Issuing CA 02||e7eea674ca718e3befd90858e09f8372ad0ae2aa|
|Microsoft Azure TLS Issuing CA 05||6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5|
|Microsoft Azure TLS Issuing CA 06||30e01761ab97e59a06b41ef20af6f2de7ef4f7b0|
If your application validates certificate in code, you will need to modify it to recognize the properties (e.g., Issuers, Thumbprint) of the newly pinned certificates. This extra verification should cover all pinned certificates to be more future-proof.
If you have additional questions, contact us through support.