Cert hot-reloading

[Jakob Bohm]

On 2020-09-01 01:52, Viktor Dukhovni wrote:
> On Sun, Aug 30, 2020 at 07:54:34PM -0500, Kyle Hamilton wrote:
>
>> I'm not sure I can follow the "in all cases it's important to keep 
>> the key
>> and cert in the same file" argument, particularly in line with openat()
>> usage on the cert file after privilege to open the key file has been
>> dropped. I agree that key/cert staleness is important to address in some
>> manner, but I don't think it's necessarily appropriate here.
> Well, the OP had in mind very frequent certificate chain rollover, where
> presumably, in at least some deployments also the key would roll over
> frequently along with the cert.
>
> If the form of the key/cert rollover is to place new keys and certs into
> files, then *atomicity* of these updates becomes important, so that
> applications loading a new key+chain pair see a matching key and
> certificate and not some cert unrelated to the key.
>
> This, e.g., Postfix now supports loading both the key and the cert
> directly from the same open file, reading both sequentially, without
> racing atomic file replacements when reopening the file separately
> to reach keys and certs.
>
> If we're going to automate things more, and exercise them with much
> higher frequency. The automation needs to be robust!
Another synchronization method would be for the application to decree a
specific order of changing the two files, such that triggering reload on
the second file would correctly load the matching contents of the other.

If a future OpenSSL version includes an option to detect such change,
documentation as to which file it watches for changes would guide
applications in choosing which order to specify for changing the files.


> Note that nothing prevents applications that have separate configuration
> for the key and cert locations from opening the same file twice. If
> they're using the normal OpenSSL PEM read key/cert routines, the key
> is ignored when reading certs and the certs are ignored when reading
> the key.
>
> Therefore, the single-file model is unconditionally superior in this
> context. Yes, some tools (e.g. certbot), don't yet do the right
> thing and atomically update a single file with both the key and the
> obtained certs. This problem can be solved. We're talking about
> new capabilities here, and don't need to adhere to outdated process
> models.
>
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.



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded