Could this be dealt with by the simple removal of any caching layer between an SSL_CTX and a directory processed by openssl c_rehash? Would reading the filesystem on every certificate verification be too heavy for your use case?
On Sun, Aug 30, 2020 at 7:20 PM Jordan Brown <open...@jordan.maileater.net> wrote: > > 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
