Cert hot-reloading

[Jordan Brown]

Well, I can restate the problem that I encountered.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200831/31f2576b/attachment-0001.html>