Print this page

Salesforce disabling TLS 1.0

Knowledge Article Number 000221207
Description

This article contains all of the information currently available on Salesforce’s disablement of the TLS 1.0 encryption protocol. This article will be updated as new information becomes available. Please check back often for guidance on preparing for TLS 1.0 disablement.

This article was last updated on October 25, 2016; changes are highlighted in red. 
 

Table of Contents

 

Overview


Preparing for TLS 1.0 Disablement 

 

Impact on the Salesforce Help/Success Community

 

Impact on Salesforce Features

 

Impact on AppExchange Apps


Impact on Developer Tools


Resources

 

OVERVIEW
 

What is the change? 

Starting in June 2016, Salesforce will begin disabling the TLS 1.0 encryption protocol in a phased approach across impacted Salesforce services. The disablement of TLS 1.0 will prevent it from being used to access the Salesforce service within inbound and outbound connections.

TLS ensures that a connection to a remote endpoint is to the intended destination through encryption and endpoint identity verification. Salesforce web and API connections, along with email delivery, use TLS as a key component of their security. HTTPS (web) and STARTTLS SMTP (email) use TLS as a key component of their security.

After Salesforce disables TLS 1.0, any inbound connections to or outbound connections from your Salesforce org will need to use the TLS 1.1 or TLS 1.2 encryption protocol. This change will impact your user access to a number of Salesforce services, including access to websites, such as Salesforce Communities, Customer and Partner portals, Force.com sites, and Site.com. 

Salesforce has already enabled TLS 1.1 and TLS 1.2 for outbound connections from Salesforce, and TLS 1.1 and 1.2 is already enabled in connections to Salesforce.
 

Why is this happening?

At Salesforce, trust is our #1 value, and we take the protection of our customers' data very seriously. The disablement of TLS 1.0 is being undertaken so we can maintain the highest security standards and promote the safety of your data as well as align with industry-wide best practices. 
 

When will Salesforce disable TLS 1.0 encryption?

The timeframes for disabling the use of TLS 1.0 to and from Salesforce can be found below. Each listed service must be compatible with TLS 1.1 or later by the dates below.

ServiceTLS 1.0 Disablement Schedule
New production
orgs created with Summer '16 or later

TLS 1.0 is disabled by default.

New production orgs created with Summer ‘16 or later will have the "Require TLS 1.1 or higher for HTTPS connections” Critical Update Console (CRUC) setting auto-enabled. This will disable TLS 1.0 by default.

This setting can be deactivated by the customer to enable TLS 1.0 as needed for TLS compatibility testing. See the article for details on user permissions required to view and change the setting.

Sandbox orgs

June 25, 2016, at 9:30 AM PDT (16:30 UTC)

After this date and time, all sandbox orgs -- whether existing, refreshed, or new -- will have TLS 1.0 automatically disabled and will require TLS 1.1 or later in HTTPS connections to or from the sandbox org. The "Require TLS 1.1 or higher for HTTPS connections" CRUC setting will not be available.

Production orgs

March 4, 2017, at 9:30 AM PST (17:30 UTC)

login.salesforce.com,
other services*
       Early 2017

NOTE: The disablement for orgs will not occur over a staggered period. All org types will have TLS 1.0 disabled based on the date and time stamp outlined above.

* Other services include the following: test.salesforce.com, www.salesforce.com, help.salesforce.com, store.salesforce.com, success.salesforce.com, branded login (*.cloudforce.com), Live Agent, UMPS/Chatter Messenger and Email.
 

PREPARING FOR TLS 1.0 DISABLEMENT
 

What do I need to do to be prepared for this change?

The action required by your organization will depend on which channels are used to access your Salesforce org, as well as which Salesforce services are in use by your org. 


What are the channels that access Salesforce where action may be needed?

There are three different channels that require encryption to access Salesforce:

  1. Internet browser
  2. API (inbound) integrations
  3. Call-out (outbound) integrations

An overview of each and our corresponding recommendation for TLS 1.1 and higher compatibility is as follows:
 

Internet Browsers

You and your users will experience issues  accessing Salesforce via your browser if non-supported browsers are in use or if you have disabled the supported encryption protocols in the browser. 
 

How to test your browser compatibility

If you are able to view our test site–which has TLS 1.0 disabled–without errors, access to Salesforce via your browser should not be impacted by this change, and no action is required.
 

Action Required for Browser Compatibility

If you experience errors, you need to ensure your browsers are compatible with TLS 1.1 or higher. If your browser is not compatible with TLS 1.1 or higher after we make this change, your users will NOT be able to access Salesforce. We recommend that you begin planning to support TLS 1.1 and TLS 1.2 as soon as possible.

NOTE: The minimum required action is to enable TLS 1.1 or TLS 1.2 encryption protocol within your browser security settings. Although we recommend disabling TLS 1.0 for a more secure browsing experience, it is not required. For example, if a user has protocols TLS 1.0, TLS 1.1, and TLS 1.2 enabled within their browser's security settings, they will be able to successfully connect to Salesforce with that browser after Salesforce disables TLS 1.0 on March 4, 2017.

Refer to the compatibility guidelines below:

Browser

Compatibility Notes

Microsoft Internet Explorer (IE)

Review the Enabling TLS 1.1 and TLS 1.2 in Internet Explorer knowledge article for more details.

Desktop and mobile IE version 11

Compatible with TLS 1.1 or higher by default

If you see the "Stronger security is required" error message, you may need to turn off the TLS 1.0 setting in the Internet Options | Advanced Settings list.

Desktop IE versions 8, 9, and 10

Compatible only when running Windows 7 or newer, but not by default. Review the Enabling TLS 1.1 and TLS 1.2 in Internet Explorer article to enable TLS 1.1 or higher encryption.

Windows Vista, XP and earlier are incompatible and cannot be configured to support TLS 1.1 or TLS 1.2.

Desktop IE versions 7 and below

Not compatible with TLS 1.1 or higher encryption.

Mobile IE versions 10 and below

Not compatible with TLS 1.1 or higher encryption.

Microsoft Edge

Compatible with TLS 1.1 or higher by default.

Mozilla Firefox

Compatible with the most version, regardless of operating system.

Firefox 27 and higher

Compatible with TLS 1.1 or higher by default.

Firefox 23 to 26

Compatible, but not by default.
Use about:config to enable TLS 1.1 or TLS 1.2 by updating the security.tls.version.max config value to 2 for TLS 1.1 or 3 for TLS 1.2.

Firefox 22 and below

Not compatible with TLS 1.1 or higher encryption.

Google Chrome

Compatible with the most recent version, regardless of operating system.

Google Chrome 38 and higher

Compatible with TLS 1.1 or higher by default.

Google Chrome 22 to 37

Compatible when running on Windows XP SP3, Vista, or newer (desktop), OS X 10.6 (Snow Leopard) or newer (desktop), or Android 2.3 (Gingerbread) or newer (mobile).

Google Chrome 21 and below

Not compatible with TLS 1.1 or higher encryption.

Google Android OS Browser

Android 5.0 (Lollipop) and higher

Compatible with TLS 1.1 or higher by default.

Android 4.4 (KitKat) to 4.4.4

May be compatible with TLS 1.1 or higher. Some devices with Android 4.4.x may not support TLS 1.1 or higher.

Android 4.3 (Jelly Bean) and below

Not compatible with TLS 1.1 or higher encryption.

Apple Safari

Desktop Safari versions 7 and higher for OS X 10.9 (Mavericks) and higher

Compatible with TLS 1.1 or higher by default.

Desktop Safari versions 6 and below for OS X 10.8 (Mountain Lion) and below

Not compatible with TLS 1.1 or higher encryption.

Mobile Safari versions 5 and higher for iOS 5 and higher

Compatible with TLS 1.1 or higher by default.

Mobile Safari for iOS 4 and below

Not compatible with TLS 1.1 or higher encryption.

 

API (inbound) Integrations 

API Integrations are interfaces or applications–including mobile apps and desktop clients–that are separate from Salesforce, but use Salesforce data. If you have any API Integrations, please ensure that the TLS 1.1 and/or TLS 1.2 encryption protocols are enabled in those integrations.
 

Action Required for API (Inbound) Integrations

If your integrations that use inbound connections to Salesforce do not have TLS 1.1 and/or TLS 1.2 enabled after we make this change, your integrations may experience disruption. We recommend that you begin planning to support TLS 1.1 and TLS 1.2 as soon as possible. 

Please refer to the compatibility guidelines below:

 

Platform or Library

Compatibility Notes

Java (Oracle)

Compatible with the most recent version, regardless of operating system

Java 8 (1.8) and higher

Compatible with TLS 1.1 or higher by default.

Java 7 (1.7)

Enable TLS 1.1 and TLS 1.2 using the https.protocols Java system property for HttpsURLConnection. To enable TLS 1.1 and TLS 1.2 on non-HttpsURLConnection connections, set the enabled protocols on the created SSLSocket and SSLEngine instances within the application source code. Switching to IBM Java may be an effective workaround if upgrading to a newer Oracle Java version isn't feasible.

Java 6 (1.6) update 111 and higher

 

