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.
Related
so I just got APN to work locally using the PushSharp library for C#. I can send it by clicking a button and see it on my phone.
The issue is when I deploy to the server, I get an error:
Failure: One or more errors occurred. -> {"aps":{"alert":"Test!","badge":1,"sound":"default","category":"none"}}
Apns notification error: 'ConnectionError'
There isn't a whole lot of information to go off of. So far, I have created a rule in Windows Firewall to allow outbound traffic on port 2195. I have also contacted my datacenter / provider and verified that the port is not blocked for outbound traffic.
I am having trouble finding specific information about this online, any advice / pointers would be appreciated.
I resolved this issue, which seems to be more of a bug with X509Certificate2 in .NET, but I figured I would document my fix here anyways because someone else may run into the same issue.
var cert = new X509Certificate2(#"C:\filepath.p12", "", X509KeyStorageFlags.MachineKeySet);
The third parameter is required on the server because by default, IIS is only allowed to get certificates out of the IIS user's key store. By passing the parameter X509KeyStorageFlags.MachineKeySet, it allows IIS to read and use certificates off of the filesystem.
I have spent hours trying to get the .NET FtpWebRequest library to communicate with my Ubuntu 16.04 FTP server using vsftpd over SSL.
No matter what I try, I always end up with the exception "A call to SSPI failed. The message received was unexpected or badly formatted."
I have tried generating client and server certificates, installing them in windows, loading them with the X509 class in .NET, toggling various client and server side options. No matter what I do, it's always the same error. I believe this has something to do with my certificate not being verified by an authority. Here are my basic questions:
1) Can .NET just ACCEPT a suspicious certificate?! Installing it 30 different ways seems to have no affect?
2) What does "a call to SSPI failed" really mean? I've read conflicting answers. I have no problem connecting with TLS/SSL via FileZilla, but .NET 4.5 just won't have it.
3) Can someone give the minimum amount of steps to have a Windows 7 client using the .NET framework connect to a Linux server using vsftpd over SSL? I strongly believe the problem lies in my Windows/.NET settings since FileZilla on my Windows machine has no problem connecting.
Thank you in advance.
Insert the line below in your vsftpd.conf:
ssl_ciphers=AES128-SHA
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 .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.
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 :)