Retiring TLS 1.0 and 1.1

Serviceaide is retiring Transport Layer Security (TLS) 1.0 and TLS 1.1 and continuing support TLS 1.2 for Intelligent Service Management (ISM) and Luma.

Why this change?

TLS 1.0 and TLS 1.1 are out-of-date protocols that do not support modern cryptographic algorithms, and they contain security vulnerabilities that may be exploited by attackers

What does this Mean?

Serviceaide has announced that TLS 1.0 and TLS 1.1 are out-of-date protocols that do not support modern cryptographic algorithms, and they contain security vulnerabilities that may be exploited by attackers. Support for TLS 1.0 and 1.1 will be deprecated soon will continue to support TLS 1.2 protocols.

When and on which environments this change will occur?

This change will happen along with ISM August Maintenance release i.e on 22-Aug-2020. TLS protocols TLS 1.0 & 1.1 versions will be disabled from all our customer-facing environments viz. CSM3, CSM2 production, staging, and trial environments.

What is the impact on customers?

This impacts our customers who have integrated 3rd party applications to ISM/Luma using TLS 1.0 or TLS 1.1 protocols using SOAP Webservices. They will have to upgrade their clients via which they are connecting to ISM/Luma. They need to ensure they do their testing in the staging environment.

Accessing ISM/Luma application using Browser
API Integration Outbound and Inbound
ADSync Utility
Asset Discovery Configuration

Accessing ISM/Luma application using Browser

Google, Microsoft, Apple, and Mozilla have also announced that their browsers will no longer support TLS 1.0 and TLS 1.1 as of March 2020. So, below browsers will not work with ISM application after the deprecation:

Firefox 27
Chrome 30
IE 11 on Windows 7
Edge
Opera 17
Safari 9

Action Required

Upgrade your browser to the latest versions to continue using ISM/Luma application. Below is the information on compatible browsers with the application:

ISM: https://serviceaide.atlassian.net/wiki/spaces/CloudSMGoldfish/pages/2965397/Compatibility+Matrix

Luma: https://serviceaide.atlassian.net/wiki/spaces/LUMA/pages/756646032/Compatibility+Matrix

API Integration Outbound and Inbound

API (inbound) Integrations

If you have any API Integrations, connecting from third party systems to ISM/Luma which will be supporting only TLS v1.2 protocol, please ensure the appropriate Java versions are used in those integrations.

Action Required for API (Inbound) Integrations

Your integrations that use inbound connections to Serviceaide ISM / Luma, ensure that TLS 1.2 encryption protocols are enabled in those integrations. Otherwise, the integrations may experience disruption after the upgrade is done at ISM/Luma. We recommend that you begin planning to upgrade to supported Java version which supports TLSv1.2 as soon as possible.

If you have any API Integrations, 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.2 by default.
Java 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) and below	Not compatible with TLS 1.2. 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.2 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.2.
.NET 4.6 and higher	Compatible with TLS 1.2 by default.
.NET 4.5 to 4.5.2	.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 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	Option 1: .NET 4.0 doesn’t have an entry for TLS1.2, so we’d have to use a numerical representation of this enum value: `ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;` Option 2: .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.2

How do I change the default SSL protocol my Java Client Application will use?

There are two properties that a java application can use to specify the TLS version of the SSL handshake.

jdk.tls.client.protocols="TLSv1.2"
and
https.protocols="TLSv1.2"

Specifying simply jdk.tls.client.protocols="TLSv1.2" will cause any type of ClientHello to use TLSv1.2 (https included). The https.protocols is only valid if the Client Application us using HttpsURLConnection class or URL.openStream() operations.

The value "TLSv1.2" is case sensitive. It is very important the 'v' is lowercase.

Property

Description

jdk.tls.client.protocols

Controls the underlying platform TLS implementation. Additional information is available in the JSSE Reference Guide.

Example: -Djdk.tls.client.protocols=TLSv1.1,TLSv1.2

Available in all JDK 8 releases, or after Java 7 update 95 (January 2016) and Java 6 update 121 (July 2016).

https.protocols

Controls the protocol version used by Java clients which obtain https connections through use of the HttpsURLConnection class or via URL.openStream() operations. For older versions, this can update the default in case your Java 7 client wants to use TLS 1.2 as its default.

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

API (Outbound) Integrations

If you have any Outbound Integration configured in ISM/Luma, which means connecting from ISM/Luma to any third-party system using Web services, validate if the endpoint web service only supports TLS v1.2 protocol. We have made support for outgoing web services to call all TLS protocols (TLSv1.0, TLSv1.1, and TLSv1.2).

Action Required for API (outbound) Integrations

Your integrations that use outbound connections should be validated.

AD Sync Utility

If you have configured AD Sync to sync the contacts from AD/LDAP Systems to ISM/Luma, ensure that the java JRE used is Java 1.8 and above. Otherwise, JRE 1.7 requires Java 7 update 95 (January 2016) or Java 6 update 121 (July 2016).

Action Required for ADSync Utility

For integrations that use ADSync utility validate and verify in Staging that the functionality works.

Asset Discovery Integration

If you have Asset Integration, download the new package that supports TLSv1.2 and update all the Asset connector environments before the production rollout to ensure the connectivity.

Action Required for Asset Integration

For integrations that use Asset Discovery, download the latest package, upgrade the Asset Discovery Manager, and test the functionality in staging.

Note: In some environments, if the old asset connector is not uninstalled properly then it doesn't allow to install a new asset connector again. In such cases need to clean up the Registry by running regedt32.exe and look for Asset Connector reference and by deleting all the reference will clean the environment for the fresh install.