At present, the private key and certificate for TLS must be provided once at startup of the server. Short-lived certificates are becoming increasingly common; Let's Encrypt certificates are valid for 90 days, but it is recommended to renew them more often than that (e.g., every 30-60 days) to avoid issues around the expiry period.
Certificates also need to be re-issued if more alternative names are added to a non-wildcard certificate.
It would be good if dropshot::HttpServer provided a routine for installing new certificates, probably by passing a new dropshot::ConfigTls. (see #490 for why it should not just be a pair of PathBuf arguments.)
At present, the private key and certificate for TLS must be provided once at startup of the server. Short-lived certificates are becoming increasingly common; Let's Encrypt certificates are valid for 90 days, but it is recommended to renew them more often than that (e.g., every 30-60 days) to avoid issues around the expiry period.
Certificates also need to be re-issued if more alternative names are added to a non-wildcard certificate.
It would be good if
dropshot::HttpServerprovided a routine for installing new certificates, probably by passing a newdropshot::ConfigTls. (see #490 for why it should not just be a pair ofPathBufarguments.)