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!
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.
--
Viktor.
