See updates in Red [06/03/16]
What is this change?
At Zuora, our customers trust is our #1 value, and we take the protection of our customers' data very seriously. To maintain the highest security standards and promote the protection of your data, we occasionally need to make security improvements and deprecate older encryption protocols. To maintain alignment with industry standard best practices and comply with PCI DSS requirements, Zuora will disable the use of TLS 1.0 for inbound connections to Zuora as well outbound callouts from Zuora.
What will this change affect?
This change will affect all incoming web browser based traffic as well as API traffic to both API Sandbox and Production.
When will this change take place?
We will take a phased approached to disabling TLS 1.0 for both inbound and outbound API calls to allow customers ample time to test and ensure your preparation.
Phase 1 - APISandbox and Services Environment
On February 4th 2016 from 7 AM PST - 11 AM PST, we will enforce TLS 1.1 or higher protocols only and disable TLS 1.0 connections for API Sandbox.
From March 17th-31st 2016 7AM PST - 11AM PST, we will enforce TLS 1.1 or higher protocols only and disable TLS 1.0 connections for Services. For the specific implementation date for your service tenant, please submit a ticket through our Support Center.
Services Deployment Schedule
3/17/2016 Services environments with suffix ranging from 101-266
3/24/2016 Services environments with suffix ranging from 276-385
3/31/2016 All other Services environments
Phase 2 - Production [UPDATED 06/03/16]
Zuora will disable TLS 1.0 for all inbound calls to production on October 13th, 2016. This change will impact all channels including SOAP APIs, REST APIs and browser based traffic (UI).
How do I prepare for this change?
We have split up the preparation section to cover inbound calls to Zuora for browser based traffic as well as API based traffic.
Testing should be done prior to Feb 4th 2016 when we make the change in API Sandbox.
Inbound Preparation (API and Web Browsing)
For Inbound API testing, using the following endpoints listed below based on your need to test SOAP or REST APIs.
TLS1 endpoints below have been decomissioned as of 2/4/16
See the table below for common libraries and their compatibility with TLS 1.1 or higher. If the library you use is not listed here, please reach out to your software vendor for more information regarding support for TLS 1.1 or higher.
TLS 1.1/1.2 Compatibility Notes
Java 8 (1.8) and higher
Compatible by default
Java 7 (1.7)
See Java documentation to enable TLS 1.1 and TLS 1.2
Java 6 (1.6) and below
Not compatible with TLS 1.1 or higher encryption
.NET 4.5 and higher
TLS 1.2 not enabled by default. To enable TLS 1.2, it is possible to 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".
.NET 3.5 and below
Python 2.7.9 and higher
Python 2.7.8 and below
TLS 1.2 is enabled by default when used with OpenSSL 1.0.1 or higher. Using the :TLSv1_2 (preferred) or :TLSv1_1 symbols with an SSLContext's ssl_version ensures TLS 1.0 or earlier is disabled
Ruby 1.9.3 and below
The :TLSv1_2 symbol does not exist in 1.9.3 and below. It can be patch to add that symbol and compile Ruby with OpenSSL 1.0.1 or higher
Windows Server 2008 R2 and higher
Windows Server 2008 and below
OpenSSL 1.0.1 and higher
OpenSSL 1.0.0 and below
Mozilla NSS 3.15.1 and higher
Mozilla NSS 3.14 to 3.15
Compatible with TLS 1.1, but not with TLS 1.2
Mozilla NS 3.13.6 and below
Inbound Browser Preparation
To test web browsing, first ensure your browser meets Zuoras Browser Support Policy found here
Once you have confirmed you are using a supported browser and version, surf to https://tls1.apisandbox.zuora.com/apps/newlogin.do and login to confirm you can access the environment. Below is table listing the version of supported browsers and their support for TLS 1.1 or higher.
Desktop and mobile IE version 11
Desktop IE versions 9 and 10
Capable when run in Windows 7 or newer, but not by default
Firefox 27 and higher
Google Chrome 38 and higher
Mobile Safari versions 5 and higher
Outbound Preparation (API)
Integrations using Java will need to use Java 8 which supports TLS 1.1/1.2 by default. See here for more details.
Integrations that run on Windows will need to run on Windows Server 2008 R2 or higher. This generally includes most .NET applications and Microsoft Internet Information Server (IIS). Earlier versions of Windows Server do not support TLS 1.1 or TLS 1.2. See here for details.
Integrations which rely on OpenSSL should ensure they are using OpenSSL version 1.01 or newer. See here for changelogs.
What happens if I take no action?
Customers are advised to immediately perform the necessary changes to ensure support for protocol versions TLS 1.1 or higher.. If you have made the necessary changes, no further action is required on your part.
Failure to make the necessary changes before October, 13th, 2016 to support TLS 1.1 or higher will result in a disruption of Zuora services for your integration.
Zuora Global Support is readily available to answer any additional questions you may have.
Please contact us at +1-650-779-4993 or at email@example.com.
Frequently Asked Questions:
Q. Do we have a Test Endpoint like Salesforce has https://tls1test.salesforce.com to validate TSLv1.1 and above compatibility before even switching Sandboxes?
A. For Inbound API testing of TLS 1.1 or higher use the following endpoints listed below based on your need to test SOAP or REST APIs.SOAP API Interface: https://tls1.apisandbox.zuora.com/apps/services/a/68.0REST API Interface: https://tls1.apisandbox.zuora.com/rest/v1/
Q: How do I verify if my browser support TLS 1.1 and above
A: User could always verify SSL/TLS protocol versions you browser supports by accessing the site https://www.ssllabs.com/ssltest/viewMyClient.html using browser you intend to confirm. Look for Your user agent has good protocol support or specific version support under Protocol Features section.
Q: How does this affect Salesforce (or other integrations - Avalara, Netsuite, Payment gateways, etc) - do we need to contact anyone or take action elsewhere?
A: Tenants do not need to contact any third parties who are integrated with Zuora. We are in contact with all third parties to ensure coordination for this change to avoid any disruptions to service.
Q: Do we need to restart our application after this change?
A: The change itself on Zuora's end is an online, non-disruptive change. However some applications and SSL implementation are known to cache SSL attributes for longer duration. Thus in case any prior connection established using TLS 1.0 before this version is disabled, might require an application restart to initiate new connections on TLS 1.1 or above. Again, this is not typical or usual behaviour and depends upon SSL Client implementation.
We plan to continue disabling TLS 1.0 as per plan. Since Salesforce do support TLS 1.1 and higher for all callouts of Salesforce we should be OK with any such dependent integration. We will keep you posted in case any change in execution plan.
We are using Oracle SOA suite 11g for Zuora Integeration. Currently oracle is facing major bug which is casuing hand shake failure for TLS1.1 and Above. They are looking into this with High priority but not any timeline has specified. I assume, this would affect most of your customer base as well. We would appreciate if zuora team decide to defer execution plan same like Salesforce.
Thank you for bringing this to our attention. Our Security Team will definitely look into the details of this Oracle bug you've mentioned and will let you know their thoughts.
Thank you for bringing this to our attention. It would be great if you could provide Oracle bug# for us to track and get more details. Also, does this bug currently impact your integration with Sandbox or Production or both ? Also, we reccomend checking with Oracle if there is a workaround to support TLS 1.1 and above while permanent bugfix is released.
Here is Oracel Bug # 22606743. We have found that and raised to Oracle. Oracle has accepted that and their Development currently working on it.
This bug will impact both Sandbox & Production instance as Zuora move forward with disabling TLS1.0.
No Workaround in place at the moment.
One more Sales Force related bug for your referece.. Oracle Bug # 22575721.
Just a general reminder - The API Sandbox Test endpoint (tls1.apisandbox.zuora.com) will not be available after 2/4 change. Thanks
I am using the AQuA API to get data. Are these endpoints affected by TLS 1.1?
Thank you for bringing this up. Yes, to conform the changes described above also apply to the AQuA API
Due to security incompatibility on the side of the Apigee Dev Console tool when we disable TLS 1.0 for API Sandbox on February 4, 2016, please cease the use of the Apigee Developer Console tool. We are also working to update the Knowledge Center article to remove links to the tool. There are many alternatives that work well and do not have security issues. Two alternatives are the Chrome plugins linked below:
The phase 1 deployment has begun
Phase 1 - APISandbox
On February 4th 2016 from 7 AM PST - 11 AM PST, we will enforce TLS 1.1 or higher protocols only and disable TLS 1.0 connections for API Sandbox.
As outlined above, this deployment will take approximately 2 hours to propogate through the Akamai network
Can you please advise of the schedule for disabling TLS 1.0 in Services Sandboxes?
This change will also impact Performance Test environment (Endpoint: pt1.zuora.com). TLS 1.0 will not be supported in PT1 environment as of today once the change takes effect.
Please feel free to reach out to us in case you have any question.
We can confirm the API Sandbox TLS 1.0 disablement has been completed.
is not found when trying to hit the url. A server not found message appears. Is the server available?
nevermind - I see the URL has changed, and now doesn't resolve...
@kgarosshen - tls1.apisandbox.zuora.com endpoint was removed as outlined above posts
Not enough context to respond to this or tell what the issue is.
What version of curl are you using as some earlier versions require an update to support TLS 1.1+
Thanks, we believe we've gotten to the bottom of this.
We've heard from a few customers implementing *.NET 4.5 code that noted they had to force *.Net to use TLS 1.2 which worked to resolve the issue. Please refer to your *.NET documention for the changes necessary. We would welcome any comments from other *.NET administrators on their experience with this change.
Sr. Application Support Engineer
In .net client to enable TLS1.x programatically:
// Default Protocols are Ssl3 | Tls. This is changed to support Zuora's TLS 1.1 rollout
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
OR with a registry hack (source http://stackoverflow.com/questions/28286086/default-securityprotocol-in-net-4-5/28502562#28502562
Windows Registry Editor Version 5.00
I tried the programmatic solution posted by @zoltanmike in my code. It's working in my dev API, which I have pointing at the sandbox.
Hi , We are using AQuA API to connect to Zuora end points below.
We missed to test this change before it went live in the API Sandbox.
Now, when we try to connect to https://apisandbox.zuora.com/apps/api/batch-query/ we are getting the following error.
"Error in zuora data extraction process : EOF occurred in violation of protocol (_ssl.c:581)"
We are not sure if this error is caused due to the change in TLS version and this is the first time we are trying to access API sandbox environment.
Any help in resolving this error would be much appreciated. Thanks!
Looking at the error it looks like you are using Python library to connect Zuora. It is difficult to say, but looking at the error, it does look like error is caused due to protocol version support. Please note that you would need Python 2.7.9 in order to support TLS 1.1 & above. Please upgrade Python version and see if that helps.
Thanks for the response PERMALINK.
We are indeed using python library to connect to Zuora. We are currently using python version 2.7.9 already. Do we need to upgrade to a higher version?
Are there any configuration changes required while connecting to https://apisandbox.zuora.com/apps/api/batch-query/ which is different from the connection to https://www.zuora.com/apps/api/batch-query/?
Python 2.7.9 should support TLS 1.1 & above. However you need to ensure OpenSSL library also has supported compatible version - 1.0.1 I belive.
In our environment we created below two registry entry's successfully and i can see them in registry. But it is still taking SSLv3/TLS 1.0.
Could you please help? Please find the environment details below.
Windows Server 2008 R2 Standard,Service pack 1
.Net framework 4.0
According to this article, NET 4.0 may also requires a change to ServicePointManager.SecurityProtocol in addition to the registry change
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;//SecurityProtocolType.Tls1.2;
I have gone through that blog .. Since it requires system.dll replace and code change we decided to upgrade our .net framework to 4.5 .
If you're using the SoapUI client, here's how you can enable TLS1.1 (or 1.2 for that matter):
- navigate to your SOAP install directory, and open the bin directory
- locate your soapui.bat file (or soapui.sh, depending on your platform)
- locate JAVA_OPTS
- add the following line:
set JAVA_OPTS=%JAVA_OPTS% -Dsoapui.https.protocols="TLSv1.1,TLSv1.2"
- Example, my bat file looks like this:
SSLv3 was just an example for syntax. Please do NOT add SSLv3. This is a legacy, unsecure protocol and Zuora does not support any version of SSL protocol any longer. You can add TLS 1.1 if you prefer to keep both though.
To add both TLS 1.1 and TLS 1.2 support you could use below Java prams.
Phase 2 - Production
We are re-scheduling deprecation of TLS 1.0 for production environments, the new date will be updated here shortly.
I assume you don't have a new date but i just want to confirm that it will not be on April 7th that was planned.
@cmcbrayer Yes, that's correct that we don't have a new date. We will announce the new date as soon as it's available.
Thanks for your patience!
Just expanding on the Python requirements somewhat based on some additional feedback internally, here's what we understand to this point.
Python 2.7.8 and before is not compatable with TLS 1.1+Python 2.7.9 is compatable (but requires patching and dependancy on OpenSSL version supporting appropriate TLS version)Python 3.2.4 is compatable by default
I would encourage other Python users to share their experience with the recent TLS changes and what they had to do in support of TLS 1.1+
Excuse me , I have a question, please give me some advice. Thank you!
I used soap UI to test soap API login() method , but it was failed.
I got some error like this,
I filled <api:username> and <api:password> tags with my username and password,
I tried some methods, but it not worked at all.
please give me some advice .Thank you very much!
Hi @ryurin , the handshake error is the result of the wrong protocol being used.
Please see my previous comment on how to configure SoapUI for TLS1.1+ and how to start it using the new configuration - this is the very method I am using since we have deprecated the old TLS protocol on Sandbox:
Thank you for your reply.
I made the following changes
add this line
then it works very well, this problem has solved!
Thank you very much!
I just wanted to share that I tried pything 2.7.10 as well as 2.7.11 and neither uses TLS 1.1 by default. I build 2.7.11 with OpenSSL 1.0.1 and that allowed me to connect but this won't work for me in my produciton environment.
I've updated the post with new information, please check the original post above.
Phase 2 - Production [UPDATED 4/27/16]
We expect to have an update to the timeline for deprecation in the next few weeks. We will provide at least 90 days notice prior to ending support for TLS 1.0 in production to ensure customers have sufficient time to update mission critical applications.
Has a new date been decided? @monique
We will have a new date next week. Once we have the new date, we will post this on the community. Thank you for your patience.