To maintain the highest security standards and promote the protection of your data, Zuora will disable support for 3DES Ciphers on Zuora endpoints. Disabling weak TLS Ciphers is one of many steps towards ensuring Zuora endpoints are protected against potential high risk vulnerabilities.
When will these changes take effect?
These changes will be rolled into both Sandbox and Production environments on the following timelineAPI Sandbox on 11 July 2017 approximately 8:00AM (Pacific time)Production on 25 July 2017 approximately 8:00AM (Pacific time)
API Sandbox on 13 July 2017 approximately 8:00AM (Pacific time)Production on 27 July 2017 approximately 8:00AM (Pacific time)It may take several hours for the changes to propagate through Akamai's systems and converge, once the changes are applied.
Which Zuora URLs, environments or services does this affect?
The following domains will be changed:
On 13 July:
apisandbox.zuora.com, apisandbox-api.zuora.com, apisandboxstatic.zuora.com
pt1.zuora.compt1-api.zuora.compt1static.zuora.comblog.zuora.comde.zuora.comfr.zuora.comjp.zuora.comapisandbox.zuora.comapisandbox-api.zuora.comapisandboxstatic.zuora.comOn 27 July:api.zuora.com, blog.zuora.com, de.zuora.com, fr.zuora.com, jp.zuora.com, live-www.zuora.com, rest.zuora.com, static.zuora.com, www.zuora.com, gateway.prod.auw2.zuora.com
Do I need to take action?
No action is required on the customer side. Zuora is removing support for 3DES Ciphers from the selections within the TLS1.1 and TLS1.2 protocols. By removing a single cipher from each suite, the negotiations that occur when building a secure session has many other protocols to use. These negotiations are automatic, happen each time a new TLS session is created and invisible to the applications that are requesting the TLS session.
Schedule has been modified delayed an additional 2-days to account for some additional URLs included in the api sandbox change.
API Sandbox on 13 July 2017 approximately 8:00AM (Pacific time)Production on 27 July 2017 approximately 8:00AM (Pacific time)
We are on schedule to begin the initial phase of deployment to the above endpoints at 8am PT. It is expected to take 4-6 hours to propogate through the Akamai network and we will post again once the rollout is completed.
Deployment complete. No issues.
We will check in again in two-weeks time for the remaining endpoint changes.
Based on the 'outage' that happened for the sandbox environment, are you guys able to identify how to minimize the downtime when this rolls to production?
Hi @tatyanaI'm not aware we had any outages in our API Sandbox environments. Our trust site shows only the mainteance scheduling which did not incur downtime.
@scottb during the sandbox SSL upgrade we recieved many 401 errors especially from 15:40 MST to 17:00 MST. Please see the attached screenshot from the 13th
@brody-smith401 HTTP response is legitimate authentication issue (basically a failure in authorizing for that API user or the API token being used). The changes were deployed at our CDN removing an old cipher which is actually ahead of our domain (and prior to any authentication check). The fact that you received a HTTP 401 response tells me that our Zuora application rejected the request based on an Authentication issue, and you were already past our CDN (Akamai) where the cipher change took place.
I suspect this is unrelated, but curious in terms of coincidence.
Our sandbox tenant also saw errors on the 13th just after 4:00pm on July 13th (about 45 mins after the SSL cipher maintainence. Here is the error we got instead of a login token:
<HTML><HEAD><TITLE>Service Unavailable</TITLE></HEAD><BODY><H1>Service Unavailable - Zero size object</H1>The server is temporarily unable to service your request. Please try againlater.<P>Reference #15.a9daf180.1499983911.28f9ce9d</BODY></HTML>
So we also have the same question as Tatyana above.
Again, 4pm (assuming this is Pacific time) is well after our deployment completed so I suspect this is unrelated. Will validate with our TechOps and Security team to be sure. It's possible we had some "other" issue, however I'm not aware we had anything on the Zuora side following this deployment.
The reference ID value is something that Akamai produces and we can triage this directly with Akamai support, however this needs to be done within 48 hours of receipt due to Akamai log retention policy. In the future, I would recommend opening a ticket direclty with our support team so we can troubleshoot these issues in real time.
Our production deployment has started and will take several hours to deploy through Akamai's network. We expect no impact to existing intgegrations. Will post again once it's completed
Our deployment to production has been completed.