There are two issues that come to mind with the current way we approach loading of certificates (and eventual* generation of self-signed certificates) and config files.

1. On the first run, when we generate the self-signed certificate, we block the incoming connection for a long time.  This might give a new user of cockpit a bad impression.
2. We made a design decision to avoid inotify for reloading certificates and config files on the basis that these actions should only be performed by explicit admin action after the admin is finished editing the files, but for the case where cockpit-tls isn't running during an editing session, and a connection randomly comes in, the file will be used in the state that it's found at the time of that incoming connection.  Ditto certificates, which may be in the middle of being updated by ACME, certmonger or similar.

We already have a couple of ExecStartPost lines in cockpit.socket to deal with setting up motd.  We might imagine to read the configuration file and certificates at that point as well (generating the self-signed certificate as appropriate).  This would also give us an opportunity to rewrite the motd-generating code in C, which would help us avoid some shell shenanigans that we've employed to keep things "efficient".

As a draw-back, it would lead to increased resource usage on the first start of the system, to generate a self-signed certificate that may never end up being used.  I don't consider this to be a significant problem: these resources would be used anyway as soon as someone did something as innocent as a nmap of the machine in question.

There might also be some confusion from admins who think that they can reload the config file by restarting cockpit.service, which would stop being the case.  It's also not clear if it's possible to implement the reload verb on a socket unit in any meaningful way.

We'd also need to figure out a way to ensure that we still manage to regenerate self-signed certificates on systems with long uptimes.  This is actually a problem that we already have for long-running cockpit-tls instances, but we can ignore it because we sort of assume that the service will exit at some point during the 30 days grace period.

This topic definitely needs some discussion before we implement it, if we decide to implement it at all.

(* I live in Europe now, so I'm allowed to do this.)