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
Root Thumbprint: d4de20d05e66fc53fe1a50882c78db2852cae474

Expiration: Monday, May 12, 2025, 4:59:00 PM

Subject Name:
CN = Baltimore CyberTrust Root
OU = CyberTrust
O = Baltimore
C = IE
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:52:38 AM

Subject Name:
OU = Microsoft IT
O = Microsoft Corporation
L = Redmond
S = Washington
C = US
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;

Subject Name:
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:

Certificate Thumbprint
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.

Next steps

If you have additional questions, contact us through support.