1
votes

I've come across some strange behaviour of dotnet SslStream, when running my dotnet-core app on linux environment.

here is the code:

TcpClient cl = new TcpClient();
cl.Connect("52.209.63.190", 443);
var ssl = new SslStream(cl.GetStream());
ssl.AuthenticateAsClient("api.bitfinex.com");

Auth result is success, when running on windows. But same code ends with auth error (RemoteCertificateNameMismatch), when linux.

dotnet --info:

.NET Command Line Tools (2.1.4)

Product Information: Version: 2.1.4 Commit SHA-1 hash: 5e8add2190

Runtime Environment: OS Name: fedora OS Version: 27 OS Platform: Linux RID: linux-x64 Base Path: /usr/share/dotnet/sdk/2.1.4/

Microsoft .NET Core Shared Framework Host

Version : 2.0.5 Build : 17373eb129b3b05aa18ece963f8795d65ef8ea54

Why code behaviour is so different on linux? How can I handle it and pass ssl auth?

Thank you in advance

2
Can you please test it by this way cl.Connect("api.bitfinex.com", 443); - Meruzhan Hovhannisyan
it works, but dns is resolved with different ip which I don't want to connect to. - Bambaleo
I don't know how you get the IP address of api.bitfinex.com, but api.bitfinex.com is under cloudflare, and that domain resolves with cloudflare. - Meruzhan Hovhannisyan
it is not about cloudflare or specific host and ip, it is about app behaviour on different platforms - Bambaleo
.NET Core uses Win32 API on Windows to implement SSL, while on Linux it currently uses openssl. Thus, the behavior can slightly differ. There is nothing to be surprised. - Lex Li

2 Answers

0
votes

So, you can connect to that host with

TcpClient cl = new TcpClient();
cl.Connect("api.bitfinex.com", 443);
var ssl = new SslStream(cl.GetStream());
ssl.AuthenticateAsClient("api.bitfinex.com");

I don't know how you got the IP address of api.bitfinex.com, but it's under cloudflare, and may be you don't need to connect bitfinex with his real IP address.

But if it is required to connect that special IP address, you can override verification callback before you do any connection

System.Net.ServicePointManager.ServerCertificateValidationCallback =
    (sender, certificate, chain, errors) => true;
0
votes

Looks like the answer is simple: too old dotnet version.

2.0 seems to have some ssl issues, which were fixed since 2.1

When I installed the newest one (2.1.3), my app still didn't work, decause I had to uninstall prev version (2.0.5) manually to be able to use 2.1.3

Now the app ends with the same result on both windows and linux environments.

Many thanks to M. Hovhannisyan. I've started trying different linux versions, and figured out what I did wrong