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

DangerousAcceptAnyServerCertificateValidator delegated not working on Ubuntu 18.04 #30242

Closed
olandese opened this issue Jul 12, 2019 · 10 comments
Closed

Comments

@olandese
Copy link

@olandese olandese commented Jul 12, 2019

Issue Title

DangerousAcceptAnyServerCertificateValidator is ignored on Ubuntu 18.04 with .Net Core 2.2.301

General

I'm using the HttpClient and the DangerousAcceptAnyServerCertificateValidator delegate in the HttpClientHandler but calling rest api with self-signed cerificate generated from a self-signed root certificate, I get the following error:

Error Message:
System.Threading.Tasks.TaskCanceledException : The operation was canceled.
Stack Trace:
at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Stream stream, SslClientAuthenticationOptions sslOptions, CancellationToken cancellationToken)

For more information see my blog post https://blog.olandese.nl/2019/07/12/solve-system-threading-tasks-taskcanceledexception-the-operation-was-canceled-on-ubuntu-18-04-in-net-core-2-2/

@bartonjs bartonjs transferred this issue from dotnet/core Jul 12, 2019
@davidsh
Copy link
Contributor

@davidsh davidsh commented Jul 12, 2019

@olandese Can you please attach the test certificate to this issue so that we can attempt to repro the problem?

There is an interesting issue on Linux where self-signed certificates will NOT work at all because Linux requires the certificate to have additional X509v3 fields set that Windows doesn't require. This is a limitation of Linux and OpenSsl and not related to .NET Core. So, it's quite possible that exporting a self-signed certificate that works on Windows will not work on Linux.

The extra field required on the self-signed certificate is about having the "Cert signing" attribute set on the KeyUsage field.

The specific exception you're getting "The operation was canceled" is probably masking the real problem with the certificate.

Can you try to re-generate a self-signed certificate on Linux directly so that it meets the requirements for Linux?

@davidsh
Copy link
Contributor

@davidsh davidsh commented Jul 12, 2019

@olandese
Copy link
Author

@olandese olandese commented Jul 12, 2019

sure, in which format you want them? the root and the actual certificate

image

Right is the certificate of the rest api, left is the root certificate, installing the root certificate /usr/local/share/ca-certificates/ solved the problem

@davidsh
Copy link
Contributor

@davidsh davidsh commented Jul 12, 2019

sure, in which format you want them? the root and the actual certificate

Based on the issue description, it was assumed there was a single self-signed certificate in use:

but calling rest api with self-signed cerificate I get the following error

But there is actually two certificates in use? A root and a certificate derived from that? So, is the "root" certificate untrusted in some way?

Can you provide a complete repro for this? For example, a runnable project that we can do a "dotnet run" on to reproduce this problem? Also, are you using Ubuntu as a VM or docker image?

@davidsh
Copy link
Contributor

@davidsh davidsh commented Jul 12, 2019

And looking at your images of the certificates you provided, I'm wondering whether the use of SHA1 could be a problem on Linux. SHA256 is recommended as the minimum for certificates.

@olandese
Copy link
Author

@olandese olandese commented Jul 12, 2019

Thank you for your feedback! I will ask to upgrade the encryption algorithm. But anyway, the delegate should suppress all of this "dangerous" things, I would assume.
The rest api is talking with a certificate derived from a self-signed root certificate.
As soon I put the root certiicate in the /usr/local/share/ca-certificates/ everything works fine.
I can provide you the sources, but it's nothing more than I already wrote in the blog post.
And the error is happening both in Docker as in an Azure Ubuntu 18.04 VM as well

@davidsh
Copy link
Contributor

@davidsh davidsh commented Jul 12, 2019

In terms of your scenario, are you running both a client and a server? What "server" is sending back that certificate?

The problem you're seeing could be a variety of issues. The only real way to diagnose this is a repro we can run that reproduces the problem. And the description from the blog article isn't specific enough for us to construct a run-able repro.

Other customers in the past have been able to use Docker, for example, to provide a fully run-able repro program that can build and run and demonstrate problems that they report here.

@olandese
Copy link
Author

@olandese olandese commented Jul 12, 2019

the derived certificate is running on an Azure API Management.
I will create and provide you a repo, or docker image to reproduce this behaviour

@bartonjs
Copy link
Member

@bartonjs bartonjs commented Jul 15, 2019

And looking at your images of the certificates you provided, I'm wondering whether the use of SHA1 could be a problem on Linux.

The SHA1 in the images is "thumbprint algorithm". It's not a real attribute of the certificate, just explaining that the thumbprint is computed using SHA-1, which is true for all certificates. (It's just a CertUI oddity)

@davidsh
Copy link
Contributor

@davidsh davidsh commented Sep 4, 2019

I will create and provide you a repo, or docker image to reproduce this behaviour

@olandese Please let us know when/if you will be able to create a repo for this issue so that we can easily reproduce the behavior you see.

Also, please consider trying out .NET Core 3.0. Latest preview:
https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0-preview-9/

@davidsh davidsh closed this Sep 4, 2019
@msftgits msftgits transferred this issue from dotnet/corefx Feb 1, 2020
@msftgits msftgits added this to the 5.0 milestone Feb 1, 2020
@msftbot msftbot bot locked as resolved and limited conversation to collaborators Dec 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants