New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support reloading certificates #505

Closed
richardalow opened this Issue Jun 20, 2018 · 3 comments

Comments

Projects
None yet
6 participants
@richardalow
Copy link
Member

richardalow commented Jun 20, 2018

It's good security practice to regularly roll certificates. Currently, the process (client or server) would need to restart to pick up the new certificate. It would be a lot better to watch the files and reload them if appropriate.

We should take care to not fail if the certificate and key files are not updated at exactly the same time, as they likely won't be.

@hgray1 hgray1 added this to the 6.0 milestone Jun 25, 2018

@satherton

This comment has been minimized.

Copy link
Contributor

satherton commented Jun 25, 2018

If we go with a polling approach, it would probably be best to create a new TLS Policy object only if the content actually changed.

@thoughtpolice

This comment has been minimized.

Copy link

thoughtpolice commented Jul 19, 2018

FWIW, the way Nginx handles this is that if a the main process is sent SIGHUP, then certificates/configuration are reloaded from disk and are used in new connections -- provided they're valid; otherwise, the prior certificates remain. Nginx actually replaces the worker processes with new ones if the configurations change, and let the old ones die gracefully once they've finished. (In this case if you only want SSL certificates, you probably don't need to even kill any fdbserver processes or anything, just tell them all to reload.)

Generally, on Linux, this is pretty easy to setup using systemd, since you can have systemctl reload foundationdb.service send SIGHUP (or whatever signal you want) to the main process, which can kick off this process.

Then, any automated renewal script, or manual administration, can do it atomically when they know the certificates are valid. This is how most letsencrypt.org/nginx integrations work, for example; they trigger the init system to send a reload signal once every 30-60 days (to comfortably avoid the 90 day window)

@alexmiller-apple

This comment has been minimized.

Copy link
Contributor

alexmiller-apple commented Jul 23, 2018

Note that I agree with you, but unfortunately, it is not what I was tasked to implement.

There's maybe some ease of use in that we'll just reload certificates whenever they validate, and you don't have to rig up any SIGHUP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment