[Mono-dev] Sync of mono Cert Store

Rick Tillery rtillerywork at gmail.com
Mon Jul 17 15:39:44 UTC 2017

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

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
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
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?


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/20170717/a242b255/attachment.html>

More information about the Mono-devel-list mailing list