Veeva Vault disabling TLS 1.0 and 1.1

Published July 2, 2018

Beginning with the release of 18R3, Veeva Vault will disable TLS 1.0 and 1.1 and require TLS 1.2 with strong ciphers in order to align with industry best practices for security and data integrity. Once we disable TLS 1.0 and 1.1, non-TLS 1.2 HTTPS connections, web browsers, and Vault API integrations will be unable to access Veeva Vault.

Action is required prior to November 16, 2018 to prevent disruption to Vault integrations.

When is this happening?

The change happens on one of two possible dates, depending if your Vault is on Limited Release or General Release:

Disablement Plan: Important Dates

What is the impact?

Once Veeva Vault disables TLS 1.0 and 1.1, any inbound connections from HTTPS, web browsers, or Vault APIs which utilize TLS 1.0 or 1.1 will fail. In addition, TLS 1.2 connections using weak ciphers will also fail. Customers must update all inbound connections to be compatible against TLS 1.2 with strong ciphers.

Vault will no longer support the following weak ciphers:

What is TLS?

Veeva Vault uses the TLS encryption protocol for its web and API connections.

TLS stands for “Transport Layer Security.” It is a cryptographic protocol that provides privacy and data integrity between two communicating applications. It sees widespread use across network applications to ensure that data is securely transmitted between a client (e.g., web browser) and a server (e.g., Veeva Vault). At its core, TLS provides this security via encryption, identity authentication, and reliability.

TLS 1.2 is the latest standardized and most secure version of TLS as of this notice.

Why are we no longer supporting TLS 1.0 and 1.1?

TLS 1.0 was standardized nearly 20 years ago in 1999. Since its release, the protocol has been found to be vulnerable to attacks such as BEAST, CRIME, and POODLE. In response to these vulnerabilities, TLS 1.1 (2006) and then TLS 1.2 (2008) were released to fix flaws, enhance security, and offer expanded cipher suite support. TLS 1.1 saw minimal adoption as major browsers instead opted to move to TLS 1.2.

Outside of security flaws, compliance standards agencies recommend disabling TLS 1.0 and 1.1. As of June 30, 2018, the Payment Cards Industry Security Standards Council (PCI SSC) requires a minimum of TLS 1.1 while TLS 1.2 is recommended. The National Institute of Standards of Technology (NIST) requires at least TLS 1.2.

Most leading enterprise SaaS providers, such as Salesforce, Intuit, Adobe, and Zendesk, have also chosen to disable TLS 1.0 and TLS 1.1. Salesforce completed their disablement of TLS 1.0 as of March 10, 2018.

In an effort to align with the highest security standards and provide increased safety of customer data, Veeva has opted to require TLS 1.2 and above going forward.

What action is required?

The majority of Veeva Vault users and integrations are already using TLS 1.2 and will not be impacted. However, some older browsers and integrations may be using TLS 1.0 or TLS 1.1 and will require updates to use TLS 1.2.

We encourage customers to update their integrations to use TLS 1.2 as soon as possible. Veeva Vault already supports TLS 1.2.

For customers that would like to test against a Vault with TLS 1.0 and 1.1 disabled, we can provide TLS Test Vaults after August 17th, 2018 at their pre-release domain. Customers can use these Vaults to verify if browsers or integrations are compatible with TLS 1.2.

If you have questions on how to access your TLS Test Vault, please reach out to Veeva Support.

Web Browser Access

To access Veeva Vault through a web browser, customers must use a TLS 1.2 compatible browser and enable TLS 1.2 where necessary. Our supported browser list is unchanged and contains browsers compatible with TLS 1.2 by default.

To test your web browser, navigate to https://www.howsmyssl.com/ and verify the Version section is displayed as Good with your client using TLS 1.2 or above:

TLS Version 1.2

TLS Version 1.3

Vault API Integrations

We will contact user accounts used for integrations which we’ve detected as using TLS 1.0 or TLS 1.1. Please ensure that user accounts used for API integrations have updated email addresses. If you are contacted, your integration requires an update to use TLS 1.2.

We recommend testing and preparing all Vault API integrations for TLS 1.2 as soon as possible. Enabling TLS 1.2 for an integration may require an environment upgrade, such as Java 1.7 to Java 1.8+, runtime arguments, or source code changes.

Please see the platform and library compatibility tables below.

How to Test a Vault API Integration

You can test if your Vault API integration supports TLS 1.2 with a simple Authentication request.

  1. Set up the integration application in a test environment.
  2. Configure the integration’s authentication URL to point to your TLS Test Vault. For example: https://prerelease0.veevavault.com/api/v18.2/auth
  3. Start the integration and attempt to log in with any user in your domain. The user does not need to be active, it just needs to be pointed to your domain. If necessary, your Vault Administrator can configure a valid user.
  4. Based on the request response, determine if your integration supports TLS 1.2 as defined by the test cases below. However, in either test case, it is recommended that you perform additional tests to confirm that TLS 1.2 access is uniform across the integration.

Failure Test Case

The authentication request to Vault returns a failure for the initial TLS 1.2 handshake and is unable to access Vault APIs.

If you receive a TLS or HTTPS error message (e.g., in Java, a java.net.SocketException: Connection reset error), your integration is not compatible with TLS 1.2.

Your integration will require an environment upgrade, runtime arguments, or code changes to connect to Veeva Vault. For example, if you are using Java 1.7 and HttpsUrlConnections, configure the -Dhttps.protocols=TLSv1.2 JVM property and retest.

Success Test Case

The authentication request to Vault returns a success for the initial TLS 1.2 handshake and is able to access the Vault APIs.

If you receive a SUCCESS or FAILURE responseStatus, as defined by our basic Authentication request, then your integration is compatible with TLS 1.2. However, it is recommended that you perform additional tests to confirm that TLS 1.2 access is uniform across the integration.

Third-Party Compatibility

Third-party libraries or platforms used for integrations may be affected when Veeva disables TLS 1.0 and 1.1.

Java (Oracle)

Name Description
Java 8 (1.8) and higher Compatible with TLS 1.2 by default.
Java 7 (1.7) update 131 and higher Compatible with TLS 1.2 by default.
Java 7 update 131 and newer are not publicly available. They require a support contract for Java 7 from Oracle.
Java 7 (1.7) Enable TLS 1.2 for HttpsURLConnections with the the https.protocols Java system property: -Dhttps.protocols=TLSv1.2.
To enable TLS 1.2 on non-HttpsURLConnection connections, the source code must be modified to default the protocol on any created SSLSocket and SSLEngine instances.
Java 6 (1.6) update 121 and higher Enable TLS 1.2 for HttpsURLConnections with the the https.protocols Java system property: -Dhttps.protocols=TLSv1.2.
To enable TLS 1.2 on non-HttpsURLConnection connections, the source code must be modified to default the protocol on any created SSLSocket and SSLEngine instances.
Java 6 update 121 and newer are not publicly available. They require a support contract for Java 6 from Oracle.
Java 6 (1.6) and below Not compatible with TLS 1.2 encryption.

Java (IBM)

Library Description
Java 8 Compatible with TLS 1.2 by default.
The com.ibm.jsse2.overrideDefaultTLS=true Java system property may need to be set if your application 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 for HttpsURLConnections with the the https.protocols Java system property: -Dhttps.protocols=TLSv1.2.
Enable TLS 1.2 for SSLSocket and SSLEngine connections using the com.ibm.jsse2.overrideDefaultProtocol Java system property: Dcom.ibm.jsse2.overrideDefaultProtocol=TLSv12.

For more information, please see IBM’s documentation.
The com.ibm.jsse2.overrideDefaultTLS=true Java system property may need to be set if your application uses SSLContext.getinstance("TLS").

Python

Library Description
Python 2.7.9 and higher Compatible with TLS 1.2 by default.
Python 2.7.8 and below Not compatible with TLS 1.2 encryption.

.NET

Library Description
.NET 4.6 and higher Compatible with TLS 1.2 or higher by default.
.NET 4.5 to 4.5.2 TLS 1.2 is not enabled by default. There are two methods to enable TLS 1.2:
  • Enable TLS 1.2 in the integration’s code by setting System.Net.ServicePointManager.SecurityProtocol to TLS 1.2. The following C# code is an example: System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12.
  • Modify registry keys to enable TLS 1.2 by default without changing the source code. This is done by setting the SchUseStrongCrypto DWORD value to “1” (“SchUseStrongCrypto”=dword:00000001) in the following registry keys:

    32-bit system: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319

    64-bit system:
    "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319"

    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319
    These registry keys enable TLS 1.2 by default in all installed .NET 4.0 and above applications on that system.

    Note: While the version number in these registry keys is 4.0.30319, the .NET 4.5, 4.5.1, and 4.5.2 frameworks also use these values. For reference, see Microsoft’s Reference Article.
.NET 4.0 Not compatible with TLS 1.2 by default.
To enable TLS 1.2, .NET Framework 4.5, or a newer version, would need to be installed.
Then, set the SchUseStrongCrypto DWORD value to “1” (“SchUseStrongCrypto”=dword:00000001) in the following registry keys:

  • 32-bit system:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319

  • 64-bit System:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319

    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319

    These registry keys will enable TLS 1.2 by default in all installed .NET 4.0 and above applications on that system.

    Note:While the version number in these registry keys is 4.0.30319, the .NET 4.5, 4.5.1, and 4.5.2 frameworks also use these values. For reference, see Microsoft’s Reference Article.
.NET 3.5 and below Not compatible with TLS 1.2 or higher encryption.

PowerShell

Library Description
PowerShell 6.0
  • Option 1: If using the Invoke-RestMethod cmdlet, a “-SslProtocol” parameter can be added to the call to set the protocol as TLS v1.2:
    $uri = ‘https://httpbin.org/get’
    Invoke-RestMethod -Uri $Uri -SslProtocol 'Tls12’


  • Option 2: Provided .NET 4.5 or above is installed on the system, the protocol can be set to TLS 1.2 via the System.Net.ServicePointManager class:
    [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
    This line should be added to the start of your script.

    Note: This code will only apply to that individual session. If additional scripts need to run as TLS 1.2, the above code will have to be added to each script.
PowerShell 5.1 and below Provided .NET 4.5 or above is installed on the system, the protocol can be set to TLS 1.2 via the System.Net.ServicePointManager class:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Note: this code will only apply to that individual session. If additional scripts need to run as TLS 1.2, the above code will have to be added to each script.

Questions or Concerns

Please direct any questions or concerns to Veeva Support.