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.
The change happens on one of two possible dates, depending if your Vault is on Limited Release or General Release:
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:
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.
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.
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.
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:
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.
You can test if your Vault API integration supports TLS 1.2 with a simple Authentication request.
https://prerelease0.veevavault.com/api/v18.2/auth
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.
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 libraries or platforms used for integrations may be affected when Veeva disables TLS 1.0 and 1.1.
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. |
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") . |
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. |
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:
|
.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:
|
.NET 3.5 and below | Not compatible with TLS 1.2 or higher encryption. |
Library | Description |
---|---|
PowerShell 6.0 |
|
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. |
Please direct any questions or concerns to Veeva Support.