Enable TLS 1.1 using the https.protocols Java system property for HttpsURLConnection. To enable TLS 1.1 on non-HttpsURLConnection connections, set the enabled protocols on the created SSLSocket and SSLEngine instances within the application source code. This Java 6 update and newer updates are not publicly available and require a support contract for Java 6 from Oracle

Java 6 (1.6) and below (publicly available version)

Not compatible with TLS 1.1 or higher encryption. Switching to IBM Java may be an effective workaround if upgrading to a newer Oracle Java version isn't feasible.

Java (IBM)

Java 8

Compatible with TLS 1.1 or higher by default. You may need to set com.ibm.jsse2.overrideDefaultTLS=true if your application or a library called it by it uses SSLContext.getinstance("TLS").

Java 7 and higher, Java 6.0.1 service refresh 1 (J9 VM2.6) and higher, Java 6 service refresh 10 and higher

Enable TLS 1.2 using the https.protocols Java system property for HttpsURLConnection and the com.ibm.jsse2.overrideDefaultProtocol Java system property for SSLSocket and SSLEngine connections, as recommended by IBM's documentation. You may also need to set com.ibm.jsse2.overrideDefaultTLS=true.

.NET

Compatible with the most recent version when running in an operating system that supports TLS 1.1 or TLS 1.2.

.NET 4.6 and higher

Compatible with TLS 1.1 or higher by default.

.NET 4.5 to 4.5.2

.NET 4.5, 4.5.1, and 4.5.2 do not enable TLS 1.1 and TLS 1.2 by default. Two options exist to enable these, as described below.

Option 1:
.NET applications may directly enable TLS 1.1 and TLS 1.2 in their software code by setting System.Net.ServicePointManager.SecurityProtocol to enable SecurityProtocolType.Tls12 and SecurityProtocolType.Tls11. The following C# code is an example:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;

Option 2:
It may be possible to enable TLS 1.2 by default without modifying the source code by setting the SchUseStrongCrypto DWORD value in the following two registry keys to 1, creating them if they don't exist: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" and "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319". Although the version number in those registry keys is 4.0.30319, the .NET 4.5, 4.5.1, and 4.5.2 frameworks also use these values. Those registry keys, however, will enable TLS 1.2 by default in all installed .NET 4.0, 4.5, 4.5.1, and 4.5.2 applications on that system. It is thus advisable to test this change before deploying it to your production servers. This is also available as a registry import file. These registry values, however, will not affect .NET applications that set the System.Net.ServicePointManager.SecurityProtocol value.

.NET 4.0

.NET 4.0 does not enable TLS 1.2 by default. To enable TLS 1.2 by default, it is possible to install .NET Framework 4.5, or a newer version, and set the SchUseStrongCrypto DWORD value in the following two registry keys to 1, creating them if they don't exist: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" and "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319". Those registry keys, however, may enable TLS 1.2 by default in all installed .NET 4.0, 4.5, 4.5.1, and 4.5.2 applications on that system. We recommend testing this change before deploying it to your production servers. This is also available as a registry import file.

These registry values, however, will not affect .NET applications that set the System.Net.ServicePointManager.SecurityProtocol value.

.NET 3.5 and below

Not compatible with TLS 1.1 or higher encryption

Python

Compatible with the most recent version when running on an operating system that supports TLS 1.1 or TLS 1.2.

Python 2.7.9 and higher

Compatible with TLS 1.1 or higher by default.

Python 2.7.8 and below

Not compatible with TLS 1.1 or higher encryption

Ruby

Compatible with the most recent version when linked to OpenSSL 1.0.1 or higher.

Ruby 2.0.0

TLS 1.2 is enabled by default when used with OpenSSL 1.0.1 or higher. Using the :TLSv1_2 (preferred) or :TLSv1_1 symbols with an SSLContext's ssl_version helps ensure that TLS 1.0 or earlier is disabled.

Ruby 1.9.3 and below

The :TLSv1_2 symbol does not exist in 1.9.3 and below, but it is possible to patch Ruby to add that symbol and compile Ruby with OpenSSL 1.0.1 or higher.

Microsoft WinINet

Compatible with the most recent version.

Windows Server 2012 R2 and higher

Windows 8.1 and higher

Compatible with TLS 1.1 or higher by default.

Windows Server 2008 R2 to 2012

Windows 7 and 8

Compatible by default if Internet Explorer 11 is installed. If Internet Explorer 8, 9, or 10 is installed, then TLS 1.1 and TLS 1.2 will need to get enabled by the user or an administrator for compatibility. Review the Enabling TLS 1.1 and TLS 1.2 in Internet Explorer article to enable TLS 1.1 or higher encryption.

Windows Server 2008 and below

Windows Vista and below

Not compatible with TLS 1.1 or higher encryption.

Microsoft Secure Channel (Schannel)

Compatible with the most recent version.

Windows Server 2012 R2 and higher

Windows 8.1 and higher

Compatible with TLS 1.1 or higher by default.

Windows Server 2012

Windows 8

TLS 1.1 and TLS 1.2 are disabled by default, but are available if enabled by an application. TLS 1.1 and TLS 1.2 can be enabled by default within the registry. Those registry settings are also available as a registry import file

Windows Server 2008 R2

Windows 7

Compatible by default in client mode when Internet Explorer 11 is installed. If Internet Explorer 11 is not installed or if Salesforce needs to connect to a service running on this type of system, then TLS 1.1 and TLS 1.2 can be enabled by default within the registry. Those registry settings are also available as a registry import file

Windows Server 2008 and below

Windows Vista and below

Not compatible with TLS 1.1 or higher encryption.

Microsoft WinHTTP and Webio

Windows Server 2012 R2 and higher

Windows 8.1 and higher

Compatible with TLS 1.1 and TLS 1.2 by default

Windows Server 2008 R2 SP1 and 2012

Windows 7 SP1

With KB3140245 applied, Webio is compatible by default, and WinHTTP can be configured via registry settings to enable TLS 1.1 and TLS 1.2.

Windows Server 2008 and below

Windows Vista and below

Not compatible with TLS 1.1 or higher encryption

OpenSSL

Compatible with the most recent version, regardless of operating system.

OpenSSL 1.0.1 and higher

Compatible with TLS 1.1 or higher by default.

OpenSSL 1.0.0 and below

Not compatible with TLS 1.1 or higher encryption.

Mozilla NSS

Compatible with the most recent version, regardless of operating system.

3.15.1 and higher

Compatible with TLS 1.1 or higher by default.

3.14 to 3.15

Compatible with TLS 1.1, but not with TLS 1.2.

3.13.6 and below

Not compatible with TLS 1.1 or higher encryption.

 

How do I test the compatibility of an API (inbound) integration to Salesforce?

To test the compatibility of an API client that uses SOAP to communicate with Salesforce:

1. Set up an API client in a test environment.
2. In that test environment, change the API client's login endpoint hostname from login.salesforce.com or [MyDomain].my.salesforce.com to tls1test.salesforce.com.

As an example, change https://login.salesforce.com/services/Soap/u/32.0 to https://tls1test.salesforce.com/services/Soap/u/32.0 while leaving the path as-is.

3. Log in with that API client.
4. If you see an error message that resembles the following: "INVALID_LOGIN: Invalid username, password, security token; or user locked out." or “Content is not allowed in prolog.”, then this test passed and your integration works with either TLS 1.1 or TLS 1.2.

The presence of this response means that the underlying TLS connection was successful, despite the higher-level error. The TLS connection is the focus of this test.

5. If you instead see an error message that involves TLS or HTTPS, then the test has failed. Your API client will require adjustments or upgrades to operate properly with Salesforce, when Salesforce deactivates TLS 1.0.

To test the compatibility of an API client that uses REST to communicate with Salesforce:

1. Set up an API client in a test environment.
2. In that test environment, change the API client's access token retrieval endpoint hostname from login.salesforce.com or [MyDomain].my.salesforce.com to tls1test.salesforce.com.

As an example, change https://na1.salesforce.com/services/oauth2/token to https://tls1test.salesforce.com/services/oauth2/token while leaving the path as-is.

3. Alternatively, it's possible to change an API client's service URL from [instance].salesforce.com or [MyDomain].my.salesforce.com to tls1test.salesforce.com.

As an example, change https://na1.salesforce.com/services/data/v32.0/ to https://tls1test.salesforce.com/services/data/v32.0 while leaving the path as-is.

4. If you see an OAuth error, an "INVALID_SESSION_ID Authorization required" error, or a "400 Bad Request" error, then this test passed.

The presence of this response means that the underlying TLS connection was successful, despite the higher-level error. The TLS connection is the focus of this test.

5. If you instead see an error message that involves TLS or https, then the test has failed. Your API client will require adjustments or upgrades to operate properly with Salesforce, when Salesforce deactivates TLS 1.0.

 

Call-out (outbound) Integrations

Call-outs are integrations where Salesforce refers to an outside source to either verify login credentials, push data, or pull data. Examples of call-outs include: Delegated Authentication Single-Sign-On (SSO), Outbound Messaging, and Apex call-outs. If you use call-out integrations, please ensure that TLS 1.1 and/or TLS 1.2 are enabled in those integrations.


Action Required for Call-Out (Outbound) Integrations

If your integrations that use outbound connections from Salesforce do not have TLS 1.1 and/or TLS 1.2 enabled after we make this change, your integrations may experience disruption. We recommend that you begin planning to support TLS 1.1 and TLS 1.2 as soon as possible. 


Compatibility Guidelines

The general compatibility guidelines from the API (inbound) integrations (see section above) can be used to help achieve TLS 1.1 and later compatibility. However, since the technologies and vendors used to run the remote endpoints can vary, the teams that manage the endpoints will need to work to achieve TLS 1.1 or TLS 1.2 compatibility on the end points that they run. 
 

How do I test the compatibility of a call-out (outbound) integration from Salesforce?

Test Method 1:
A way to test for TLS 1.1 and TLS 1.2 compatibility is to use the Qualsys SSL Labs test site at https://www.ssllabs.com/ssltest/ if your https endpoints are publicly accessible. In the test results, ensure that TLS 1.1 and/or TLS 1.2 support is reported as working properly.

Test Method 2:
Another way to test is to use OpenSSL 1.0.1 or newer with either the -tls1_1 or -tls1_2 command line options when making an s_client callout to your https endpoints. An example OpenSSL command is the following. Replace www.your-callout-endpoint.net with the hostname of your https endpoint and, if needed, replace port 443 with the service port of your https endpoint.

openssl s_client -connect www.your-callout-endpoint.net:443 -showcerts -tls1_2

If the OpenSSL test is successful, then you will not be returned to the command prompt but, instead, will see successful messages before OpenSSL awaits input to send to the remote endpoint. Press Control+C to exit OpenSSL. If the OpenSSL test is not successful, then you will see error messages and will be returned to the command prompt.

NOTE: The Mac OS X, including El Capitan, ships with an old version of the OpenSSL command line, and that version does not include TLS 1.1 and TLS 1.2 support. Alternatives, such as Homebrew from http://brew.sh/, may be used to install a newer version of OpenSSL on Mac OS X.


How can I help my end users manage this change?

You can provide your users (including both internal and external community users) with a notification when they access Salesforce using TLS 1.0 that advises them to either update their web browser setting or upgrade their web browser.

To do so, leverage the following methods:


AppExchange package:

Install and configure the TLS 1.0 Compatibility User Message AppExchange package to easily provide in-app notifications to your TLS 1.0 users informing them on what to do in order to reach TLS 1.1 or higher compatibility. Installation instructions are available from the AppExchange listing.


Visualforce Page Controller:

If you are familiar with Visualforce and Apex development, you can check the ApexPages.currentPage().getHeaders().get('CipherSuite') value, if not null, for the ' TLSv1 ' (including the leading and trailing space) substring. If that is present, then TLS 1.0 is being used, and the Visualforce page can display a notice that advises them to either update their web browser settings or upgrade their web browser.

 

New TLS Protocol Field in the Login History 

Beginning in Summer ‘16, Salesforce plans to deliver a TLS protocol field in the login history. This can help identify which users and software are continuing to rely on TLS 1.0 in their connections to Salesforce.  See the Summer ‘16 Release Notes for more details. 

From Setup in Summer '16, enter Login History in the Quick Find box, then select Login History. To view TLS 1.0 logins, it is possible to download the history by selecting TLS 1.0 Logins ONLY from the File Contents list and clicking Download Now. Alternatively, it is possible to create a new view that filters by TLS 1.0 logins.

Other options that Salesforce plans to deliver in Summer '16 for tracking TLS 1.0 logins include the following:


How can I do general testing prior to the Salesforce disablement of TLS 1.0?

You can test the disablement of TLS 1.0 for your sandbox and production org prior to the Salesforce disablement using the new Critical Update Console (CRUC) setting–"Require TLS 1.1 or higher for HTTPS connections".

We recommend that you test this CRUC update in a sandbox environment to verify end-to-end compatibility before testing it in your production org. 

See the TLS 1.0 Disablement Critical Update Console (CRUC) Setting article for more details. 


What if I use an intercepting HTTPS proxy server in my network?

Some networks intercept outbound HTTPS traffic by using a proxy server that creates its own certificates so that the unencrypted communications with Salesforce and other endpoints can be inspected. Those proxy servers create their own TLS connections to Salesforce. Networks that use this type of proxy server need to ensure that it supports TLS 1.2 and prefers TLS 1.2 when connecting to Salesforce. Irregular behavior may be observed if the proxy server either does not support TLS 1.0 or prefers TLS 1.0 over TLS 1.2 when connecting to remote endpoints.

If connections to https://tls1test.salesforce.com are successful, but the "Stronger security is required" error message is displayed after the "Require TLS 1.1 or higher for HTTPS connections" critical update is activated, it is likely that an intercepting HTTPS proxy server is not preferring TLS 1.2 over TLS 1.0 when it initiates a TLS connection with Salesforce. 

