ArcGIS Platform SSL/TLS Support andConfiguration Briefing

Date:
Version:

2/21/2020
4.1

Prepared by:
Esri Software Security & Privacy Team
SoftwareSecurity@esri.com

1|PageIntroduction
Since POODLE came out in late 2014, marking the death of SSL v3 as a secure
protocol, Esri has evolved our support of both SSL & TLS across the ArcGIS Platformto provide you the best security options for your implementations. Security
standards such as PCI and FedRAMP have deprecated TLS 1.0, and since usage ofTLS 1.1 is not widespread, the version customers should now use is TLS 1.2.
ArcGIS Online transitioned to utilizing TLS 1.2 only on April 16, 2019. Esri
established a support page to help our customers at:https://support.esri.com/en/tls

General TLS/SSL architecture guidance for our products is provided later in thisdocument. By the way, if you have some custom systems/clients that are not
upgradable, you should consider utilizing ArcGIS Enterprise as an intermediate fix
until you are able to utilize current secure technology solutions. This document is
updated as new information becomes available.

What is TLS & Impact of ArcGIS Online Removing 1.0 & 1.1

TLS stands for “Transport Layer Security.” It is a protocol that provides privacy anddata integrity between two communicating applications. It’s the most widely
deployed security protocol used today and is used for web browsers and otherapplications that require data to be securely exchanged over a network. TLS ensuresthat a connection to a remote endpoint is the intended endpoint through encryption
and endpoint identity verification. The versions of TLS, to date, are TLS 1.0, 1.1, 1.2,
and 1.3. The spec for TLS 1.3 was approved August 2018 and is therefore notavailable yet from most cloud infrastructure providers nor Esri’s Online services.
The ArcGIS platform web and API connections use TLS as a key component of theirsecurity. HTTPS (web) uses TLS as a key component of its security. After ArcGIS
Online upgraded to only TLS 1.2 on April 16, 2019, any inbound or outboundconnections from your ArcGIS Online organization that rely on either TLS 1.0 or 1.1
will fail. Services that currently provide both HTTP and HTTPS continue to operatethat way after the April 16th TLS 1.2 enforcement date.

Esri has scheduled a September 15, 2020 maintenance window for enforcing
HTTPS only via HSTS. The action required by your organization will depend on
which clients and their versions are used to access your ArcGIS Online org as
described below.
Note: TLS 1.2 test endpoints are available for validating your applications at:https://support.esri.com/en/technical-article/000019897

2|PageClients Requiring Update/Fixes to Support TLS 1.2
Esri Products
•
•
•
•
•
•
•
•
•
•
•
•
•
•

ArcGIS Desktop – 10.6.1 and earlier (patch or registry entry needed)
ArcGIS Pro 1.0 – 1.2 (upgrade version or registry entry needed)
ArcScene, ArcCatalog – 10.6.1 and earlier (registry entry needed)
ArcGIS Enterprise – 10.4 and below (upgrade version, details here)
ArcGIS Runtime – See details here
ArcGIS Earth 1.4 and earlier – (upgrade version or registry entry needed)
Drone2Map 1.3.1 and earlier – (upgrade version or registry entry needed)
Operations Dashboard Windows App - (registry entry needed)
ArcGIS for AutoCAD v. 370 and earlier – (registry entry needed)
ArcPAD for Windows Desktop - (registry entry needed)
ArcGIS Explorer Desktop – (registry entry needed)
Explorer for ArcGIS on Windows – (registry entry needed)
Esri Resource Proxy – 1.1.1 and earlier (upgrade to version 1.1.2)
See the Resolution Details section below for details if applicable

Other Clients

Old Browsers• Firefox version 5.0 and earlier versions• Internet Explorer 8-10 on Windows 7 and earlier versions• Internet Explorer 10 on Win Phone 8.0• Safari 6.0.4/OS X10.8.4 and earlier versions
Old Mobile Devices•••

Android 4.3 and earlier versions
Leica Zino Collector (see Blog)
ArcPad using Mobile/CE 6.5 and earlier (CE v.7 patch for TLS 1.2 )Custom/3rd Party Scripts/Tools using Old Frameworks or old OS
•
•
•
•
•
•

Oracle Java 1.6 and earlier versions.NET 3.5 and earlier versions
Python 2.7.8 and earlier versions
OpenSSL 1.0.0 and earlier versions
Windows 2008 / Vista and earlier versions
Additional details may be found in the API Integration section of this doc

3|PageResolution Details for Esri Products with known TLS 1.2 Issues
ArcGIS Desktop-based Clients

Using the Add Data button to add data from ArcGIS Online or from Portal for ArcGIS
fails with an error by default for versions 10.6 and earlier (Add Data and Searchfunction correctly in ArcMap version 10.6.1 and later, but for ArcCatalog and
ArcScene Portal/ArcGIS Online organization search do not). These tools containcomponents built with the Microsoft .Net Framework. Prior to ArcGIS 10.6.1, thistool was built to target the highest TLS version .Net supported at the time theproduct was released. The below steps will address TLS issues with ArcGIS
Desktop, ArcScene, and ArcCatalog.
The error may read:

Guidance to address TLS issues with ArcGIS Desktop
Deploy relevant Desktop patch available here, or perform the below steps:
Step 1 – OS PatchIf your organization is attempting to run an older version of Desktop on older
Windows operating system builds you will need to first install a patch fromMicrosoft to allow support of TLS 1.2.
•

Windows 7 or Windows 2008 R2 Users - Install this patch•

Windows 2012 Users - Install this patch

If your system already has an appropriate patch or newer .NET version inplace, you may receive a prompt indicating the update is not applicable,
which is fine, proceed to the next step.

Step 2 – Add Windows Registry Entrya. ArcGIS Desktop 10.4 – 10.6 users - Click here to download , copy andpaste the text into notepad, save the file as ArcMapPost104TLS.reg
and then double-click the file to Run and deploy

4|Pageb. ArcGIS Desktop 10.2 – 10.3.x users – Click here to download , copy
and paste the text into notepad, save the file as ArcMapPre104TLS.reg
and then double-click the file to Run and deploy
c. Start ArcMap and test.

Notes for Desktop TLS Registry Fix:
1. Older clients - ArcGIS Desktop 10.0 – 10.1 can likely follow the same steps
as for 10.2-10.3 used, but upgrading the client is strongly recommended.
2. Fallback option - The registry entries above enable TLS 1.2 as a default for
all applications utilizing the relevant .NET version – This is a desired state formost organizations, but if there are any issues, the user can just remove theregistry entries.
3. Large deployments - If your organization has a large number of Desktop
systems and utilizes Active Directory, the registry entries can be centrally
deployed in less than 10 minutes by following the steps here.

ArcGIS Enterprise 10.3.1 and below Known Issues

Some operations in Portal for ArcGIS require Portal to act as a client, by consuming
resources provided by an application server like ArcGIS Online.

As mentioned previously, in April 2019, ArcGIS Online is moving toward a pure TLS
1.2 environment. When this occurs, Portal for ArcGIS version 10.3.1 and below will
be unable to consume some resources provided by ArcGIS Online.
•
•

•
•

Utility services will be affected because Portal will send credentials to ArcGIS
Online over https only.
Print services may be affected. Typically, Portal for ArcGIS uses theFederated ArcGIS Hosting Server's print service (or a print service hosted ona stand-alone ArcGIS Server). However, if the Portal does not reference anexternal print service, then Portal will use its own built-in print that will beaffected in Portal 10.3.1 and prior. Users who are using the hosting server's
print service will not be affected.
Stand-alone ArcGIS Servers will be unable to share newly published services
to ArcGIS Online through ArcGIS Server Manager in 10.3.1 and prior.
ArcGIS Online utility services registered with the Portal with saved
credentials, potentially including Esri provided locator services, routing
services, print tasks, and geometry services, and other ArcGIS Online hosted
web services that have been added as items to the Portal and include saved
credentials will be impacted.

5|PagePython•All versions of Python included with the ArcGIS Platform since 10.0 support
TLS.

General TLS Implementation Guidance

Customers today must balance general accessibility of their applications,compliance demands, utilizing the strongest security TLS version, and choosing theright architecture for TLS support as described below:

Architecture for TLS support

In general, application servers should NOT be the front-line for connecting TLS withclients. In other-words, when you are concerned about client communication withArcGIS Servers, the clients should be establishing their TLS communication withsome other web service device in front of ArcGIS (not directly with ArcGIS). This is
in-line with the premise of utilizing a DMZ and having web endpoints being from theclient to the web server / SSL accelerator located in the DMZ. This architecture
configuration decouples TLS client communication concerns from your applications
and allows more centralized certificate management and configuration throughdevices that support SSL acceleration. Yes, the separate web-endpoint could evenbe utilized with the ArcGIS Web Adaptor to piggyback on the TLS capabilities ofyour standard web server, instead of dealing with unique application server
SSL/TLS restrictions. To be clear, when you jump into the weeds, you will see thatin addition to SSL/TLS versions, secure communication with clients is further
managed by ciphers which is just the nail in the coffin as to why you should
seriously consider NOT terminating your client TLS communication with application
servers (such as ArcGIS), but instead standard web servers / load balancers /accelerators.

Easing the Transition to TLS 1.2 Only Organization-wide

Along the same lines of using an intermediate system in the DMZ to standardize
inbound communications, if your organization already utilizes a web security
gateway proxy for outbound communications you can potentially reduce theurgency for ensuring all your internal products such as ArcGIS Desktop are utilizing
TLS 1.2 protocols directly. Web security gateway proxies, frequently support
accepting TLS 1.0 traffic from internal clients and establishing TLS 1.2 connections
externally. Please contact your proxy vendor to confirm this is supported and thespecifics for how to configure it. For example F5 provides guidance to handle thiswith their BigIP proxy capabilities here.

With an appropriately configured web security gateway proxy, when an internal
product such as an older version of ArcGIS Desktop makes a TLS 1.0 call through a
proxy to ArcGIS Online after April 2019, the request will not fail, as the proxy will
accept the TLS 1.0 call and negotiate a TLS 1.2 call to ArcGIS Online.

6|PageArcGIS Platform Support••

SSLv2 is not enabled by default with ArcGIS 10 and later – e.g. Not
susceptible to DROWN
SSLv3 is not enabled by default with ArcGIS 10.3 and later – e.g. Not
susceptible to POODLE

Specific ArcGIS Product Support
ArcGIS Online
•
•
•
•

•

Currently supports only TLS 1.0, 1.1, and 1.2 (configuration since 2014).
With the September 2018 release, new organizations utilize only HTTPS.
Be aware, with the April 2019 release, TLS 1.0 & 1.1 will be disabled.
With the September 2020 release, ALL organization only use HTTPS (noHTTP).
HSTS (HTTP Strict Transport Security) is supported at the organization levelin ArcGIS Online. Organizations that allow only HTTPS benefit from HSTS
when members are logged into their ArcGIS Online organization. HSTS will
be enforces for all ArcGIS Online communications

Esri Managed Cloud Services (EMCS) Advanced Plus•

Utilizes only TLS 1.2 by default, but can enable other TLS versions as
required by customer.

ArcGIS Enterprise – ArcGIS Server, Portal for ArcGIS, and ArcGIS DataStore

Ideally, by following the architecture for TLS support section of this document
above, you are NOT having external clients communicate directly with Esri
application servers, therefore the below information is not as critical for the securityof your deployment. If you choose otherwise, the below information can be usefulfor your secure deployment planning efforts.
• SSLv2 – Disabled for ArcGIS 10 and later• SSLv3 – Disabled for ArcGIS 10.3 and later. Note that ArcGIS Server 10.1SP1
QIP, and 10.2 users can apply the security patch to disable SSLv3• TLSv1.0 – Enabled for ArcGIS 10 through 10.6 – Starting with 10.6.1, TLS 1.0
will be disabled by default in alignment with PCI and FedRAMP guidelines.
• TLSv1.1 & 1.2 - Enabled for ArcGIS 10.4 and later. Note that users can specify
server TLS versions and disable ciphers starting with ArcGIS 10.4
• New installations of ArcGIS Enterprise 10.6.1 disable TLS 1.0 by default.
• TLSv1.2 - New installations of ArcGIS Enterprise 10.7 disable TLS 1.0 and 1.1
by default. If an existing ArcGIS Enterprise instance is upgraded to version
7|Page•

