Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
Created attachment 17840 [details]
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
Can you please try running btls-cert-sync and see if that fixes it? If yes, we should provide a better exception message.
*** Bug 44972 has been marked as a duplicate of this bug. ***
Nope, doesn't help, although it gave me a clue from where the issue might come from:
Found 0 files in the old store.
root@ArchiDroid:/tmp/mono/BTLS/bin# dpkg -l ca-certificates* | grep ii
ii ca-certificates 20160104 all Common CA certificates
ii ca-certificates-mono 220.127.116.11+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.
> 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.
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).
$ 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.
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.
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.
Thanks for the info. It is possible that we didn't correctly add the system-wide directory, I'll look into that.
> Yes, I have parallel Mono environments
Good! Just checking.
I submitted a PR for this issue on github:
I merged the PR, thank you!