The general configuration recommendations regarding intercepting HTTPS proxy servers regarding the TLS 1.0 disablement are the following:

  • Update the intercepting HTTPS proxy server to not intercept the HTTPS connections to Salesforce's *.salesforce.com and *.force.com subdomains. This is preferred as it ensures end-to-end confidentiality between the end-users' web browsers and Salesforce.
  • If HTTPS interception is required by the company's policy or otherwise cannot be removed or exempted, update that proxy server to a newer version that supports TLS 1.2 or, at least, TLS 1.1. When the critical update is enabled, the intercepting HTTPS proxy server will have its requests at the application layer rejected if it negotiated TLS 1.0 with Salesforce.
  • If the intercepting HTTPS proxy server does support TLS 1.2, but prefers TLS 1.0 by using TLS 1.0 in its initial ClientHello messages, update the proxy server's configuration to prefer TLS 1.2 over TLS 1.0 when connecting to Salesforce's *.salesforce.com and *.force.com domain names.



IMPACT ON SALESFORCE HELP/SUCCESS COMMUNITY

Browser incompatibility will also impact the ability for Salesforce users to access and use the following:



IMPACT ON SALESFORCE FEATURES


Microsoft Integration Products

To continue using Lightning for Outlook, Lightning Sync, or Salesforce for Outlook, IT administrator and user action will be required to verify that 1) users' local computing environments are compatible with TLS 1.1 and higher; and 2) the requirements for each application are met.

NOTE: Before Summer '16, Lightning for Outlook was known as Salesforce App for Outlook, and Lightning Sync was known as Exchange Sync.

For full details on the action required, review the appropriate article:

 

Prepare Your Org to Continue Using Lightning for Outlook and Lightning Sync When TLS 1.0 Disablement Begins

Prepare Your Org to Continue Using Salesforce for Outlook After TLS 1.0 is Disabled

 

Additionally, the following Microsoft integration products will be impacted after TLS 1.0 is disabled:

  • Connect for Office: The support for Connect for Office will retire and may not function when Salesforce disables TLS 1.0. See our Spring ’16 release notes for more details. Users are strongly encouraged to transition to the following alternatives:
  • Microsoft Word Add-In 
  1. Manual entry of merge Salesforce fields in Word templates; or
  2. AppExchange solution (customers should verify with the AppExchange partner directly on the solution’s TLS 1.1 and higher compatibility)
  • Microsoft Excel Add-In
  1. CSV file export directly from Salesforce (Salesforce Classic Only); or
  2. AppExchange solution (customers should verify with the AppExchange partner directly on the solution’s TLS 1.1 and higher compatibility)
  3. Microsoft Power BI or Microsoft Power Query
  • Standard Mail Merge: The support for standard Mail Merge will retire and may not work when Salesforce disables TLS 1.0. Users are strongly encouraged to transition to Extended Mail Merge, which supports TLS 1.1. See our Spring ’16 release notes for more details.
  • Connect for Outlook: This feature was retired in Winter ’16 and will not be tested for TLS 1.1 and higher compatibility. Prepare your users by transitioning them to TLS 1.1 compatible features such as Lightning for Outlook, Lightning Sync, or Salesforce for Outlook.

 

Salesforce mobile apps

Upon the disablement of TLS 1.0, the following mobile operating systems and Salesforce app versions are required to support the use of the following Salesforce mobile apps:

Mobile AppRequired iOS and Salesforce app versionRequired Android and Salesforce app version
Salesforce Classic*

SF Classic version 4.6.10 (latest) requires iOS 7.x and later

iOS devices with iOS 5.x and later with existing SF Classic installs will continue to operate

No minimum SF Classic version

Android 5.x and later

No minimum SF Classic version.

Salesforce1
(downloadable app + browser app)
Salesforce1 for iOS version 7.3.4

iOS 8.x and later
Salesforce1 for Android version 8.0

Android 4.4.x and later
SalesforceA

SalesforceA for iOS version 3.0.0 and later.

iOS 8.x and later

SalesforceA for Android version 3.0.0 and later

Android 4.4.x and later

* No version of BlackBerry will work with Salesforce Classic after the disablement of TLS 1.0. 

 

Data Loader

To ensure no disruption to the use of Data Loader, customers need to download the newest version of data loader, released with Spring '16, which is the only version that supports TLS 1.1 and higher. 

 

Identity Connect

The disablement of TLS 1.0 will impact the provisioning capabilities of Identity Connect. Customers who do not upgrade to Identity Connect version 2.1.0 prior to the TLS 1.0 disablement will be unable to propagate any user account or entitlement changes from Active Directory to Salesforce, including user creation and disablement. Please note that user authentication for existing users will not be impacted.

The Identity Connect upgrade should be performed during off-peak hours, as the service will be unavailable during the upgrade. A backup of your current install is recommended prior to performing the upgrade to ensure the ability to perform a rollback if needed. Additionally, the upgrade will require an update to Java 8 on all servers hosting Identity Connect.

The newest version for either a Windows or Linux system can be downloaded from Setup | Security Controls | Identity Connect within Salesforce. Customers should review section 2.6, “Upgrading an Identity Connect instance”, within the Implementation Guide for more details on how to upgrade. 

See the New Identity Connect Release Available for TLS Compatibility article for more details.

 

Communities and Sites

Users will be unable to connect to Communities or Sites unless their browser or browser settings are updated per the compatibility guidelines mentioned above. Customers should inform their Community and/or Site users to update their browser or browser settings as soon as possible. See the Internet Browser compatibility section above for detailed guidance. 

To prepare for your transition to support TLS 1.1 and later, conduct early testing with your users by disabling TLS 1.0 for your org via the new Critical Update Console setting: “Require TLS 1.1 or higher for HTTPS connections”. See the TLS 1.0 Disablement Critical Update Console (CRUC) Setting article for more details. 

 

Custom HTTPS Domains

Users will be unable to connect to your custom HTTPS domain sites unless their browser or browser settings are updated per the compatibility guidelines mentioned above. Customers should inform their users to update their browser or browser settings as soon as possible. See the Internet Browser compatibility section above for detailed guidance. 

To prepare for your transition to support TLS 1.1 and later, conduct early testing with your users by disabling TLS 1.0 for your org via the new Critical Update Console setting: “Require TLS 1.1 or higher for HTTPS connections”. See the TLS 1.0 Disablement Critical Update Console (CRUC) Setting article for more details.



CTI Toolkit and Open CTI
 

CTI Toolkit

The CTI Toolkit will not support TLS 1.1 and higher and all CTI Toolkit functionality will no longer work after the product retirement in Spring ‘17. See the CTI Toolkit Feature Retirement in Spring ‘17 article for more details. 

We previously communicated that the end-of-support for the CTI Toolkit would take place in Spring ‘15 (February 2015). With the Spring ’17 release*, the CTI Toolkit will end of life and no longer function. Any telephony integrated functionality using the CTI Toolkit will cease to work. Telephony partners will no longer be able to support the CTI Toolkit beyond Spring ‘17.

If you are currently using the CTI Toolkit, you need to transition to the Salesforce Open CTI alternative to ensure no disruption to your use of this functionality. While there is no cost to use the Salesforce Open CTI solution, contact your telephony partner for details on any costs or services required to transition to Salesforce Open CTI. 

*Currently targeted for February 2017; date subject to change

 

Open CTI

As Open CTI is a cloud-based solution, users need to ensure that their browsers support TLS 1.1 or TLS 1.2 in order to support the web-based telephony integrated functionality. See the Internet Browser compatibility section above for detailed guidance. 

The on-premises Open CTI connector’s connection from the PBX/telephony system to Salesforce also needs to support TLS 1.1 or TLS 1.2. 

 

Chatter Desktop

Windows

To support TLS 1.1 or higher, Chatter Desktop for Windows users will need to update their Internet Explorer configuration. Alternatively, TLS 1.1 and TLS 1.2 can be enabled using Active Directory group policies. See the Enabling TLS 1.1 and TLS 1.2 in Internet Explorer article for more guidance.   

 

Mac

To support TLS 1.1 or higher and ensure no disruption to the use of Chatter Desktop for Mac, users will need to do all of the following:

  • Install and update with the latest release of Chatter Desktop for Mac. 
  • Update the Adobe AIR patch to 21.0.0.176 or higher.

See the Install Chatter Desktop and Install Chatter Desktop Managed Version help topics for more guidance on the install process. 
 


Salesforce File Sync

To support TLS 1.1 and higher and ensure no disruption to the use of File Sync, users will need to upgrade to the latest release, version 1.9, available for upgrade directly from the client application. Review the Salesforce File Sync System Requirements article for more details. 

 

SalesforceIQ

Product

TLS 1.1 and Higher Compatibility Requirements

SalesforceIQ Inbox for iOS

Any version of the SalesforceIQ Inbox for iOS may be used since it only supports iOS 5 and higher and iOS 5 supports TLS 1.1 and TLS 1.2.

SalesforceIQ Inbox for Android

Android KitKat (4.4.x) devices will need to be running Salesforce Inbox for Android version 2.5.1.

Android Lollipop (5.x) devices include native support for TLS 1.1 and TLS 1.2 and do not require a specific version of the SalesforceIQ Inbox for Android app. 

SalesforceIQ Inbox Chrome extension

Chrome provides support for TLS 1.1 and TLS 1.2. No action is required for customers to support the Chrome extension. 

SalesforceIQ Inbox for Outlook Desktop add-in

Internet Explorer version 11 

SalesforceIQ Inbox     for Outlook Mac

Internet Explorer version 11 and Microsoft Edge 
Latest version of Chrome and Firefox
Desktop Safari version 9 or higher on OS X v10.9 (Mavericks) and higher.

SalesforceIQ Inbox     for Office 365 add-in

Desktop Safari version 9 or higher on OS X v10.9 (Mavericks) and higher. 

 

Marketing Cloud

See the Marketing Cloud documentation on TLS Support for full details and updates. 

 

Pardot B2B Marketing Automation

The Pardot connector to Salesforce was updated on June 25th, 2016 for the latest TLS compatibility and no customer action. Follow this post within the Pardot B2B Marketing Automation Success Community group for updates and questions. 

 

Single Sign-On

All forms of authentication with Salesforce will be impacted by the TLS 1.0 disablement. 

Delegated Authentication

If the callout which Salesforce sends to the delegated authentication endpoint is an HTTPS URL, then the callout will need to support TLS 1.1 or TLS 1.2.

SAML

  • Salesforce as a SAML Identity Provider (IdP) – If you are using Salesforce as a SAML IdP and TLS 1.0 is disabled in your org, users using incompatible web browsers that only support TLS 1.0 won’t be able to access the IdP.
  • Salesforce as a SAML Service Provider (SP) – If you are using Salesforce as a SAML SP and TLS 1.0 is disabled in your org, users using incompatible web browsers that only support TLS 1.0 won’t be able to access the org.




IMPACT ON APPEXCHANGE APPS

Determine if your AppExchange apps are compliant with Salesforce TLS 1.0 disablement by engaging with the vendor and/or partner directly. 

IMPACT ON DEVELOPER TOOLS

 

Mobile apps developed with the Salesforce Mobile SDK

If your Salesforce Mobile SDK-created apps do not support TLS 1.1 or higher after Salesforce disables TLS 1.0, then your existing mobile apps will be unable to interface with Salesforce.

To avoid loss of functionality in your app, apply the following changes to your app as soon as possible:

iOS

No changes are required for Mobile SDK apps built with iOS 5.0 or later. Older apps must be updated to support iOS 5.0 or later. 

Android

  • Earlier than 4.4.x (KitKat): Android versions older than 4.4 don’t support TLS 1.1/1/2 and therefore are no longer supported by the Salesforce Mobile SDK. Existing applications that target these platforms will stop working when TLS 1.0 is disabled.
  • 4.4.x (KitKat): Applications targeting 4.4.x will require a fix to be applied and the app to be re-published to Google Play prior to Salesforce’s disablement of TLS 1.0 in early 2017. See the Applying the Mobile SDK Fix on Android 4.4 (KitKat) for more details.
  • 5.x (Lollipop) and later: 5.x and later use TLS 1.1/1.2 by default and won’t require a Salesforce Mobile SDK update. Existing applications targeting these platforms will continue to work without changes.

 

Force.com Migration Tool

Starting with version 36.0, the Force.com Migration Tool automatically enables TLS 1.1 and 1.2 if it detects Java version 7 (1.7). 

Java 8 (1.8) enables TLS 1.1 and TLS 1.2 by default. 

Using Java version 7 (1.7)

Download version 36.0 or later of the Force.com Migration Tool to enable TLS 1.1/1.2. 

If you are using a Force.com Migration Tool version older than 36.0, you must enable TLS 1.1 and TLS 1.2 explicitly and disable TLS 1.0. To do so, add the following to your ANT_OPTS environment: variable: -Dhttps.protocols=TLSv1.1,TLSv1.2. 

NOTE: This setting also enforces TLS 1.1 or 1.2 for any other ant tools on your local system.

 

Force.com IDE Plug-In for Eclipse

If you use Java 7, you can’t create or edit projects using the Force.com IDE plug-in for Eclipse unless you disable TLS 1.0. (TLS 1.0 is disabled by default in Java 8.) Update your eclipse.ini file to include this line.

-Dhttps.protocols=TLSv1.1,TLSv1.2

The location of the eclipse.ini file depends on your operating system. For more information, see https://wiki.eclipse.org/Eclipse.ini.

 

RESOURCES


For additional questions, please reach out to Support by opening a case via the Help & Training portal.




Attachments
Name Type Size
TLS Readiness Checklist.pdf
133KB

promote demote