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.
Related
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.
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've been chasing this problem around for a while now and I can't get to the bottom of it. I've read the other solutions on here (https://identityserver4.readthedocs.io and https://github.com/IdentityServer/IdentityServer4.Quickstart.UI) and it's still not working, so I've tried to reduce this down to the absolute basics. This is not the actual problem I am facing, but produces the very same outcome. i.e. I can't get Windows Authentication to work.
I clone https://github.com/IdentityServer/IdentityServer4.Samples
I amend Quickstarts/7_JavaScriptClient/src/QuickstartIdentityServer/Quickstart/Account/AccountController.cs so that WindowsAuthenticationEnabled is true
I then goto http://localhost:5000/account/login and attempt to use the Windows external provider and I get 401.
The only difference with this simple sample here, and what I see on my actual system is that I'm getting challenged for credentials on my real site.
Debugging the code I never see if(HttpContext.User is WindowsPrincipal) succeeding, because it's always a ClaimsPrincipal.
Can someone explain to me what I'm doing wrong?
Do you have windows authentication enabled on your IIS site? This needs to be enabled for your WindowsPrincipal to be assigned. Note that windows authentication only works when running behind IIS or IIS Express.
I am using a certificate authority from windows 2003 machine and it issues certificates with SHA1 algorithm and these certificates are used in URLs. I came to know what all the browsers IE , Chrome , Mozilla , etc are going to stop supporting SHA1. Can you advise me what is the impact i am going to have in my URLs ??
Does these URLs will display only the security error message like "The URL which you are trying to access is not from trusted source" and if i add an exception i will still be able to view the web page or i will not be able to view the webpage completely even after adding the exception to the browser ?? Thanks
Google Statement
Step 2: Blocking all SHA-1 certificates Starting January 1, 2017 at
the latest, Chrome will completely stop supporting SHA-1 certificates.
At this point, sites that have a SHA-1-based signature as part of the
certificate chain (not including the self-signature on the root
certificate) will trigger a fatal network error. This includes
certificate chains that end in a local trust anchor as well as those
that end at a public CA. In line with Microsoft Edge and Mozilla
Firefox, the target date for this step is January 1, 2017, but we are
considering moving it earlier to July 1, 2016 in light of ongoing
research. We therefore urge sites to replace any remaining SHA-1
certificates as soon as possible. Note that Chrome uses the
certificate trust settings of the host OS where possible, and that an
update such as Microsoft’s planned change will cause a fatal network
error in Chrome, regardless of Chrome’s intended target date.
According to Google's statement Chome will block alle network traffic to your site.
I am doing an automatic upgrade through Azure portal. While it is upgrading 1st instance, if I try to access my site through http://xyz.cloudapp.net it doesn't open.
IMO when 1st instance is upgrading, the request should be served from the 2nd instance, but I think this is not happening, that's why I see site unavailable message on my browser.
Is it something which I need to do/configure before I do an upgrade?
Your understanding matches mine. I would open a support ticket (http://windowsazure.com/support) to get to the bottom of it.
You want to handle the RoleEnvironmentChanging event properly (i.e. don't set the e.Cancel to true if you don't need to reboot)
http://msdn.microsoft.com/en-us/library/gg432963.aspx