Bug 3966 - Mono.Security.X509.X509StoreManager doesn't pick up changes to the store after first access
Summary: Mono.Security.X509.X509StoreManager doesn't pick up changes to the store afte...
Status: RESOLVED NORESPONSE
Alias: None
Product: Class Libraries
Classification: Mono
Component: Mono.Security ()
Version: master
Hardware: PC Linux
: --- normal
Target Milestone: Untriaged
Assignee: Sebastien Pouliot
URL:
Depends on:
Blocks:
 
Reported: 2012-03-19 10:14 UTC by David Ferguson
Modified: 2018-03-13 11:07 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Unit tests for testing both the Mono specific store and the System.Security store (5.19 KB, text/x-csharp)
2012-03-19 10:14 UTC, David Ferguson
Details
Proposed patch that modifies the System X509Store and the Mono.Security X509Store (8.93 KB, patch)
2012-03-19 10:15 UTC, David Ferguson
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:
RESOLVED NORESPONSE

Description David Ferguson 2012-03-19 10:14:01 UTC
Created attachment 1536 [details]
Unit tests for testing both the Mono specific store and the System.Security store

The Mono certificate store is creates static lists when the store is first accessed.  Any certificates added after the initial read does not get returned by the X509StoreManager.  This became an issue when working with client certificate authentication with the HttpListener.  Since the SslServerStream (it uses static properties on the Mono.Security X509StoreManager) was not picking up the newly added certificate, the certificate request would never result with the proper client certificate being picked up during the SSL v3 handshake until the application was restarted.

Similarly, the System.Security.Cryptography.X509Certificates.X509Store will not pick up changes while it is open.  I confirmed on windows that .NET 4.0 runtime will pick up changes to the store while it is open.

The attached patch fixes these problems and brings the behavior in line with the Windows implementation.  Also attached are two unit tests that fail with Mono 2.10.5 but pass on Master with the attached patch in place.  Rather than simply reload the certificates on each access, the patch scans the store's files to determine if there has been an update/deletion/addition and rebuilds its collections.  The System X509Store has to rebuild the X509Certificate2 object each time on access since the Mono.Security dll cannot have a reference to X509Certificate2 with the current dependency scheme.
Comment 1 David Ferguson 2012-03-19 10:15:09 UTC
Created attachment 1537 [details]
Proposed patch that modifies the System X509Store and the Mono.Security X509Store
Comment 2 Sebastien Pouliot 2012-03-23 13:38:06 UTC
Comment on attachment 1537 [details]
Proposed patch that modifies the System X509Store and the Mono.Security X509Store

-			string path = Path.Combine (_storePath, storeName);
-			if (!CheckStore (path, false))
+			if (!CheckStore (_storePath, false))

^ the use of the storeName is removed everywhere. How are they differentiated ?
Comment 3 David Ferguson 2012-03-23 15:01:24 UTC
The _name variable is populated from the _storePath variable.  The extra step to get the path by doing a combine would end up returning _storePath.  The _storePath variable will have the full path to the store, including the name of the store.

When calling BuildCertificatesCollection in the Certificates property, storePath is used as the storeName parameter. 

_certificates = BuildCertificatesCollection (_storePath);

In looking at BuildCertificatesCollection, the parameter is the store name.  So, if you have a path to your cert store as ~/.config/.mono/certs/Trust, you'll end up running the equivalent of Path.Combine("~/.config/.mono/certs/Trust", "~/.config/.mono/certs/Trust") which will return "~/.config/.mono/certs/Trust".

private X509CertificateCollection BuildCertificatesCollection (string storeName) 
		{
			X509CertificateCollection coll = new X509CertificateCollection ();
			string path = Path.Combine (_storePath, storeName);
			if (!CheckStore (path, false))
				return coll;	// empty collection

From that standpoint, it is just extra code that doesn't need to run.
Comment 4 Sebastien Pouliot 2012-03-23 15:12:44 UTC
Good catch, that was not the original intent but I guess it evolved that way (I suspect a cosmic ray ;-)
Comment 5 Sebastien Pouliot 2012-03-26 14:49:12 UTC
TrustedStoreUpdate_Test fails for me when executed on MS .NET 4.0. 

			Assert.IsTrue (found);

I will need to validate that the Windows store really works this way before pushing the fix.
Comment 6 Marek Safar 2018-03-13 11:07:19 UTC
We have not received the requested information. If you are still experiencing this issue please provide all the requested information and reopen the bug report.

Thank you!