-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
HttpClient with mutual TLS on macOS High Sierra - does not support client authentication (Libcurl/LibreSSL problems) #24726
Comments
I can take a look @asjafjell If you have more specific steps or simple test app, that would be great. |
@wfurt I have exported I will try to make a simplification of the code as soon as possible. In the meantime, you can test the original code. It is a public repo digipost/signature-api-client-dotnet (branch: net-standard-2-build), and a test that uses HttpClient is this one Note that a certificate path and password has to be added to a secrets file at ~/.microsoft/usersecrets/User-Secret-ID/secrets.json:
Thanks in advance. |
I also have this problem. I exported DYLD_LIBRARY_PATH according to https://spin.atomicobject.com/2017/09/28/net-core-osx-libcurl-openssl/ because I was getting the following:
So even using OpenSSL with curl I get:
I was under the impression .NET Core 2.0 was going to fix having to use curl with OpenSSL in favour of SecureTransport? Method
Edit If I don't run any updates to curl it does actually look like it finds the certificate in the Keychain; however, I still get the same kind of error:
|
I have now replaced the default
I don't know if this makes me any closer to any solution, but this is now the newest version of Curl being run, and it is the version I installed throug Brew with the |
simple repro would be good @asjafjell The hit with DYLD_LIBRARY_PATH as meant to help with loading proper curl. However that will prefer everything from that directory over over system default and it may cause the libJPEG.dylib loading error. To avoid that you can try something like = /usr/local/Cellar/curl/7.57.0/lib @gbrhaz As notes from #21679 state, there may be additional work needed to get that working on OSX. |
@wfurt Yes, I believe I'm doing everything that post suggests. This is essentially what's going on:
I can check the certificate and it has a private key, is the correct one, all that kind of stuff, but still get the previous error. Just to clarify: the .pfx was imported into my login keychain. I looked at the documentation here: Which says "On macOS the CurrentUser\My store is the user's default keychain (login.keychain, by default). The LocalMachine\My store is System.keychain". I have tried importing the .pfx into both login and system keychains and still no luck. Still get:
|
Can you wrap that to runable app and point me at right server @gbrhaz? It would save my troubles trying to set up a repro. From the exception it seems like you properly overcome all the other hurtles and there is some platform to work to be done. |
If you guys are just doing dev locally and trying to build out a stack on macOS - our work around was simply to build a nginx Docker to act as a reverse proxy. The nginx container would do the client auth for us and the .NET Core solution just connects to the container. This is not an optimal solution, but avoided us having to do dev on Windows (We are deploying in Ubuntu with Docker, so in the end we can use client authentication when we get out of local machine development). Here is the nginx config if anyone is interested. simply add the cert and key (remove password) and voila done.
|
@wfurt Unfortunately I don't think it'd be possible to send you a precise project for this. Limitations on my side. In the meantime, I have done some digging around and found this. Are you able to shed any light on this? It looks as if any certificate that is added as a client certificate is denied and a platform not supported exception is thrown? I thought .net core 2.0 allowed X509 from Keychain so I'm a bit confused by this - or maybe it's only supported for server certificates, not client? |
As mentioned above - this should be addressed in .NET Core 2.1 which by default uses SocketsHttpHandler. Closing |
@karelz, unfortunately the same error occurs while using version 2.1.300-rc1-008673 on CentOS 7 (The handler does not support client authentication certificates with this combination of libcurl (7.29.0) and its SSL backend ("NSS/3.34")). |
That is highly suspicious. Please check if you're really running against 2.1. Unless you set explicit opt-in (env.var / AppContext), you won't get libcurl into your process. |
I am running version 2.1.301 and I get
Is this the right place to ask? |
do you actually target netcore2.1 in your project? |
@wfurt Checked the csproj files and found that it was using |
I'm glad it worked for you. this is not always intuitive. |
I am currently targeting |
I have the following error in my netstandard2 class library:
I installed the newest version of Curl with OpenSSL through Homebrew and:
which curl
gives/usr/local/bin/
, andcurl --version
givescurl 7.57.0 (x86_64-apple-darwin17.2.0) libcurl/7.57.0 OpenSSL/1.0.2n zlib/1.2.11
.This does not change the version of Curl being run through my class library.
I have now been reading and testing the possible solutions in #17723, #23640 and ended up with #21679 stating that custom certificate handling will be fixed in netcore 2.1. Do I have to wait till this fix propagates into netstandard?
Is my problem just related to me not being able to change the version of libcurl being executed, or do I have a dead end?
Pardon if the solution is obvious, I have tried for almost a day with outdated and more recent answers of the related posts.
The text was updated successfully, but these errors were encountered: