regenerate_tls_cert() passed -keyout /etc/archipelago/ssl/archipelago.key
and -out .../archipelago.crt, so openssl wrote straight into the files nginx
is serving from. If openssl died partway, was killed, or the disk filled,
the live key and cert were already truncated — a routine `server.set-name`
could take HTTPS down with no way back. Reproduced: the live key goes from a
valid 2048-bit PEM to 33 unparseable bytes.
Mirror the discipline gen_tls() already uses in the ISO builder: generate
into .new siblings of the destinations (same directory, so the final mv is a
rename(2) and therefore atomic), parse both halves back with `openssl pkey`
and `openssl x509` and compare the extracted public keys to prove they are
valid and belong together, and only then swap them in. On any failure the
existing key and cert are left byte-for-byte untouched and the error is
returned. Staging files are cleared before the attempt and on every exit
path, success or failure.
Permissions: the staging key is created by `install -m` carrying the live
key's own mode and owner *before* openssl writes into it (openssl truncates
an existing -keyout file rather than recreating it), so the new private key
is never group- or world-readable, not even between generation and a chmod.
A live mode that grants group/other any access is not reproduced — the key
falls back to 0600 — so the swap can never widen permissions.
Cert content and parameters are unchanged: same subject, same SAN
construction, same rsa:2048, same 3650 days. This is an atomicity and
validation fix, not a crypto change.
Testing seam: the hardcoded sudo prefix and absolute paths made this
untestable, so the logic moved into a small TlsMaterial struct holding the
ssl dir, the openssl binary path and a privileged flag. Production is
TlsMaterial::production(); tests point it at a temp dir, drop sudo, and
substitute a stub openssl. Against the pre-fix shape the two atomicity tests
fail (live key modified; garbage accepted); against this change all five
pass.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
