Possible way to refresh Java Keystore without restart spring boot context?

[ghost]

Let's Encrypt is a new Certificate Authority, which provides free certificates and encourage automation for certificate renewal, etc. I think that would be great to embed a ACME client inside a spring boot web mvc application.

There are still many problem to solve, one problem would be the way to refresh the keystore. Even the Keystore file is updated, the keystore would not be refresh. I have explored many ways to reload the keystore, include writing my own Keystore class(I called it hacks and I think not secure to DIY), but none can successfully refresh the keystore. The only way I found out is to stop and recreate context as following:

@SpringBootApplication
@EnableWebMvc
@EnableScheduling
public class WebPortfolioFullBootApplication{

    private static ConfigurableApplicationContext context = null;

    private static String[] args;

    public static void main(String[] args) {
        WebPortfolioFullBootApplication.args = args;
        context = SpringApplication.run(WebPortfolioFullBootApplication.class, args);
    }

    public static int restart(){
        int exitCode = SpringApplication.exit(context);

        if (exitCode == 0) {
            context = SpringApplication.run(WebPortfolioFullBootApplication.class, args);
        }

        return exitCode;
    }
}

And having a schedule job to check if the key store file is updated. If the file is updated, then call the WebPortfolioFullBootApplication.restart() to recreate context. First, it is not the best piece of code I have seen/written. Secondly the recreation as such may break something I may not know. Lastly, it actually shutdown the server which introduce down time.

As stated, would there be a elegant and safe (secure) way to refresh the keystore?

Edit:
The running environment.

Spring Boot 1.3.3.RELEASE
Spring Boot Starter Undertow

[wilkinsona]

I think this falls outside of the scope of Spring Boot. There's no way for Boot to know how and where the keystore is being used, so there's no way for it to figure out what needs to be refreshed (even assuming that it's possible to do so).

Faced with this problem, I think I'd take a different approach. As you are concerned about downtime, I presume that you run multiple instances of your application? If so, I'd consider performing a rolling redeployment of the application whenever a new certificate becomes available.

[Hakky54]

Hi @wilkinsona This issue is pretty old and already closed, however some time ago I discovered a way to update the ssl configuration of a spring-boot server at runtime, so without restarting it. I am using this setup on my projects and it is working fine so I thought it would be good the share it with you. Not quite sure whether it would be usefull for you, but maybe handy if you are curious or thinking about adding similar feature to spring, see here for a basic demo:
Spring Boot - Instant SSL Reloading

The basic demo can update ssl configuration from:

1. An endpoint/controller
2. The filesystem, listens on changes of the keystores
3. The database, listens on changes made on the database

What do you think of it?

[Hakky54]

Hi @philwebb Do you have any updates regarding this issue? Is there anything what I can do from my side? I can provide a PR for the Netty, Jetty and Undertow based embedded server in such a way that the enduser can just enable it with the properties in their aplication.yaml file

[wilkinsona]

Unfortunately we're focused on Boot 3.0 at the moment. We'll revisit this when we're considering changes for Boot 3.1. Generally speaking we believe that this is better handled at the orchestration level rather than at the application instance level.

[loganmzz]

I think this falls outside of the scope of Spring Boot. There's no way for Boot to know how and where the keystore is being used, so there's no way for it to figure out what needs to be refreshed (even assuming that it's possible to do so).

As Spring Boot is "wrapping" and "managing" HTTP server components (including HTTPS transport setup), it seems reasonnable to offer some primitives to access such underlying which should help on this concern. Most "standalone" HTTP server (Nginx, Haproxy, Traefik) offers primitives to reload their certificates from disk.

May a study may be made about each supported HTTP "engine" and find if they may provide such feature, and expose (at least at bean level: AutoConfiguration*, any wrapper, etc.) some optional APIs ? WDYT ?