Remove TLS 1.0 and 1.1 from use with Azure Cache for Redis

There's an industry-wide push toward the exclusive use of Transport Layer Security (TLS) version 1.2 or later. TLS versions 1.0 and 1.1 are known to be susceptible to attacks such as BEAST and POODLE, and to have other Common Vulnerabilities and Exposures (CVE) weaknesses. They also don't support the modern encryption methods and cipher suites recommended by Payment Card Industry (PCI) compliance standards. This TLS security blog explains some of these vulnerabilities in more detail.

As a part of this effort, we'll be making the following changes to Azure Cache for Redis:

  • Phase 1: We'll configure the default minimum TLS version to be 1.2 for newly created cache instances (previously, it was TLS 1.0). Existing cache instances won't be updated at this point. You can still use the Azure portal or other management APIs to change the minimum TLS version to 1.0 or 1.1 for backward compatibility if you need to.

  • Phase 2: We'll stop supporting TLS 1.1 and TLS 1.0. After this change, your application must use TLS 1.2 or later to communicate with your cache. The Azure Cache for Redis service is expected to be available while we migrate it to support only TLS 1.2 or later.


    Phase 2 is tentatively planned to begin not earlier than December 31, 2020. However, we strongly recommend that you begin planning for this change now and proactively update clients to support TLS 1.2 or later.

As part of this change, we'll also remove support for older cypher suites that are not secure. Our supported cypher suites will be restricted to the following suites when the cache is configured with a minimum of TLS 1.2:


This article provides general guidance about how to detect dependencies on these earlier TLS versions and remove them from your application.

The dates when these changes take effect are:

Cloud Phase 1 Start Date Phase 2 Start Date
Azure (global) January 13, 2020 Postponed due to COVID-19
Azure Government March 13, 2020 Postponed due to COVID-19
Azure Germany March 13, 2020 Postponed due to COVID-19
Azure China 21Vianet March 13, 2020 Postponed due to COVID-19


Phase 2 is tentatively planned to begin not earlier than December 31, 2020. This article will be updated when specific dates are set.

Check whether your application is already compliant

The easiest way to find out whether your application will work with TLS 1.2 is to set the Minimum TLS version value to TLS 1.2 on a test or staging cache, then run tests. The Minimum TLS version setting is in the Advanced settings of your cache instance in the Azure portal. If the application continues to function as expected after this change, it's probably compliant. You might need to configure the Redis client library used by your application to enable TLS 1.2 in order to connect to Azure Cache for Redis.

Configure your application to use TLS 1.2

Most applications use Redis client libraries to handle communication with their caches. Here are instructions for configuring some of the popular client libraries, in various programming languages and frameworks, to use TLS 1.2.

.NET Framework

Redis .NET clients use the earliest TLS version by default on .NET Framework 4.5.2 or earlier, and use the latest TLS version on .NET Framework 4.6 or later. If you're using an older version of .NET Framework, you can enable TLS 1.2 manually:

  • StackExchange.Redis: Set ssl=true and sslprotocols=tls12 in the connection string.
  • ServiceStack.Redis: Follow the ServiceStack.Redis instructions and requires ServiceStack.Redis v5.6 at a minimum.

.NET Core

Redis .NET Core clients default to the OS default TLS version which obviously depends on the OS itself.

Depending on the OS version and any patches which have been applied, the effective default TLS version can vary. While there is one source of info about this, here is an article for Windows.

However, if you are using a old OS or just want to be sure, we recommend configuring the preferred TLS version manually through the client.


Redis Java clients use TLS 1.0 on Java version 6 or earlier. Jedis, Lettuce, and Redisson can't connect to Azure Cache for Redis if TLS 1.0 is disabled on the cache. Upgrade your Java framework to use new TLS versions.

For Java 7, Redis clients don't use TLS 1.2 by default but can be configured for it. Jedis allows you to specify the underlying TLS settings with the following code snippet:

SSLSocketFactory sslSocketFactory = (SSLSocketFactory) SSLSocketFactory.getDefault();
SSLParameters sslParameters = new SSLParameters();
sslParameters.setProtocols(new String[]{"TLSv1.2"});
URI uri = URI.create("rediss://host:port");
JedisShardInfo shardInfo = new JedisShardInfo(uri, sslSocketFactory, sslParameters, null);
Jedis jedis = new Jedis(shardInfo);

The Lettuce and Redisson clients don't yet support specifying the TLS version, so they'll break if the cache accepts only TLS 1.2 connections. Fixes for these clients are being reviewed, so check with those packages for an updated version with this support.

In Java 8, TLS 1.2 is used by default and shouldn't require updates to your client configuration in most cases. To be safe, test your application.


Node Redis and IORedis use TLS 1.2 by default.



  • Versions earlier than PHP 7: Predis supports only TLS 1.0. These versions don't work with TLS 1.2; you must upgrade to use TLS 1.2.

  • PHP 7.0 to PHP 7.2.1: Predis uses only TLS 1.0 or 1.1 by default. You can use the following workaround to use TLS 1.2. Specify TLS 1.2 when you create the client instance:

  • PHP 7.3 and later versions: Predis uses the latest TLS version.


PhpRedis doesn't support TLS on any PHP version.


Redis-py uses TLS 1.2 by default.


Redigo uses TLS 1.2 by default.

Additional information