-
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
Test failure: System.Net.Http.Functional.Tests.SocketsHttpHandler_HttpClientHandler_ServerCertificates_Test.UseCallback_BadCertificate_ExpectedPolicyErrors(url: \"https://self-signed.badssl.com/\", expectedErrors: RemoteCertificateChainErrors) #41381
Comments
Tagging subscribers to this area: @safern, @ViktorHofer |
Tagging subscribers to this area: @dotnet/ncl |
cc: @dotnet/ncl |
@wfurt any thoughts? |
I have local repro. I will take a look. maybe something changed at self-signed.badssl.com. |
it seems fresh and the name does not match. It is curious that it fails only on OSX. cc: @bartonjs for any additional thoughts. since this is HTTP Client test, perhaps we can construct this with SslStream without reliance on external server we cannot control. |
Weird, it looks like macOS just didn't do SNI. I think this test was written prior to CertificateRequest existing, so creating self signed certs had meant a) check one in and wait for it to expire or b) depend on an external resource. Now that certs can be easily made on the fly, I agree that it can go from an external test to a self-test. |
my bad @bartonjs. I got the posted certificate when running openssl from command line. When I run the test, SNI is set and test gets different certificate. That on is for |
It seems like this is essentially dup of #666. The verification fails with CSSMERR_APPLETP_INVALID_EXTENDED_KEY_USAGE because the self-signed certificate does not have EKU set. The question is if EKU should cause RemoteCertificateNameMismatch...? (I think RemoteCertificateChainErrors would still make sense if OS cares about EKU) cc: @vcsjones |
Ah. That. The way we currently detect a hostname mismatch on macOS is to build their version of X509Chain but with an "I'm doing TLS" policy applied. The assumption is that if the base policy passes, but the TLS policy fails, that it failed because of the hostname; but apparently there are secondary characteristics that can also cause it to fail. So there's a tradeoff: a few false negatives, or all of the various bugs/complaints that come from trying to write our own version of the wildcard matching. (It's so much easier to say "it's an OS problem", but it's double-so-much-easier when that's exposed directly.) Maybe that functionality has become more public/directly-diagnosable since the original implementation. |
I will rewrite the test to use certificate we can control to make it less dependent on external entities. We already have enough hooks that we could ignore specific error codes during name validation e.g. use what you described with exceptions. I would expect that we validate rest of the certificate outside of _SslIsHostnameMatch ...? |
The X509Chain class is used to determine the RemoteCertificateChainErrors value, and to pass some context into the AppleCryptoNative_SslIsHostnameMatch function in order to build the request (e.g. it always says that the context is trusted so that an untrusted chain doesn't produce hostname mismatch). Trying to tear apart the false to distinguish "name mismatch" specifically from "generically not valid for TLS" has virtue, but I don't think it'd be approved for 5.0 at this point as it's not a regression. |
failed again in job: runtime-libraries outerloop 20200902.4 failed test: System.Net.Http.Functional.Tests.SocketsHttpHandler_HttpClientHandler_ServerCertificates_Test.UseCallback_BadCertificate_ExpectedPolicyErrors(url: "https://self-signed.badssl.com/\", expectedErrors: RemoteCertificateChainErrors) net5.0-OSX-Release-x64-CoreCLR_release-OSX.1015.Amd64.Open Error message
|
failed in job: runtime-libraries outerloop 20200825.2
net5.0-OSX-Release-x64-CoreCLR_release-OSX.1015.Amd64.Open
Error message
The text was updated successfully, but these errors were encountered: