I tried opening a ticket with Docusign Support, but they sent me this way instead. I'm hoping someone will be able to assist with this.
Starting on Nov. 16th at about 12:30 Central, we started getting errors in our application logs in our non-production environment. Upon investigation, it appears that https://demo.docusign.net/restapi started responding to TLSv1 queries with the following:
{
"errorCode": "TLS_INVALID_VERSION",
"message": "TLS Version is invalid, please update to TLS1.2 TLSv1.2 is
required. Currently using TLSv1"
}
This came as a surprise to us considering that Docusign was supposed to disable TLSv1 in their non-production environment many months ago. Back then, we tested our application against the above URL (after the supposed switchover) and everything was working with our application, so we assumed that production would continue to work when that was supposed to switch over. And it did.
The issue is that it turns out that Docusign seems to have not disabled TLSv1 when they said they were supposed to, which invalidated any testing we did previously. And now, we're at risk of our production environment failing at some unknown point in the future.
So, does anyone know when Docusign will be switching over the production environment so that TLSv1 is disabled? We're investigating the option to update the libraries in the app so they support at least TLS 1.1, but that may take some time and this is a critical issue for us.
Hugh
p.s. On a side note, the site says that TLS v1.2 is required, but it still responds to TLS v1.1.
Note the publicly announced date for TLS 1.0 deprecation is 6/25/2018. However we had a grace period. Now the hard block dates are coming up. The hard block date in PROD is set at 1/31/2019. In Demo its 11/16, as you noticed.
Add this line before calling REST API
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
It will works fine.
I work for DocuSign.
As of this writing, DocuSign has no current plans to stop supporting TLS 1.1. We already support TLS 1.2 and encourage you to upgrade to it rather than TLS 1.1. But TLS 1.1 is fine if that is all your stack currently supports.
Related
With KB5018410 Windows update installed in Windows 10 recently, my Delphi REST applications have stopped working. It seems that TLS 1.2 is turned off. Insomnia, Firefox etc can access the URL below, but not a "default" set of TRESTClint/TRESTRequest/TRESTResponse components dropped on a form with the minimal required Properties modifications.
https://yams.ked.co.za/version
Checking boxes under TRESTClient.SecureProtocols also does not seem to make any difference.
How can I get my (very large) REST application going again!?
Check this conversation out on Reddit - Global Protect TLS issue after install of KB5018410
https://www.reddit.com/r/paloaltonetworks/comments/y21chi/some_of_our_users_are_having_issues_connecting_to/
Check your ssl cert and make sure your cert is not valid for more than 1 year 365 days. If it is issued to be longer than a year try switching your cert to one that is only good for 1 year and see if it solves it. That fixed my Palo Alto global protect vpn issue.
My final solution was to use another, 3rd party component (Chilkat) to carry out the REST functionality.
There is also the option of rolling back (and then blocking repeat upgrading) the Windows 10 KB5018410 upgrade.
The problem with the Embarcadero REST components was reported on the Issues site, and has now been elevated from "Reported" to "Open" status.
We're using a VB6 application on Windows 7+ machines (we can't upgrade it just yet). We call several web services in the application like so:
Set objClient = CreateObject("MSSOAP.SoapClient30")
objClient.MSSoapInit gszEmailWebServiceURL
objClient.ConnectorProperty("Timeout") = 30000
strXMLResponse = objClient.GetEmails()
Soon, all of the web services we call are changing to only allow TLS 1.2 connections.
Is there any way to set the object to use TLS 1.2?
I know that in .NET, you can do this:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12
Is there something similar for VB6?
Also, I know that you can force the entire system to use TLS 1.2 by default, as specified here: https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in. I tested this on one of our VMs and it indeed works, but we'd have to do this on every one of our client workstations (100+) that use this application, and so I'm hoping there is a way to do it from within the app itself, as we already have auto-update functionality for the app.
Thanks in advance.
we use bluemix-letsencrypt for generating SSL certificates (as mentioned for example here).
When you run the script, at the end of the process, there is mentioned a limitation - you're not able to update existing certificate without downtime. You need to delete the old certificate first and then upload a new one. But this procedure means unacceptable downtime.
The mentioned solution is that we should use IBM Cloud console where should be possible to upload new SSL certs over the old ones, it means without downtime. This solution worked recently (2-3 months ago), but not anymore.
A few days ago I wanted to do the same as I did four times over the last 12 months (every 3 months), but the design of the console has been changed and now it's impossible to do that.
This is really bad. While we use HTTPS Strict Transport Security, any downtime of SSL certificate is critical for us.
Anyone who knows how we could solve this issue?
Thank you.
I am using Web IDE and want to see the log by clicking on the arrow.I can only see an empty "Untitled" page. The Node.js app is running normally. Live edit is switch off.
After some minutes:
Gateway Timeout
The proxy server did not receive a timely response from the upstream server.
Reference #1.45bf1402.1511018717.3dddb8b
I'm not for sure what Web IDE you are referring to. The only one I'm aware of is the DevOps (which works for me below):
It seems to me like this error that you posted would indicate a temporary outage. Is it still an issue?
In any case, I would advise opening a support ticket if you encounter this issue again (more details about your account would help). I think the Bluemix proxy will time out requests if they take too long.
I posted on friday regarding this issue and received no response, however since then some updates have occurred which might affect whether people have an answer to my question or not.
I'm trying to deploy an MVC website to Azure, and in this particular project the web deploy receives a Socket Error 10054 and gives up after 10 attempts saying it was Unable to write data to the transport connection. It makes varying progress in between the socket failures but never completes within the 10 attempts.
I have since had a play around with other projects which are deployed to different url locations within this same Azure Account and they deploy fine! I think this means the problem is not on my end, i.e. port 8172 is open and deployment can be achieved with my current local settings.
What are the problems that can cause this socket error 10054? I saw somewhere that I should enable the "Allow untrusted certificate" option when deploying but I can't find that option within VS 2013.
Any ideas are welcome please,
This issue is driving me mad, it seems there's a real mixed bag of solution ideas which have worked for others but not me.
JK