Search code examples
springspring-bootssllets-encryptspring-cloud-config

SpringBoot - Reload SSL Cert using Spring Cloud Config


I'm learning about using SSL Certificates with Spring Boot. Specially using Let's Encrypt ones.

They have the limitation of being expired after 3 months, so they should be renewed and as far as I know, when renewing the certificate we need to restart the Spring Boot app in order to make it load the new one instead.

Some time ago, I was playing around with Eureka and Zuul Gateway, to develop microservices... And I recall I also set a git repo to be used as a Spring Cloud Config. I do not remember well, I think we can use Spring Cloud Config without using the microservice arch.

So my question is: Can we use this Spring Cloud Config mechanism that reload properties to reload the SSL Certificate? The idea would be to trigger the properties reloading mechanism, and as the ssl is configured via those properties, I think maybe it can be reloaded.

I'm planning on automating the process of getting and renewing the Let's Encrypt certificate and avoid the downtime on my app.

Best regards!


Solution

  • SSL certs are applied at the JVM level - neither Spring Boot nor Spring Cloud Config has any control over this, and so to apply a new cert would require a restart of the JVM instance your app runs in, because you've updated your keystore. Being able to dynamically add certs without shutting down the JVM would be a major security flaw.

    In the AWS ecosystem, the idea is that if you ever shut down your VM, you lose that VM, and the contents on it are gone forever. With Spring Cloud (Config, Zuul, Eureka) you can spin up VMs that get registered with Eureka via Config, and Zuul uses the info in Eureka to do the load balancing. So, the way it should be done is you spin up another VM with your Spring Boot instance with the updated cert, and kill off the older VM which evaporates thanks to AWS, and Zuul takes care of the dirty work of being a "reverse web proxy", routing the requests to the new web server as required.

    The can of worms you open going this route is that now you have to implement 4 servers and a VPN to support them, your Zuul server becomes the target of external web requests, and you might need to look into the "circuit breaker" pattern on how to handle HTTP request failures - Hystrix is the next thing to look into.

    With Digital Ocean, I'm not sure what you might have to do differently, but a JVM restart is unavoidable.