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.
Note
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 |
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; Subject Name: O = Microsoft Corporation C = US |
Required |
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 |
Tip
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.