What are the implications for ArcObjects SDK for the Microsoft .NET Framework and ArcGIS Engine .NET client applications when enforcing TLS 1.2-only connections?

Answer

Esri is planning to require TLS 1.2 connections for ArcGIS Online services starting on April 16, 2019. When TLS 1.2-only connections to ArcGIS Online resources are in effect, there are certain things to be considered when creating new ArcObjects SDK for the Microsoft .NET Framework applications (including  ArcGIS Engine for .NET), or running existing ones. At 10.7, the desktop software is already configured to use TLS 1.2 and no action is necessary to enable TLS 1.2.

If your client applications created with legacy ArcObjects .NET (including Engine applications) that use inbound connections to ArcGIS do not have TLS 1.2 enabled after the switch to TLS 1.2 only is made, your integrations may experience disruption.

The following changes can be made to ArcObjects .NET and Engine applications that were built with .NET versions prior to 4.6:

1. Recompile the application against the .NET Framework 4.6 or better to enable TLS 1.2 since 4.6 is compatible with TLS 1.2 by default (no code change is necessary).
2. .NET applications at 4.5.x do support the TLS 1.2 protocol, but not as the default, even if the OS environment has been set to TLS 1.2. A physical code change is required, as explained on page 9 in the ArcGIS Platform SSL/TLS Support and Configuration Briefing. See note below for example on how to set this value in the application.
3. .NET applications at 4.0 do 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
     These 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. These registry values, however, will not affect .NET applications that set the System.Net.ServicePointManager.SecurityProtocol value.

Note:
.NET applications may directly enable TLS 1.2 by setting System.Net.ServicePointManager.SecurityProtocol to enable SecurityProtocolType.Tls12, as shown in the example below.

Example (C#):
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;

Additional resources for transitioning to TLS 1.2 for the Esri platform, can be found on the on the Important Updates for the ArcGIS Platform and Transport Layer Security (TLS) Protocol Support pages, including references to Microsoft developer documents and the Esri Product Security team.

HTTP
Concerning the use of HTTP in legacy applications, note that with a future security update to ArcGIS Online, all organizations must use HTTPS-only, as this is becoming a standard practice in the industry.

It may be that ArcObjects .NET applications that previously worked with HTTP experience certificate errors with HTTPS, because client machines do not have the relevant certificates in their certificate stores. Client machines, therefore, must be configured accordingly (for example, the relevant certificates added to the certificate stores). For testing and development, it is possible to create server ‘test’ certificates. This can allow developers to test their client code against a test server that only supports HTTPS without requesting a certificate from a Certificate Authority. This is common for intranet scenarios.

For more information on TLS 1.2, refer to the Esri Technical Support document: Important Updates for the ArcGIS Platform and Transport Layer Security (TLS) Protocol Support