Support for re-reading TLS keys and certificates without restart

[jhujhiti]

I would like to use RTR-over-TLS between Routinator and RTRTR. In my environment, this means frequent, automatic certificate reissuance. Are there any plans to support hitlessly reloading certificates in Routinator? I think responding to SIGHUP/SIGUSR1/SIGUSR2 make the most sense for this use case. I see that #200 is considering reloading configuration and restarting validation, but this is a slightly different case: it doesn't require re-reading the configuration file itself, and I do not want to restart validation on such a certificate reissue event.

Obviously, I can restart the process when the certificate has been rolled, but this makes Routinator unavailable for a time while it performs its initial validation. Some way to handle only the TLS certificate changes hitlessly would be fantastic.

[partim]

Apologies for the late response. I missed the issue after returning from vacation.

We currently re-load the TALs at SIGUSR1 which, given that most TALs are now bundled, doesn’t make all that much sense any more. But we could expand it to also reload other things such as the TLS keys.

This would trigger a validation run but I don’t think that really is a problem?

[partim]

On further reflection, we have #200, i.e., reload configuration at a SIGHUP. This would also restart all the listener, so would cover the case.

[jhujhiti]

Retriggering validation seems unnecessarily heavy, but doing this during a configuration reload makes sense.

Maybe this is better discussed in the other issue, but hopefully restarting the listener will not drop active connections if nothing else about the listener has changed (or nothing at all, if no new certificate were provided...)? This certificate is of course validated at the beginning of a connection, so ideally existing clients would see no interruption at all during the SIGHUP. (Again, unless the configuration change itself demanded it.)