10.6.1 or later, some of the TLS settings are retained but they should always
be reviewed after the completion of an upgrade.
HSTS (HTTP Strict Transport Security) is supported at the ArcGIS Enterprisetier starting at ArcGIS 10.6.1. For prior versions, HSTS may be implemented
by the customer at the web tier. See your web server documentation for
instructions for implementing HSTS.

There is currently no documented way to configure the TLS settings (ciphers or TLS
versions) for the ArcGIS Data Store's REST API. It is on Esri’s roadmap to provide
administrators greater control over their encryption settings in Data Store.
At ArcGIS 10.6.1, ArcGIS Data Store was updated to not allow TLS 1.0 and to use
strong ciphers.

Notes:• The Data Store endpoint is NOT intended for end-user connections and theonly workflow where a client uses a browser is during the installation andupgrade of the product.
• Esri recommends that port 2443 be firewalled off from users; only themachines running the ArcGIS Data Store and the ArcGIS Server need to beable to access port 2443 for backend communications.
• At ArcGIS 10.5 Esri added logic that causes port 2443 to select the strongest
cipher that a client supports - and since the clients are all internal, stronger
ciphers and protocols will be used.
• If this guidance is followed, hackers won't be able to use TLS 1.0
vulnerabilities to eavesdrop on internal backend traffic because TLS 1.0
wouldn't be used.

API Integrations & Customized Clients

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

Action Required for API Integrations

If your integrations that use inbound connections to ArcGIS do not have TLS 1.2
enabled after we switch to TLS 1.2 only, your integrations may experience
disruption. We recommend that you begin planning to support TLS 1.2 as soon as
possible.

8|PagePlease refer to the compatibility guidelines below:
PlatformorCompatibility Notes
LibraryJava (Oracle)
Compatible with the most recent version, regardless of operating system
Java 8(1.8) and Compatible with TLS 1.2 by default.
higherJava 7(1.7)

Enable TLS 1.2 using the https.protocols Java system property for
HttpsURLConnection. To enable 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) andbelow
Not compatible with TLS 1.2 or higher encryption. Switching to IBM Java may be an(publicly effective workaround if upgrading to a newer Oracle Java version isn't feasible.
available
version)Java (IBM)Java 8Compatible with TLS 1.2 by default. You may need to set
com.ibm.jsse2.overrideDefaultTLS=true if your application or a library called it by ituses SSLContext.getinstance("TLS").

Java 7andhigher, Ja
va 6.0.1
servicerefresh 1
Enable TLS 1.2 using the https.protocols Java system property for(J9
HttpsURLConnection and the com.ibm.jsse2.overrideDefaultProtocol Java system
VM2.6)
property for SSLSocket and SSLEngine connections, as recommended by IBM's
anddocumentation. You may also need to set com.ibm.jsse2.overrideDefaultTLS=true.
higher,Java 6
servicerefresh10 andhigher.NET

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

9|Page.NET 4.6
andhigherCompatible with TLS 1.2 by default.

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

Option 1:.NET applications may directly enable TLS 1.2 in their software code by setting
System.Net.ServicePointManager.SecurityProtocol to enable
SecurityProtocolType.Tls12. The following C# code is an example:.NET 4.5
to 4.5.2.NET 4.0.NET 3.5
andbelow
PythonSystem.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 |SecurityProtocolType.Tls;

Option 2:
It may be possible to enable TLS 1.2 by default without modifying the source codeby 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 does not enable TLS 1.2 by default. To enable TLS 1.2 by default, it ispossible to install .NET Framework 4.5, or a newer version, and set the
SchUseStrongCrypto DWORD value in the following two registry keys to 1, creatingthem 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 alsoavailable as a registry import file.
These registry values, however, will not affect .NET applications that set the
System.Net.ServicePointManager.SecurityProtocol value.
Not compatible with TLS 1.2

Compatible with the most recent version when running on an operating system that supports
TLS 1.2.
Python2.7.9 and Compatible with TLS 1.2 by default.
higher10 | P a g e

Python
2.7.8 and Not compatible with TLS 1.2
below
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 symbols with an SSLContext's ssl_version helps ensure that TLS 1.0 or
earlier is disabled.

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

Compatible with the most recent version.

Windows
Server2012 R2
andCompatible with TLS 1.2 by default.
higherWindows
8.1 andhigherWindows
ServerCompatible by default if Internet Explorer 11 is installed. If Internet Explorer 8, 9, or2008 R2 10 is installed, then TLS 1.2 will need to get enabled by the user or an administrator
to 2012 for compatibility. Review the Enabling TLS 1.2 in Internet Explorer article to enable
Windows TLS 1.2.
7 and 8

Windows
Server2008 andbelow
Not compatible with TLS 1.2.
Windows
Vista andbelow

Microsoft Secure Channel (Schannel)
Compatible with the most recent version.

Windows
Server2012 R2 Compatible with TLS 1.2 by default.
andhigher11 | P a g e

Windows
8.1 andhigherWindows
ServerTLS 1.2 disabled by default, but is available if enabled by an application. TLS 1.2 can2012
be enabled by default within the registry. Those registry settings are also available
Windows as a registry import file.
8

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

Microsoft WinHTTP and WebioWindows
Server2012 R2
andCompatible with TLS 1.2 by default
higherWindows
8.1 andhigherWindows
Server2008 R2
SP1 and With KB3140245 applied, Webio is compatible by default, and WinHTTP can be
configured via registry settings to enable TLS 1.2.
2012
Windows
7 SP1

Windows
Server2008 andbelow
Not compatible with TLS 1.2
Windows
Vista andbelow

12 | P a g e

OpenSSL
Compatible with the most recent version, regardless of operating system.
OpenSSL
1.0.1 and Compatible with TLS 1.2
higher

OpenSSL
1.0.0 and Not compatible with TLS 1.2
below
Mozilla NSS

Compatible with the most recent version, regardless of operating system.
3.15.1andhigherCompatible with TLS 1.2

3.15 andNot compatible with TLS 1.2.
below

References
ArcGIS Platform Guidance•••

ArcGIS Server: Restrict SSL protocols and cipher suites http://enterprise.arcgis.com/en/server/latest/administer/windows/restrict-arcgis-server-ssl-protocols-and-cipher-suites.htm
Portal for ArcGIS: Restrict SSL protocols and cipher suites –http://enterprise.arcgis.com/en/portal/latest/administer/windows/restrict-portal-for-arcgis-ssl-protocols-and-cipher-suites.htm
ArcGIS Desktop System Requirements http://desktop.arcgis.com/en/system-requirements/latest/arcgis-desktopsystem-requirements.htm

Web Server TLS/Cipher Configuration Guides•••

Microsoft IIS – https://technet.microsoft.com/enus/library/security/3009008.aspx
o If you don’t want to get into IIS weeds with the above approach, checkout the free IIS Crypto tool instead https://www.nartac.com/Products/IISCrypto/
Tomcat Web Server - http://blog.facilelogin.com/2014/10/poodle-attackand-disabling-ssl-v3-in.html
Apache Web Server - https://www.digicert.com/ssl-support/apachedisabling-ssl-v3.htm

13 | P a g e

IBM WebSphere Application Server - http://www01.ibm.com/support/docview.wss?uid=swg21687173

Industry TLS Guidance••

OWASP: Transport Layer Protection Cheat Sheet https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
SSLLabs: SSL and TLS deployment best practices https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-BestPractices

Microsoft-based Solution Guidance
•

•

•
•

Customized Desktop Clients Using .NET Methods https://docs.microsoft.com/en-us/dotnet/framework/networkprogramming/tls
Windows 2012 R2 / 8 and Earlier OS TLS Guidance
https://docs.microsoft.com/en-us/previous-versions/windows/itpro/windows-server-2012-R2-and2012/dn786418(v=ws.11)#bkmk_schanneltr_tls12
Windows 8 and Windows 2008 OS TLS Guidance for .NET clients https://support.microsoft.com/en-us/help/3154518/support-for-tlssystem-default-versions-included-in-the-net-framework
Windows 2012 OS TLS Guidance for .NET clients https://support.microsoft.com/en-us/help/3154519/support-for-tlssystem-default-versions-included-in-the-net-framework

Feedback
We welcome your feedback concerning the information provided within this briefing
and any suggestions you may have. Feel free to contact the Software Security &Privacy Team @ SoftwareSecurity@Esri.com

14 | P a g e