Bug 44963 - [Regression] BTLS fails to verify certificate when using WebClient
Summary: [Regression] BTLS fails to verify certificate when using WebClient
Status: VERIFIED FIXED
Alias: None
Product: Class Libraries
Classification: Mono
Component: Mono.Security ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: 4.8.0 (C9)
Assignee: Martin Baulig
URL:
: 44972 ()
Depends on:
Blocks:
 
Reported: 2016-10-01 21:40 UTC by Łukasz Domeradzki
Modified: 2017-01-12 10:24 UTC (History)
8 users (show)

Tags: btls
Is this bug a regression?: Yes
Last known good build: 3e735a6171e151dd122830f82ee90e9419e8dbbd


Attachments
Reproducable case (3.16 KB, application/x-zip-compressed)
2016-10-01 21:40 UTC, Łukasz Domeradzki
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
VERIFIED FIXED

Description Łukasz Domeradzki 2016-10-01 21:40:25 UTC
Created attachment 17840 [details]
Reproducable case

Newly added BTLS seems to have some serious regression with WebClient, as it fails entirely to verificate certificate, despite of valid setup.

HttpClient works OK, as well as turning off certificate validation (ServicePointManager.ServerCertificateValidationCallback += (s, ce, ca, p) => true;). I added reproducable case - this is not setup-specific or cert storage issue. It regressed on my valid setup.

System.Net.WebException: Error: TrustFailure (Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED) ---> Mono.Btls.MonoBtlsException: Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
  at Mono.Net.Security.MobileAuthenticatedStream.ProcessAuthentication (System.Net.LazyAsyncResult lazyResult) <0x40f67f40 + 0x00213> in <2da547d0c0764eee863ddbfbf7fbce35>:0
Comment 1 Alexander Köplinger [MSFT] 2016-10-03 15:27:19 UTC
Can you please try running btls-cert-sync and see if that fixes it? If yes, we should provide a better exception message.
Comment 2 Alexander Köplinger [MSFT] 2016-10-03 16:23:22 UTC
*** Bug 44972 has been marked as a duplicate of this bug. ***
Comment 3 Łukasz Domeradzki 2016-10-03 20:27:28 UTC
Nope, doesn't help, although it gave me a clue from where the issue might come from:

root@ArchiDroid:/tmp/mono/BTLS/bin# btls-cert-sync
Found 0 files in the old store.

However:

root@ArchiDroid:/tmp/mono/BTLS/bin# dpkg -l ca-certificates* | grep ii
ii  ca-certificates      20160104          all          Common CA certificates
ii  ca-certificates-mono 4.2.1.102+dfsg2-8 all          Common CA certificates (Mono keystore)

It might be issue related to self-builds that are being installed in custom location - /opt/mono in my case. For some reason btls-cert-sync is unable to find any certificates (?) when searching for them, which might also be the reason why such thing is happening.

I have ca-certificates and ca-certificates-mono installed from native Debian repo, but that Mono is used for bootstrapping my custom build only. However, on legacy TLS provider (export MONO_TLS_PROVIDER="legacy") certificates work perfectly fine and my reproducable case outputs "OK". On BTLS (export MONO_TLS_PROVIDER="btls") the issue happens.

Based on that info, it's very likely that there is some issue with btls-cert-sync in custom builds, but that issue doesn't exist with legacy TLS provider. I'm not sure if having ca-certificates-mono installed affect the result of legacy TLS provider, because perhaps it's not BTLS that is broken, but mozroots or similar thing that should be executed prior to that for cert sync - which might not work in custom builds, but makes legacy TLS working, as I still have my Debian ca-certificates-mono in version 4.2.

Maybe there is a step that is being omitted, either by me or by make process? I'm doing autogen.sh with --prefix=/opt/mono, then make and make install. Make install should handle ca-certificates IIRC.

In any case, let me know if there is something else to check, but that issue should be quite easy to reproduce with debian + mono from debian repo (used for bootstrapping only) and custom build.
Comment 4 Andres G. Aragoneses 2016-10-04 05:04:26 UTC
> I'm doing autogen.sh with --prefix=/opt/mono

Why are you installing in /opt/mono? I may be wrong but I think this prefix is only recommended for parallel mono environments (http://www.mono-project.com/docs/compiling-mono/parallel-mono-environments/). Do you have parallel mono environments? (That is, two versions of mono installed in parallel)

If not, you should probably stick to /usr/local, being very careful of not installing mono packages from your distro while you do this.
Comment 5 Martin Baulig 2016-10-04 16:53:14 UTC
btls-cert-sync assumes that you have previously used the cert-sync tool to install the trusted roots in your home directory.  It will not touch the system store and if you run it as root, it will convert the store in the root user's home directory.

Using the system certificates (from that ca-certificates package on Debian) is something that we're investigating, but it isn't done yet.

The cert-sync tool has been adjusted to support both the old and the new store (there's a --legacy and --btls argument).

Running
$ cert-sync --system --btls ca-certs.pem
should do the job, though this has not been tested yet.

We have also switched the default TLS Provider back to "legacy" until these issues have been sorted out.
Comment 6 Łukasz Domeradzki 2016-10-04 18:31:20 UTC
@Andres

Yes, I have parallel Mono environments - actually Debian one from mono-complete package, and local one installed to /opt/mono that I'm using most of the time with my custom envsetup.sh. That's the whole point of my custom build - I don't want to touch Debian packages or cause a mess, I want to have everything in one place so I can easily rm -rf or compile new one from up-to-date sources if needed. This is excellent solution for me, because all I'm doing is "source /opt/mono/envsetup.sh" if file exists.

@Martin

Thanks for answer! I found some new clues:

I executed cert-sync /etc/ssl/certs/ca-certificates.crt and it didn't work - I mean command executed properly, but for some reason trust failure was still here. Then I executed cert-sync --user /etc/ssl/certs/ca-certificates.crt and that DID work, which means that for some reason system-wide cert-sync doesn't work, or is not properly detected by BTLS.
Comment 7 Martin Baulig 2016-10-05 16:30:35 UTC
Thanks for the info.  It is possible that we didn't correctly add the system-wide directory, I'll look into that.
Comment 8 Andres G. Aragoneses 2016-10-05 16:40:28 UTC
> Yes, I have parallel Mono environments

Good! Just checking.
Comment 9 mgi 2016-12-01 21:01:28 UTC
I submitted a PR for this issue on github:
https://github.com/mono/mono/pull/4027
Comment 10 Alexander Köplinger [MSFT] 2016-12-22 13:14:20 UTC
I merged the PR, thank you!