We deliver an integrated storage system. Under the covers it is a modified Solaris running a usual collection of proprietary and open-source components. We supply an administrative user interface that, among many other things, lets you manage a list of "trusted" certificates - typically CA certificates that a program would use to authenticate its peers. That is, it's the equivalent of Firefox's Tools / Options / Privacy & Security / Certificates / View Certificates, and the "Servers" and "Authorities" tabs there, with the additional tidbit that for each certificate you can control which services (e.g. LDAP, et cetera) that certificate is trusted for.
When an administrator makes a change to the trusted-certificates list, we want that change to take effect, system-wide.
The problem is that that means that some number of processes with active OpenSSL contexts need to drop those contexts and recreate them, and we don't know which processes those are. Client operations are typically driven through a library, not a separate daemon, and so there's no centralized way to know which processes might be TLS clients. In addition, there's the question of how to *tell* the process to recreate the context. Simply restarting them may involve disruption of various sorts.
What we'd like would be for OpenSSL to, on every authentication, stat the file or directory involved, and if it's changed then wipe the in-memory cache.
Yes, aspects of this are system-specific, but that's true of many things. There could easily be an internal API that captures a current-stage object, and another that answers "is this still the same". The default implementation could always say "yes".
-- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris
