Cert hot-reloading

[Viktor Dukhovni]

> On Aug 31, 2020, at 10:57 PM, Jakob Bohm via openssl-users <openssl-users at openssl.org> wrote:
> 
> Given the practical imposibility of managing atomic changes to a single
> POSIX file of variable-length data, it will often be more practical to
> create a complete replacement file, then replace the filename with the
> "mv -f" command or rename(3) function.  This would obviously only work
> if the directory remains accessible to the application, after it drops
> privileges and/or enters a chroot jail, as will already be the case
> for hashed certificate/crl directories.

There is no such "impossibility", indeed that's what the rename(2) system
call is for.  It atomically replaces files.  Note that mv(1) can hide
non-atomic copies across file-system boundaries and should be used with
care.

And this is why I mentioned retaining an open directory handle, openat(2),
...

There's room here to design a robust process, if one is willing to impose
reasonable constraints on the external agents that orchestrate new cert
chains.

As for updating two files in a particular order, and reacting only to
changes in the one that's updated second, this behaves poorly when
updates are racing an application cold start.  The single file approach,
by being more restrictive, is in fact more robust in ways that are not
easy to emulate with multiple files.

If someone implements a robust design with multiple files, great.  I for
one don't know of an in principle decent way to do that without various
races, other than somewhat kludgey retry loops in the application (or
library) when it finds a mismatch between the cert and the key.

-- 
	Viktor.