-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Unexpected HttpClient cert validation & timeout failures #805
Comments
news.com fails for me in browser, so I think that one is a legit cert issue. apple.com works on Windows. @aik-jahoda can you try to repro in OSX? |
I'd like to add that sometimes I experience |
@JohnyL |
@scalablecory It's a luck I have found that piece of code:
As you see, it's |
@scalablecory news.com works great for me in a browser on Mac and on Windows. It's a redirect to cnet.com/news. As I mentioned in my initial report, it also works with curl on the same machines. If I directly invoke cnet.com instead, I get the same error. Their cert has an issuer name of *.cnet.com, so maybe there's a problem with wildcard handling? |
@scalablecory Also, opentable.com works fine with curl with no special headers. |
@JohnyL thanks, please move to separate issue so we can keep track of it. from what I can tell it is unrelated to this issue. |
@scalablecory I added the User-Agent and Accept headers. With User-Agent set to my app name, it hangs. I then set it to curl, and it worked fine. So that one seems to be an oddity with opentable's handling of the user agent string. That just leaves the cert problem with apple.com and news.com. |
news.com discrepancy is possibly the browser using a private cert store -- for me, it works on Chrome but fails on Edge. HttpClient will use the platform's cert store. @bartonjs @krwq do you have any tips to help diagnose that? For opentable.com, I ran Fiddler to grab all the headers my browser generates and added them all to HttpClient.DefaultRequestHeaders. I did not perform further analysis to see what exactly they are looking for. They may be trying to prevent screen scraping of their data, so I would like to respect that and not go further into that here. |
@scalablecory Presumably, curl would be using the platform's cert store, right? I would expect it to have the same behavior as HttpClient. Note that I also tried replacing SocketsHttpHandler with HttpClientHandler for the HttpClient instance. It behaved in an identical way. |
The hostname mismatch from macOS may be the same thing that's being looked at in #666. (We let the OS tell us if the hostname mismatches, but can only really do it as a side effect of a different chain build, and it seems that some ambient state is causing failures on newer macOS versions that never failed in the past). |
Your curl may be compiled to use a different cert store (like openssl/libressl) rather than the macos cert store (Secure Transport) which HttpClient uses. curl, on Windows and compiled to use the Windows cert store, fails in the same way that Edge and HttpClient does. |
It is reproducible on my machine. |
Thanks @aik-jahoda |
It seems like this is distinct issue from #666 even if observed behavior is same. #666 fails only on Catalina for me with internal error It is curious that "apple.com" is special cased in |
That's frustrating. I don't see an obvious way that we can get into the hostname verifier without the additional baggage. (I also don't see where the CSSMERR_APPLETP_INVALID_EXTENDED_KEY_USAGE error is coming from, since the SSL policy does have the "if it's not present, that's fine"). |
We have similar issue here with an intranet application calling internal API from different network. The internal API uses a certificate issued by internal CA which is behind firewall and not available for the API consumer. Here is the sample:
We tried this on netcore2.2 and netcore3.1. Operating system is RHEL7, libcurl 7.29. Error is always the same:
|
Your issue is different IMHO @catlion. Can you open a separate issue and add packet capture? I think it will be better to keep this one specific to MacOS as the underlying reasons are different. new.com fails in Safari and I think that is a legitimate failure.
There is nothing in the certificate about news.com. That would leave apple.com last from the list. (Works from Linux and fails on MacOS) Can you confirm that @geeknoid? |
@catlion Did you ever figure out what the issue was or did you open up another issue for it? We are running into similar problems intermttantly on our internal intranet sites. Very rarely though |
@rdasan we just allowed access from our server to the certificate authority through the firewall. We couldn't figure how to disable this check completely, unfortunately. |
It should be sufficient to have all intermediate certs in your X509Certificate store @catlion. That avoids needs to fetch them as needed. |
Below is a simple program that tries to read the home page of a few common web sites. I'm persistently experiencing two types of errors:
For certain sites (e.g. www.apple.com), the GET request fails due to a cert validation error. Installing a cert validation callback hook lets me see that the validation error is due to
RemoteCertificateNameMismatch
.For certain sites (e.g. www.opentable.com), something gets stuck for a long time (maybe 30s), and then fails due to a timeout.
Issuing simple
curl www.apple.com
orcurl www.opentable.com
commands on the same physical machine works flawlessly, as does using a web browser, yet my simple program is failing. This is happening on macOS 10.15.1 using .NET Core 3.0 from Visual Studio for Mac 8.3.11 (build 1).Produced output is included below.
The text was updated successfully, but these errors were encountered: