[Mono-dev] Sync of mono Cert Store

Fri Jul 28 15:18:19 UTC 2017

Has anyone done any work on mapping the mono certificate store (X509store?)
to the system store, so it could be shared, as in Windows and OSX?

Thanks,
Rick

On Tue, Jul 18, 2017 at 2:53 PM, Rick Tillery <rtillerywork at gmail.com>
wrote:

> Two items:
>
> 1.  It does not appear that FileSystemWatcher detects a file read, at
> least on CentOS 7.  If so, that would seem to kill option #5 below, which
> was meant to detect when the user executed the update-ca-trust command to
> trigger cert-sync.
>
> 2.  In looking around, I find that the Mac implementation actually uses
> the Apple TLS stack, which in turn uses the Apple certificate store, so
> there are no sync issues.  (I'm sure you all knew this, but it was news to
> me.)  That's very nice for them, and I'd hate to spend a lot of time on
> this if there was a similar solution cooking for Linux.  I do see a number
> of comments on work on different TLS implementations, but I haven't really
> seen anything that addresses the independent certificate stores.  Is there
> work being done on mapping the mono .Net certificate store to the system
> certificate store, so that whichever TLS implementation is used, there will
> be only one store?
>
> Thanks,
> Rick
>
>
> On Mon, Jul 17, 2017 at 10:39 AM, Rick Tillery <rtillerywork at gmail.com>
> wrote:
>
>> Just FYI, I don't see anything in the CentOS packaging to keep the mono
>> cert store sync'd with the system cert store after the initial sync during
>> install.
>>
>> The method used by Debian appears to be use of a feature included with
>> the system's update-ca-certificates script, causing additional scripts
>> added to /etc/ca-certificates/update.d/ to be executed after a certificate
>> update. However, the update-ca-trust script, which seems to be the
>> equivalent in CentOS/RHEL(/Fedora?), does not have a similar design.
>>
>> We're considering a couple of approaches, and if the chosen method is not
>> specific to our project, and if there is interest, I'd like to share it
>> here for potential inclusion with the mono rpm package.
>>
>> With that in mind, I thought I could share some options and ask the
>> experts here for any advice or comments:
>>
>> 1. cron job to call cert-sync
>> 2. use systemd.path (el7) and inotifywait (<el7) to monitor for writes to
>> /etc/pki/tls/certs/ca-bundle.crt
>> 3. use systemd.path (el7) and inotifywait (<el7) to monitor for reads
>> from /usr/bin/update-ca-trust
>> 4. use FileSystemWatcher to monitor for writes to
>> /etc/pki/tls/certs/ca-bundle.crt
>> 5. use FileSystemWatcher to monitor for reads
>> from /usr/bin/update-ca-trust
>>
>> In all cases, /etc/pki/tls/certs/ca-bundle.crt timestamp would be
>> checked against the last sync date (either explicitly stored or by
>> referencing the timestamps in /use/share/.mono/certs) before calling
>> cert-sync, to cut down on unnecessary syncs.
>>
>> Clearly #1 is not a great idea (blindly, continuously polling for a very
>> rare occurrence).
>>
>> For <el7, #2 & #3 require installation of the inotify-tools package.
>> This is in the epel repository, but this repo is not enabled by default,
>> and we are reluctant to force our customers to enable this.  Alternatively,
>> we could include the inotify tools in our package, but this will require
>> extra research and testing to ensure that what is included doesn't have
>> other dependencies in alternative repos or have compatibility issues with
>> certain versions of CentOS/RHEL.
>>
>> Additionally, monitoring /etc/pki/tls/certs/ca-bundle.crt seems like it
>> could be a problem, as this is a symlink and might change going forward.
>> OTOH, the installation of mono-core uses this specific path for the initial
>> sync, meaning a change here would already affect mono cert store syncing.
>>
>> So at this point, we're considering option #5 vs a product-specific
>> approach (syncing before each call back to our server), assuming
>> FileSystemWatcher will work for both CentOS/RHEL 7 and CentOS/RHEL 6.
>>
>> Does anyone have any thoughts on this?
>>
>> Rick
>>
>> On Jul 13, 2017 7:01 PM, "Rick Tillery" <rtillerywork at gmail.com> wrote:
>>
>>> Fantastic! I don't see that in the RPM, but I'll take a look.
>>>
>>> Thanks again!
>>> Rick
>>>
>>> On Jul 13, 2017 6:18 PM, "Alexander Köplinger" <alkpli at microsoft.com>
>>> wrote:
>>>
>>>> When Mono is installed from our packages (specifically the
>>>> ca-certificates-mono package*), we're adding a hook
>>>> into /etc/ca-certificates/update.d/ which runs cert-sync automatically
>>>> whenever the system certificates are updated by the update-ca-certificates
>>>> command.
>>>> This is the same approach that Java is taking as far as I know, so it
>>>> should "just work" out of the box :)
>>>>
>>>> I guess you could do something similar for your bundled Mono.
>>>>
>>>> - Alex
>>>>
>>>> * at least that's how it works on Debian et.al., I'm not really
>>>> familiar with how we're doing it on RPM distros
>>>>
>>>> On 14 Jul 2017, at 00:13, Rick Tillery <rtillerywork at gmail.com> wrote:
>>>>
>>>> Thanks, Dave. Yes, that's how our install syncs in the first place.
>>>>
>>>> The thing is that customers would need to know to run this on their
>>>> machines in addition to modifying the system cert store.  (Plus, it's a bit
>>>> more complicated & nonstandard because we have a bundled mono, while
>>>> they're may not even be any system mono installed.)
>>>>
>>>> I'm willing to create a method to automatically update the mono cert
>>>> store when the system cert store changes, but I want to understand whether
>>>> there is a different expectation about how cert updates are done & if there
>>>> are issues to consider with such a tool.
>>>>
>>>> Rick
>>>>
>>>> On Jul 13, 2017 5:04 PM, "David Curylo" <curylod at asme.org> wrote:
>>>>
>>>> Rick,
>>>>
>>>> You can run `cert-sync` at any time to synchronize new certs with your
>>>> mono cert store.
>>>>
>>>> -Dave
>>>>
>>>> > On Jul 13, 2017, at 6:01 PM, Rick Tillery <rtillerywork at gmail.com>
>>>> wrote:
>>>> >
>>>> > As a follow-up my previous question (thanks Alex), we have a concern
>>>> about changes to the system certificate store & synchronization with the
>>>> mono cert store.
>>>> >
>>>> > I see that the system cert store is imported to mono on install (& we
>>>> now do this as well in our install), but what is the expected approach to
>>>> keeping the mono cert store updated? For example, if a certificate needs to
>>>> be added or revoked, is it expected that the admin knows that the mono cert
>>>> store needs to be manually updated too (and doesn't Java have a separate
>>>> cert store too, meaning that must be manually dealt with as well?)?
>>>> >
>>>> > (I didn't find there proper search terms with Google to show me much
>>>> about this.)
>>>> >
>>>> > Is there a reason not to create a method of syncing these, so changes
>>>> to the system cert store automatically get copied into the mono cert store?
>>>> Is there an accepted (safe) method of doing this?
>>>> >
>>>> > Rick
>>>> > _______________________________________________
>>>> > Mono-devel-list mailing list
>>>> > Mono-devel-list at lists.dot.net
>>>> > http://lists.dot.net/mailman/listinfo/mono-devel-list
>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.dot.net%2Fmailman%2Flistinfo%2Fmono-devel-list&data=02%7C01%7Calkpli%40microsoft.com%7Ce25377d6f7f04f432e3708d4ca3c667a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636355808162250712&sdata=pT9S5%2FDYxUHMMbfUOv1UX%2BzuIxHYt8JRNdyMTDtQZTM%3D&reserved=0>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mono-devel-list mailing list
>>>> Mono-devel-list at lists.dot.net
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2
>>>> F%2Flists.dot.net%2Fmailman%2Flistinfo%2Fmono-devel-list&dat
>>>> a=02%7C01%7Calkpli%40microsoft.com%7Ce25377d6f7f04f432e3708d
>>>> 4ca3c667a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63635
>>>> 5808162250712&sdata=pT9S5%2FDYxUHMMbfUOv1UX%2BzuIxHYt8JRNdyM
>>>> TDtQZTM%3D&reserved=0
>>>>
>>>>
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/mono-devel-list/attachments/20170728/d7fc7810/attachment.html>