Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HttpClientHandler.ServerCertificateCustomValidationCallback blows up on OSX #17723

Closed
niemyjski opened this issue Jun 28, 2016 · 80 comments
Closed
Labels
area-System.Net documentation Documentation bug or enhancement, does not impact product or test code os-linux Linux OS (any supported distro)
Milestone

Comments

@niemyjski
Copy link

I just updated my Project to RTM and did testing on Windows and everything worked. I then went to test on OSX 10.11.5 (latest stable everything, dotnet, openssl) and ran into issues very quickly..

I'm getting The libcurl library in use (7.43.0) and its SSL backend (\"SecureTransport\") do not support custom handling of certificates. A libcurl built with OpenSSL is required. in stable latest everything on macOS...

"   at System.Net.Http.CurlHandler.SslProvider.SetSslOptions(EasyRequest easy, ClientCertificateOption clientCertOption)\n   at System.Net.Http.CurlHandler.EasyRequest.InitializeCurl()\n   at System.Net.Http.CurlHandler.MultiAgent.ActivateNewRequest(EasyRequest easy)\n--- End of stack trace from previous location where exception was thrown ---\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\n   at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()\n   at System.Net.Http.HttpClient.<FinishSendAsync>d__58.MoveNext()\n--- End of stack trace from previous location where exception was thrown ---\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\n   at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()\n   at Exceptionless.Submission.DefaultSubmissionClient.GetSettings(ExceptionlessConfiguration config, Int32 version, IJsonSerializer serializer) in /Users/blake/Code/Exceptionless.Net/src/Exceptionless/Submission/DefaultSubmissionClient.cs:line 89" [string]
5]  
blake@:~/Code/Exceptionless.Net$ brew info openssl
openssl: stable 1.0.2h (bottled) [keg-only]
SSL/TLS cryptography library

[2:16]  
lake@:~/Code/Exceptionless.Net$ brew install openssl
Warning: openssl-1.0.2h_1 already installed
blake@:~/Code/Exceptionless.Net$ brew link --force openssl
Warning: Already linked: /usr/local/Cellar/openssl/1.0.2h_1
To relink: brew unlink openssl && brew link openssl
blake@:~/Code/Exceptionless.Net$

I narrowed it down to defining a custom validation callback breaks the http client.. I can't even do a GET.

var handler = new HttpClientHandler { UseDefaultCredentials = true };
handler.ServerCertificateCustomValidationCallback = delegate { return true; };
var client = new HttpClient(handler, true);
client.GetAsync(url).GetAwaiter().GetResult();

All the code can be found here: http://github.com/exceptionless/Exceptionless.Net

@niemyjski
Copy link
Author

@davidsh
Copy link
Contributor

davidsh commented Jun 28, 2016

cc: @stephentoub

@stephentoub
Copy link
Member

stephentoub commented Jun 28, 2016

Yes, to use several of the HttpClient features related to certificates, like ServerCertificateCustomValidationCallback, you need to be using a version of libcurl built against OpenSSL; the version you're using is the one that comes with macOS, built against the SecureTransport backend. We do not have the ability to plug in to that backend, hence we throw an exception to indicate that the callback won't be used.

@niemyjski
Copy link
Author

niemyjski commented Jun 28, 2016

@stephentoub I don't think this acceptable. I couldn't make any http request because of it and I'm using the install instructions on the main website which many many others are going to use (that are on osx). Could we get a check to see if it's supported like other handler features? Any request without validation callback is better than nothing.. I get why you are throwing it.. but most peoples http client code is going to be try catched and they are not going to see this...

@stephentoub
Copy link
Member

I'm using the install instructions on the main website

We can look to augment the instructions / release notes with related details.
cc: @leecow

Any request without validation callback is better than nothing

I'm not understanding this part. If you want to avoid the error, you can avoid hooking up the callback. And if you've specified a callback, not invoking it could be a significant security hole, as we'd end up using the default validation of a security certificate rather than the validation the developer has explicitly requested via the callback.

but most peoples http client code is going to be try catched and they are not going to see this

I don't understand this part either. Can you elaborate?

Could we get a check to see if it's supported like other handler features?

You mean a capability property, like IsCustomServerCertificateValidationSupported? That's a reasonable request for the future. Thanks.

cc: @ericeil, @bartonjs

@niemyjski
Copy link
Author

Yeah, I get all of your points and agree when it comes to security.

if (handler.SupportsServerCertificateValidationCallback) {}

@joshfree
Copy link
Member

@stephentoub @bartonjs feel free to submit a PR to update the release notes / docs to make this more clear.

@atanasa
Copy link

atanasa commented Jul 21, 2016

How is this supposed to work on OSX? Install some package on OSX? Or there is no way to make it work on OSX?

@niemyjski
Copy link
Author

I don't think there is any way for this to work on OSX currently (at least I haven't found a way)

@stephentoub
Copy link
Member

I don't think there is any way for this to work on OSX currently (at least I haven't found a way)

I'm sure there are other ways, but I did:

brew install curl --with-openssl
brew link --force curl

and then with that library being used:

export DYLD_LIBRARY_PATH=/usr/local/lib/

I can successfully use these features...

stoubmac:~ stoub$ cd testapp
stoubmac:testapp stoub$ cat Program.cs 
using System;
using System.Net.Http;

namespace ConsoleApplication
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var handler = new HttpClientHandler { CheckCertificateRevocationList = true };
            var http = new HttpClient(handler);
            Console.WriteLine(http.GetAsync("https://www.bing.com").GetAwaiter().GetResult());
        }
    }
}
stoubmac:testapp stoub$ dotnet run
Project testapp (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.

Unhandled Exception: System.PlatformNotSupportedException: The libcurl library in use (7.43.0) and its SSL backend ("SecureTransport") do not support custom handling of certificates. A libcurl built with OpenSSL is required.
   at System.Net.Http.CurlHandler.SslProvider.SetSslOptions(EasyRequest easy, ClientCertificateOption clientCertOption)
   at System.Net.Http.CurlHandler.EasyRequest.InitializeCurl()
   at System.Net.Http.CurlHandler.MultiAgent.ActivateNewRequest(EasyRequest easy)
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
   at System.Net.Http.HttpClient.<FinishSendAsync>d__58.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at ConsoleApplication.Program.Main(String[] args)
stoubmac:testapp stoub$ export DYLD_LIBRARY_PATH=/usr/local/lib/
stoubmac:testapp stoub$ dotnet run
Project testapp (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.
StatusCode: 200, ReasonPhrase: 'OK', Version: 1.1, Content: System.Net.Http.StreamContent, Headers:
{
  Cache-Control: max-age=0, private
  Vary: Accept-Encoding
  Server: Microsoft-IIS/8.5
  P3P: CP="NON UNI COM NAV STA LOC CURa DEVa PSAa PSDa OUR IND"
  Set-Cookie: SRCHD=AF=NOFORM; domain=.bing.com; expires=Sat, 21-Jul-2018 23:49:04 GMT; path=/
  Set-Cookie: SRCHUID=V=2&GUID=05A7870E43E942F68BAC35BB8A4C52C6; expires=Sat, 21-Jul-2018 23:49:04 GMT; path=/
  Set-Cookie: SRCHUSR=DOB=20160721; domain=.bing.com; expires=Sat, 21-Jul-2018 23:49:04 GMT; path=/
  Set-Cookie: _SS=SID=0A99E65098CC6D950303EF09991F6C8C; domain=.bing.com; path=/
  Set-Cookie: _EDGE_S=F=1&SID=0A99E65098CC6D950303EF09991F6C8C; path=/; httponly; domain=bing.com
  Set-Cookie: _EDGE_V=1; path=/; httponly; expires=Sat, 21-Jul-2018 23:49:04 GMT; domain=bing.com
  Set-Cookie: MUID=3441EE6881166AB927F3E73180C56B38; path=/; expires=Sat, 21-Jul-2018 23:49:04 GMT; domain=bing.com
  Set-Cookie: MUIDB=3441EE6881166AB927F3E73180C56B38; path=/; httponly; expires=Sat, 21-Jul-2018 23:49:04 GMT
  X-MSEdge-Ref: Ref A: 8C58C90CF2764DCC8D6E5F4EBDDA771C Ref B: 3F2B603999D10209F1CECA268112300C Ref C: Thu Jul 21 16:49:04 2016 PST
  Date: Thu, 21 Jul 2016 23:49:04 GMT
  Content-Type: text/html; charset=utf-8
}
stoubmac:testapp stoub$

@alanrenouf
Copy link

Fantastic, the export DYLD_LIBRARY_PATH=/usr/local/lib/ was what i was missing! Thanks

@jchannon
Copy link

What's the fix for CentOS?

@bartonjs
Copy link
Member

@jchannon CentOS 6 had a curl-openssl package which would (have) work(ed). The problem is that the default libcurl package on CentOS uses Mozilla NSS as the TLS provider, and we don't have the ability to interpret their certificate pointers.

Normal CentOS curl:

$ curl --version
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.19.1 Basic ECC zlib/1.2.7 libidn/1.28 libssh2/1.4.3

Normal Ubuntu curl:

$ curl --version
curl 7.38.0 (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3

Note the Ubuntu one in this example is OpenSSL/1.0.1f, whereas the CentOS one uses NSS/3.19.1 Basic ECC.

Since curl doesn't have their own abstraction of certificates we would have to have support for each of the (currently 8) possible providers. Right now OpenSSL is the only one.

Since there's not a CentOS package for that anymore that I can find offhand; that might mean you have to build from source. Or maybe there's just something I'm missing in the CentOS package tree.

@jchannon
Copy link

jchannon commented Aug 12, 2016

@bartonjs we have it working on CentOS now, what we did was rm -f /usr/bin/curl, rm -f rm /lib64/libcurl*, yum groupinstall "Development @Tools" then downloaded latest curl tarball http://curl.haxx.se/download/curl-7.50.1.tar.gz run ./configure, make, make install

@jchannon
Copy link

jchannon commented Aug 12, 2016

However trying to debug my app on OSX I followed the above instructions with

brew install curl --with-openssl
brew link --force curl
export DYLD_LIBRARY_PATH=/usr/local/lib/

Now when I run dotnet build I see this:

Unhandled Exception: System.TypeInitializationException: The type initializer for 'Crypto' threw an exception. ---> System.TypeInitializationException: The type initializer for 'CryptoInitializer' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'System.Security.Cryptography.Native': The specified module could not be found.
 (Exception from HRESULT: 0x8007007E)
   at Interop.CryptoInitializer.EnsureOpenSslInitialized()
   at Interop.CryptoInitializer..cctor()
   --- End of inner exception stack trace ---
   at Interop.Crypto..cctor()
   --- End of inner exception stack trace ---
   at Interop.Crypto.GetRandomBytes(Byte* buf, Int32 num)
   at System.IO.Path.GetCryptoRandomBytes(Byte* bytes, Int32 byteCount)
   at System.IO.Path.GetRandomFileName()
   at Microsoft.DotNet.InternalAbstractions.TemporaryDirectory..ctor()
   at Microsoft.Extensions.EnvironmentAbstractions.DirectoryWrapper.CreateTemporaryDirectory()
   at Microsoft.DotNet.Configurer.NuGetPackagesArchiver..ctor()
   at Microsoft.DotNet.Cli.Program.ConfigureDotNetForFirstTimeUse(INuGetCacheSentinel nugetCacheSentinel)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)
[1]    9392 abort      dotnet build

I am less than amused 😠

Also these instructions are the complete opposite of what is shown on www.dot.net

brew update
brew install openssl
ln -s /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib /usr/local/lib/
ln -s /usr/local/opt/openssl/lib/libssl.1.0.0.dylib /usr/local/lib/

@Yantrio
Copy link

Yantrio commented Aug 12, 2016

@jchannon
Copy link

Thanks, the fix buried in there was to run sudo install_name_tool -add_rpath /usr/local/opt/openssl/lib /usr/local/share/dotnet/shared/Microsoft.NETCore.App/1.0.0/System.Security.Cryptography.Native.dylib

Quite frankly this is shit show and MS need to sort this out.

@jchannon
Copy link

jchannon commented Aug 12, 2016

Trying to debug a simple http request with osx now results in this error message

"One or more errors occurred. (The libcurl library in use (7.43.0) and its SSL backend (\"SecureTransport\") do not support custom handling of certificates. A libcurl built with OpenSSL is required.)"

The code is:

            var handler = new HttpClientHandler { CookieContainer = new CookieContainer() };
            handler.AllowAutoRedirect = false;
            handler.ServerCertificateCustomValidationCallback = (msg, cert, chain, errors) => true;
            var httpClient = new HttpClient(handler);
            var resp = httpClient.PostAsync(url, new StringContent(JsonConvert.SerializeObject(loginDTO), Encoding.UTF8, "application/json")).Result;

Yet when I run curl --version from terminal I get this

curl 7.50.1 (x86_64-apple-darwin15.6.0) libcurl/7.50.1 OpenSSL/1.0.2h zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets

The solution to this when debugging is to set the DYLD_LIBRARY_PATH environment variable. To do this in VSCode you add this to launch.json

 "env": {
          "DYLD_LIBRARY_PATH":"/usr/local/lib/"
        }

@evermeire
Copy link

evermeire commented Aug 18, 2016

I agree, it would be great if someone could figure out an easy solution. MacOS 10.11.x (El Capitan) makes it harder to change the OpenSSL version that ships with OS. I am hoping that 10.12 (Sierra) has a version of OpenSSL that plays nicer with ASP.NET.

/usr/bin/openssl
OpenSSL 0.9.8zh 14 Jan 2016

on MacOS 10.11 (El Capitan) Haven't had a chance to install 10.12 beta yet.

@evermeire
Copy link

Also, I deploy my Asp.Net core web app to an Azure instance and than I see the error message of

The specified CGI application encountered an error and the server terminated the process.

@hlogmans
Copy link

hlogmans commented Jan 2, 2017

With Core 1.1, I run into this issue again on Mac Sierra. Reinstalled with the instructions (OpenSSL 1.0.2j) and the symlinks. The dotnet new command runs fine, but when I use the httpclient:

(The libcurl library in use (7.51.0) and its SSL backend ("SecureTransport") do not support custom handling of certificates. A libcurl built with OpenSSL is required.) ---> System.PlatformNotSupportedException: The libcurl library in use (7.51.0) and its SSL backend ("SecureTransport") do not support custom handling of certificates. A libcurl built with OpenSSL is required.

I used the instructions in other reports to use a openssl-build of curl, and the command line reports doing so. But the dotnet project seems to reference the system version?

.NET Command Line Tools (1.0.0-preview2-1-003177)

Product Information:
 Version:            1.0.0-preview2-1-003177
 Commit SHA-1 hash:  a2df9c2576

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64

libcurl.dylib -> ../Cellar/curl/7.52.1/lib/libcurl.dylib

When using DYLD_LIBRARY_PATH things mess up quickly (methods not found etc), and the rpath commands do not seem to help at all.

As I understood, things changed in core 1.1 to both support native Apple and OpenSSL. But how do I choose between them?

@bartonjs
Copy link
Member

bartonjs commented Jan 3, 2017

@hlogmans The 1.1 release started using Security.framework for hashing, HMAC, and symmetric encryption. Asymmetric cryptography, certificates, and TLS are all still performed by OpenSSL.

otool -L System.Net.Http.Native.dylib should tell you how that library linked against curl (@rpath or a direct path reference), which should aid in tracking down why it isn't loading the build of the library you expect.

@hlogmans
Copy link

hlogmans commented Jan 6, 2017

System.Net.Http.Native.dylib:
@rpath/System.Net.Http.Native.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 8.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

/usr/lib/libcurl.4.dylib:
/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 57740.30.50)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1348.28.0)
/System/Library/Frameworks/LDAP.framework/Versions/A/LDAP (compatibility version 1.0.0, current version 2.4.0)
/System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos (compatibility version 5.0.0, current version 6.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)

So that seems quite logical that it targets the wrong one. Next step: how to fix it form me, and how to fix it for everyone... (and thanks for your support @bartonjs)

Update:
sudo install_name_tool -change /usr/lib/libcurl.4.dylib /usr/local/opt/curl/lib/libcurl.4.dylib System.Net.Http.Native.dylib

@Priya91
Copy link
Contributor

Priya91 commented Feb 16, 2017

@karelz The release docs needs to be updated as mentioned in this comment, can you please reroute to the right person.

cc @mairaw

@Priya91
Copy link
Contributor

Priya91 commented Feb 16, 2017

@niemyjski Apart from the documentation update, can you create another issue with an api proposal for the API you've mentioned in this comment. The API proposal process information is here

@mairaw
Copy link
Contributor

mairaw commented Feb 17, 2017

Is it about the installation instructions on the dot.net site @Priya91?

@Priya91
Copy link
Contributor

Priya91 commented Feb 17, 2017

@mairaw Yes..

@jchannon
Copy link

Try this http://stackoverflow.com/questions/17643509/conflict-between-dynamic-linking-priority-in-osx/35070568#35070568

@bartonjs
Copy link
Member

It might be possible to bring the libcurl+openssl1.0 workaround back for 2.0. https://github.com/dotnet/corefx/issues/19718 tracks the work. (Client authentication still won't work on macOS with HttpClient, because the bridge only reliably goes one way)

@karelz
Copy link
Member

karelz commented May 15, 2017

If you hit this and need the workaround, please go ASAP and vote for the issue dotnet/corefx#19718 which @bartonjs created. Thanks!

@AnandInstro
Copy link

What's the fix for Fedora26?

@jrmacks
Copy link

jrmacks commented Nov 13, 2017

FYI getting this on my mac using dotnet core 2.0.2.

my mac version:
ProductName: Mac OS X ProductVersion: 10.13.1 BuildVersion: 17B48
My original curl version:
curl 7.54.0 (x86_64-apple-darwin17.0) libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0

I updated my curl via homebrew and ran through the sudo install_name_tool change to System.Net.Http.Native.dylib and now my app recognizes the new curl version but still get the error.

The handler does not support custom handling of certificates with this combination of libcurl (7.56.1) and its SSL backend ("OpenSSL/1.0.2m").

As i'm reading through this thread it appears that the issue is with a bug in curl and there is no workaround?

@bartonjs
Copy link
Member

@jrmacks In .NET Core 2.0 the certificates library and TLS library used on macOS are from Security.framework, there's no longer support on macOS for custom callbacks via libcurl+openssl. And, unfortunately, libcurl+darwinssl (SecureTransport) doesn't support callbacks.

@jrmacks
Copy link

jrmacks commented Nov 14, 2017

Thanks @bartonjs for the quick reply. Are there any plans to have parity on mac with this feature? Based on your response I'm assuming it's not possible with the current architecture.

@niemyjski
Copy link
Author

Any updates on this issue when running on macOS?

@karelz
Copy link
Member

karelz commented Jan 2, 2018

@niemyjski it would be best to not continue discussion on closed issues - we do not monitor them in general.
For this particular case, I am not sure what you're asking for -- there have been several spin offs, none is tracked by this issue anymore.

@niemyjski
Copy link
Author

They shouldn't be closed if they are still an active issue ;) There are issues when you have this handler registered on macOS...

@stephentoub
Copy link
Member

@niemyjski, what is it you're concerned is still active? With the default libcurl on macOS, ServerCertificateCustomValidationCallback is simply not supported with arbitrary delegates. However, the issue you originally opened was using a delegate that always returned true, and that has been fully addressed via the DangerousAcceptAnyServerCertificateValidator member that was added in .NET Core 2.0. This also won't be an issue when using the new managed handler implementation that's on a path to ship in 2.1. If you continue to have concerns, please open a different issue.

@jchannon
Copy link

jchannon commented Jan 3, 2018 via email

@stephentoub
Copy link
Member

What's the 2.1 change you mention? Any docs etc?

It's not done yet.
https://github.com/dotnet/corefx/tree/master/src/System.Net.Http/src/System/Net/Http/Managed
Search issues for "ManagedHandler".

@MonikaMalik123
Copy link

Hi Guys
System - Linux 7.3
Run -Time - dotnet core 2.0.0

I am running dotnet Core 2.0 application on this container (registry.access.redhat.com/dotnet/dotnet-20-rhel7:latest) in linux 7.3, but when login to application and enter password gives me this error - "One or more errors occurred. (The handler does not support custom handling of certificates with this combination of libcurl (7.29.0) and its SSL backend ("NSS/3.28.3").)"
FYI - This application works fine on Windows.

Please suggest me any resolution for this issue? Much Appreciated if anyone can help me with this

Thanks

@ahaid
Copy link

ahaid commented Feb 26, 2018

I'm having the same issue on Mac and RHEL 7.4

@bartonjs
Copy link
Member

@omajid Is there an optional package that people need on RHEL to get libcurl backed by OpenSSL? I thought it was marked as a dependency for the dotnet package(s)?

@evertmulder
Copy link

Using 2.1.300-preview1-008174 on MacOSX the issue still occurs

Unhandled Exception: System.PlatformNotSupportedException: The handler does not support custom handling of certificates with this combination of libcurl (7.53.1) and its SSL backend ("OpenSSL/1.0.2n").
   at System.Net.Http.CurlHandler.SslProvider.SetSslOptions(EasyRequest easy, ClientCertificateOption clientCertOption)
   at System.Net.Http.CurlHandler.EasyRequest.InitializeCurl()
   at System.Net.Http.CurlHandler.MultiAgent.ActivateNewRequest(EasyRequest easy)

@stephentoub https://github.com/dotnet/corefx/tree/master/src/System.Net.Http/src/System/Net/Http/Managed

looks like it os renamed to

https://github.com/dotnet/corefx/blob/master/src/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/

I was hoping in the 2.1 release....

@wfurt
Copy link
Member

wfurt commented Feb 28, 2018

It is in in 2.1 preview1 @evertmulder. But you need to enable it either via app context or via environmental variable.
export DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=true should do the trick.
From the trace, you still use default curl handler.

@evertmulder
Copy link

evertmulder commented Feb 28, 2018

@wfurt is it? Executing this (or exporting the env variable) still leads to a stack trace including the CurlHandler...

DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=1 dotnet run

Unhandled Exception: System.PlatformNotSupportedException: The handler does not support custom handling of certificates with this combination of libcurl (7.53.1) and its SSL backend ("OpenSSL/1.0.2n").
   at System.Net.Http.CurlHandler.SslProvider.SetSslOptions(EasyRequest easy, ClientCertificateOption clientCertOption)
   at System.Net.Http.CurlHandler.EasyRequest.InitializeCurl()
   at System.Net.Http.CurlHandler.MultiAgent.ActivateNewRequest(EasyRequest easy)
--- End of stack trace from previous location where exception was thrown ---
   at System.Net.Http.HttpClient.<FinishSendAsyncBuffered>d__62.MoveNext()
   at cf.Program.<Main>d__0.MoveNext() in /Users/emulder/dev/core/tmp/cf/Program.cs:line 36
   at cf.Program.<Main>(String[] args)

But changing my test program to use DangerousAcceptAnyServerCertificateValidator, could help until something like https://github.com/dotnet/corefx/issues/18972 is fixed. (custom root certificate authorities)

var handler = new HttpClientHandler();
handler.ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;
var _httpClient = new HttpClient(handler);

@wfurt
Copy link
Member

wfurt commented Feb 28, 2018

Sorry about that @evertmulder. It changed after preview1 cut. Please follow notes from https://blogs.msdn.microsoft.com/dotnet/2018/02/27/announcing-net-core-2-1-preview-1/

@wfurt
Copy link
Member

wfurt commented Mar 5, 2018

Did you get that working @evertmulder? (just curious)

@evertmulder
Copy link

@wfurt No, I will try again when the SocketsHttpHandler is available in a preview release.

@thangchung
Copy link

@wfurt I run .NET Core stack on Docker for Windows with Kubernetes (Linux container on Windows 10) and got the following exception. I tried to use ServerCertificateCustomValidationCallback, but no luck. I used .NET Core SDK 2.1.301. Could anyone help to clarify?

Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler[3]
      Exception occurred while processing message.
System.InvalidOperationException: IDX20803: Unable to obtain configuration from: 'https://localhost:443/idp/.well-known/openid-configuration'. ---> System.IO.IOException: IDX20804: Unable to retrieve document from: 'https://localhost:443/idp/.well-known/openid-configuration'. ---> System.Net.Http.HttpRequestException: Address not available ---> System.Net.Sockets.SocketException: Address not available
   at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at System.Net.Http.ConnectHelper.ConnectAsync(String host, Int32 port, CancellationToken cancellationToken)
   at System.Threading.Tasks.ValueTask`1.get_Result()
   at System.Net.Http.HttpConnectionPool.CreateConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Threading.Tasks.ValueTask`1.get_Result()
   at System.Net.Http.HttpConnectionPool.WaitForCreatedConnectionAsync(ValueTask`1 creationTask)
   at System.Threading.Tasks.ValueTask`1.get_Result()
   at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
   at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
   at Microsoft.IdentityModel.Protocols.HttpDocumentRetriever.GetDocumentAsync(String address, CancellationToken cancel)
   --- End of inner exception stack trace ---
   at Microsoft.IdentityModel.Protocols.HttpDocumentRetriever.GetDocumentAsync(String address, CancellationToken cancel)
   at Microsoft.IdentityModel.Protocols.OpenIdConnect.OpenIdConnectConfigurationRetriever.GetAsync(String address, IDocumentRetriever retriever, CancellationToken cancel)
   at Microsoft.IdentityModel.Protocols.ConfigurationManager`1.GetConfigurationAsync(CancellationToken cancel)
   --- End of inner exception stack trace ---
   at Microsoft.IdentityModel.Protocols.ConfigurationManager`1.GetConfigurationAsync(CancellationToken cancel)
   at Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler.HandleAuthenticateAsync()
�[41m�[30mfail�[39m�[22m�[49m: Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler[3]
      Exception occurred while processing message.

@stephentoub
Copy link
Member

@thangchung, I'm not sure what that error has to do with this issue. The key part of that message is "System.Net.Sockets.SocketException: Address not available", which means it couldn't resolve localhost. Sounds like you may need to update the configuration of your image, and/or use a different address.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Net documentation Documentation bug or enhancement, does not impact product or test code os-linux Linux OS (any supported distro)
Projects
None yet
Development

No branches or pull requests