I have .NET 2.0 Windows Forms app that makes an HttpWebRequest to download a file from a secure HTTPS server. This has run flawlessly in test on 3-4 completely separate networks.
My client needs to run this on a very restricted, secure network. Only authorized personnel are allowed to be on that network. Our liason tester who is allowed to install and test the app reports that the it is failing with this error:
The request was aborted: Could not create SSL/TLS secure channel.
Using wireshark, he is able to see that two of the three SSL handshakes occur. Any idea why the third would not occur?
He is able to successfully hit the download link from IE and download the file, which makes me believe that permissions are set up correctly.
In my app, I have set a couple of ServicePoint properties: Expect100Continue = true and require SSL3. Also I have set the validation callback to always return true (accept all certificates). Any idea why the app can't establish and SSL connection, but IE can?
Any help debugging this would be super. Thanks.
UPDATE 3/7/2012
Added System.Net tracing and here is a piece that I found interesting. Algorithm mismatch.
I had this problem too. Cost me a lot of time... In my case I found out the server wants to check the third party's certificate with the Certificate Authority (CA). Only the CA's ip-address got blocked by the firewall. This all happens during the handshake and got me the same error message.
Related
I have a c# application that generates an error "The request was aborted: Could not create SSL/TLS secure channel" when it tries to save a file to a remote SharePoint server. This happens on a Windows 2012 server, but the application runs successfully from my desktop windows machine.
Also, from the dev server, I am able to connect to the SharePoint server with IE11, with only TLS 1.1 enabled.
The application has all security protocols enabled.
I also know that the application never calls the certificatevalidationcallback function.
Given these symptoms, does anyone have any idea what could be going wrong?
After quite a bit of experimentation, I found the solution, but I'm still puzzled. The solution turned out to be the use of
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls11;
which is not surprising. What is surprising is that when I was getting the error, I was using
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls11 | System.Net.SecurityProtocolType.Tls12;
I specified both protocols because I wasn't sure which was being used by the remote server, and I thought there was no downside to allowing either protocol.
Now I'm wondering why allowing a second protocol causes the application to be unable to establish the secure channel.
I have encountered an issue with Windows.Web.Http.HttpClient when I have multiple connections using https with different client certificates, to the same server endpoint.
I have a setup a bit like:
Connection A: connect to https://www.myserver.com/path?querystring - with the HttpBaseProtocolFilter used to create the HttpClient instance configured for 'client certificate A'.
This all works fine.
Now I create another connection, using a new HttpClient instance to the same server (different query string), and this time the filter is configured for 'client certificate B'.
This connection seems to get through to the server, but it looks like the server is getting the wrong client certificate. I have no access to the server or its logs, but from the errors I do get I wonder if perhaps it is getting 'Client Certificate A' instead.
I note the problem goes away if I put a '.' character after the '.com' part of the server name in the second connection. This makes me suspicious that there is some caching somewhere based on server name.
This is failing on a Windows 8.1 Surface tablet. It seems to work ok on my development laptop. The app I'm building is a Windows Store App, so this may also be part of the problem.
Has anyone any knowledge of how client certificates are cached, or whether ssl/tls connections are 'local' to a HttpClient instance?
Can a Windows App Store app (C#) clear/disable/disconnect any existing ssl/tls session?
Any pointers welcome.
PS: The app I'm building is a 'monitoring' app that can connect to a server using different client certificates to access different 'accounts'. The app is intended to show an aggregated view of multiple accounts, thus the requirement to use a number of different client certificates against the same endpoint. This all works for the Android/iOS version of the app, but I cannot get a Windows version working.. (oh, and the server/account access mechanism is not under my control in any way )
I note the problem goes away if I put a '.' character after the '.com'
part of the server name in the second connection. This makes me
suspicious that there is some caching somewhere based on server name.
It seems that cache behavior of http client cause this issue...
You can try the following way to turn-off the cache.
HTTPClient every time returns the same string
or following SO post also helps you.
How to stop credential caching on Windows.Web.Http.HttpClient?
I'm currently working on a console app which is using some Amadeus webservices. When I'm running the application locally, everything works without any problem. However, I'm getting the following error message when I'm trying to use it on a virtual machine (Windows Server 2003) using remote desktop connection :
Could not establish trust relationship for the SSL/TLS secure channel
with authority 'noded1.test.webservices.amadeus.com'.
I don't really see any blocking issue so I can't really figure out where the problem is.
Any idea? Thanks.
A http GET to 'noded1.test.webservices.amadeus.com' returns a Http 500 Internal server error.
https://webservices.amadeus.com/ uses a VeriSign certificate. Try accessing this url from your virtual machine.
Is there any reason why your virtual machine would not trust VeriSign?
Is the time set correctly on the virtual machine?
I have a C# console app on a Windows Server 2003 machine that sends data (over SSL) to a web service hosted on a Windows Server 2003 R2 machine. I have the entire certificate chain installed on both the Current User and Local Computer certificate stores in MMC (Microsoft Management Console).
I can hit the web service (.asmx page) in IE and Firefox just fine. I'm assuming because it uses the Current User certificate store. However, my C# app returns the following error:
System.ServiceModel.Security.SecurityNegotiationException: Could not establish trust relationship for the SSL/TLS secure channel with
authority 'www.samplewebservice.com'. ---> System.Net.WebException:
The underlying connection was closed: Could not establish trust
relationship for the SSL/TLS secure channel. --->
System.Security.Authentication.AuthenticationException: The remote
certificate is invalid according to the validation procedure.
It's almost like the certificate isn't stored in the right "account" or "container" in MMC. I browsed through the various service accounts and they all seem to have the cert. I know .NET runs under the "NT AUTHORITY\Network Service" account but "Network Service" isn't listed under the Service Accounts in MMC. I checked the following service accounts and they all had the correct certificates (I never copied them so I'm assuming it's because they're in the Local Computer account):
Computer Browser
Network Connections
Network Manager
I'm completely stumped. It's like .NET doesn't have access to the certificates. I wish I could use a keystore similar to Java. Has anyone ever came across this?
I had a similar issue. I got around by deleting the certificates, reinstalling them and restarting both PC and IIS. Also make sure your certificatess haven't expired and are trusted in the machine's store.
Somewhere early in your processing pipeline:
ServicePointManager.ServerCertificateValidationCallback = (a,b,c,d) => true;
This is to ensure that all certificates are accepted.
Of course as John points out, such general callback could possibly be dangerous so please fine tune it so that on one hand it solves your issue and on the other hand it doesn't introduce any security issues.
I hope John is satisfied now. I should have been more talkative, and so should he :)
I am trying to access a WCF web service, that is using two way SSL encryption. When I try to call the service I get a
System.ServiceModel.Security.SecurityNegotiationException: Could not establish secure channel for SSL/TLS with authority 'XXX.xx'. ---> System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.
I have tried activating wire shark, to see what is sent to and from the server: I see a client hello and a server hello. But there is no client response to the server hello. I was expecting a
"Certificate. Client key exchange. Change cipher. Encrypted handshake Message"
package, but none is sent. I'm thinking it is a problem with the certificate sent by the server, that somehow my client server does not trusy it.
Here is what I have already tried:
I have created the certificate, through the proper authority, though I could have made a mistake in the certificate request without knowing it.
I have added the two root certificates to: trusted root certificates, trusted publishers and trusted people. I have also added the client certificate to trusted people. My colleague has succeded in establishing connection on a win 2008 server (i'm using a 2003, because it is necessary for some odd reason - don't ask). I can't see any differences in our approach, so i'm a bit lost.
Any help would be greatly appreciated.
I resolved this issue:
It turn out that the app-pool did not have read permission on the private key of the certificate. We changed the app-pool to local system (I believe) and it resolved the problem.