<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Well, I can restate the problem that I encountered.<br>
<br>
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.<br>
<br>
When an administrator makes a change to the trusted-certificates
list, we want that change to take effect, system-wide.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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".<br>
<pre class="moz-signature" cols="72">--
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris</pre>
</body>
</html>