Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Reload certificate configuration at runtime #1799
Recent Jetty releases have allowed us to reload ssl/tls information at runtime, so it's no longer necessary to restart Dropwizard to install a new certificate. More information can be found: eclipse/jetty.project#918
The motivation behind this PR is that as certificate management starts to be more automatic (looking at Let's Encrypt) and certificates are issues more frequently, the downtime caused by new certificates starts to become palpable. Yes, the service may only be down for a few moments, but any reductions in downtime should be welcomed.
Those who use a TLS termination proxy in front of dropwizard (or use http endpoints) will not be affected.
I implemented a quick check to ensure it's working
I can confirm that the certificate was indeed changed without needing a restart.
I marked this PR as RFC (request for comments) to get a feel of opinions. This PR is not ready to be merged.
I think it's a very good improvement to Dropwizard from the operational side!
I think we could use a new module for that. This will allows users to disable this feature, if they don't want to expose the ability to change SSL certificates on the fly.
We now support POST requests for admin tasks, so it's doable to use this approach. I like it, because
Looks good to me. We use Jetty's lifecycle in other bundles and it works well. I think we can use it,
I think we should try to provide an atomic way to update all configurations with new certificates. I think it would be a nightmare to debug a server with a partially updated configuration.
Ok I'll cave to adding the submodule. My initial plan was not to add a submodule because many dropwizard submodules that users have to manually import have additional third party dependencies,
On atomic updates. Good point. It's entirely plausible that the keystore could have been swapped out for one with a different password, causing the reload to fail. A failure to reload is tragic. No future connections are allowed (I tested this). Like you alluded to, it's a scary thought to hot reload a certificate and break all functionality.
But on one hand, if the app was restarted, it would break as well. The app wouldn't start. If we could fallback to the previous configuration we could keep the app chugging along, but at the cost it failing at the next restart. It's debatably a reasonable response. A 500 status code could inform the admin to examine the new certificate information before the next reboot that would force usage of the new certificate.
EDIT: This post was me thinking about loud, no need to respond to anything
This is cool. Thanks, @nickbabcock!
I agree with @jplock. Including the feature in
In order to help avoid the case where an invalid cert silently fails upon hot reload, perhaps we could add an
Anybody have opinions on the
Is it awkward that I put the code in
Also looks like coveralls doesn't do cross module code coverage, so my tests in