Bug 25317 - Mono SslStream not sending intermediate certificates
Summary: Mono SslStream not sending intermediate certificates
Status: NEW
Alias: None
Product: Class Libraries
Classification: Mono
Component: System ()
Version: master
Hardware: PC Linux
: --- normal
Target Milestone: Untriaged
Assignee: Martin Baulig
Depends on:
Reported: 2014-12-12 03:59 UTC by kryss
Modified: 2017-04-04 13:02 UTC (History)
5 users (show)

Tags: SSL SslStream X509Certificate2 X509CertificateCollection
Is this bug a regression?: ---
Last known good build:

Server code - reproducible example - short program (2.45 KB, text/plain)
2014-12-12 04:02 UTC, kryss
Server output on Windows + .NET (2.07 KB, text/plain)
2014-12-12 04:03 UTC, kryss
Server output on Linux (SLC6 - Fedora derivative) + Mono (1.83 KB, text/plain)
2014-12-12 04:05 UTC, kryss
Output from openssl client (1.66 KB, text/plain)
2014-12-12 04:07 UTC, kryss

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 for Bug 25317 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description kryss 2014-12-12 03:59:00 UTC

Comment 1 kryss 2014-12-12 04:02:37 UTC
Created attachment 9041 [details]
Server code - reproducible example - short program

This is the server code that loads a certificate+chain from a PEM file obtained by concatenating together certificate.pem and chain.pem.
Comment 2 kryss 2014-12-12 04:03:58 UTC
Created attachment 9042 [details]
Server output on Windows + .NET

The server machine certificate store was checked to make sure that none of the certificates in the PEM file were also in the store. None of them was found imported in the store either before or after server execution.
Comment 3 kryss 2014-12-12 04:05:19 UTC
Created attachment 9043 [details]
Server output on Linux (SLC6 - Fedora derivative) + Mono

This is the server output on a Linux SLC6 (Fedora derivative) with Mono 3.10.0 installed. I also tried Mono (extracted from GIT) - no change in the behaviour.
Comment 4 kryss 2014-12-12 04:07:04 UTC
Created attachment 9044 [details]
Output from openssl client

This is the output from openssl on the Linux SLC6 machine. I can't post the output from the Windows machine because the certificate was created for the Linux one and the two have different addresses. However it's clear the intermediate certificates are not sent by SslStream.
Comment 5 kryss 2014-12-12 04:13:03 UTC
The test case proposed, which is easy to compile and run, shows that SslStream.AuthenticateAsServer does not send the full certificate chain if it is imported from a PEM file.
No certificate stores are involved in this test.
Furthermore, the output of .NET and Mono in dumping X509Certificate2 (.ToString()) are different; in the output it is also clear that .NET can "Verify()" the certificate using only PEM info and Mono does not. I think the problem happens already at this stage, and the behaviour of SslStream.AuthenticateAsServer is only a consequence.

All personal/sensitive information in the output is replaced with the -----REMOVED----- string for obvious security/privacy reasons. However, any certificate chain will do for reproducing the bug. I tested with three certificates for three servers, all produced by certificate authorities (none self-signed) and the behaviour is identical.

Please notice this is becoming urgent because we can't have our embedded SSL server secure if running on Mono, and I know no workaround for that.
Comment 6 xambugz 2015-04-13 09:44:22 UTC
This bug is expected to go away when the .Net code is folded into mono (when? hopefully this year (2015)?). I've been in communication with mono devs to ensure new tests are created to ensure the problem goes away.

We were forced to ship product with a hacked version of mono that solves the problem. Binaries are here: https://downloads.conceptblossom.com/mono/

The mods were forked on github, but pull request not approved because it was too dirty/hacky, and hopefully soon going to be thrown out when the .Net code is folded in. So if you care, I can provide the modified source, but it's kind of pointless. Point is, there is a workaround if you need to use a mono SslStream server.

Note: the above hacked binaries work for a single intermediate. Don't work when the server has more than 1 intermediate.
Comment 7 kryss 2015-04-13 15:47:54 UTC
Thank you. Unfortunately a temporary hack can't do. Using Mono to implement our own webserver is a qualifying point in our application, which is entirely built to run on Mono without any external code.

What is the workaround using SslStream?
Comment 8 Guerry Semones 2016-08-16 15:07:01 UTC
Is there any status on this or is there an approximate roadmap date now when the ,NET code will be applied? This bug is blocking us from proceeding on a critical project.
Comment 9 xambugz 2016-08-16 22:25:25 UTC
In Aug 2015, Miguel wrote a blog post about it here:
In particular, you might make of the mono-tls module.

At one point, Miguel told me to follow progress here:
But I never could glean any meaningful information out of that - maybe I just don't know how to use trello effectively - or maybe they're not using it anymore. I don't know.

I thought I read somewhere recently, that the .NET TLS stack was now available in mono, including TLS 1.2, but I can't find that anywhere now. You might try simply using the very latest version and see if the problem has been fixed.

There's also a very good chance you'll find it's not a problem in .NET Core https://www.microsoft.com/net/core
I only recently discovered .NET Core. You can think of it as Microsoft's compiled version of the .NET open source code, runs cross-platform on Linux and OSX, you use the command "dotnet" to run an exe just like you would use "mono" to run it.
Comment 10 Guerry Semones 2016-08-17 17:26:50 UTC
@xambugz@nedharvey.com Hey, thanks for the info. I didn't know about the Trello board. It looks like Miguel is watching. He put an update on that Trello board today:


- We are now shipping AppleTLS as a backend on Mac, iOS and tvOS.
- Actively working on BoringTLS on desktop/Android
  - TLS handler is ready
  - Mostly dealing now with how to reuse root certificates from the system
  - And how to consume existing root certificates downloaded by the user"

I'm now looking to see how to enable AppleTLS since my problem is primarily on Mac.

I've also begun working on compiling on .NET Core, but if I can get Mono working....
Comment 11 Guerry Semones 2016-08-17 23:32:10 UTC
I learned a lot today. Thanks for the original pointer to the Trello board.

Setting an environment variable MONO_TLS_PROVIDER=newtls causes Mono to load the new TLS stack supporting 1.0+. This works great, in that you get the new implementation. I could only get this to work on .NET Framework 4.6+ (Mono 4.6+). I'm not real familiar with the naming conventions.

However, using the "newtls" resulted in a different bug for me which I found was reported back in April 2016: https://bugzilla.xamarin.com/show_bug.cgi?id=40381   In this case it crashes with a null pointer to which I have no access to fix (that I can determine yet). 

In my case, I am writing a Console App on Mac OS X (El Capitan) that self-hosts using OWIN/Katana and SignalR.


Comment 12 xambugz 2016-08-18 13:39:16 UTC
Please also see Miguel's TLS 1.2 Status Update, he sent out today: