I have a Netty-based server that uses PEM-encoded certificate files that are periodically re-issued (by Let‘s Encrypt). Netty fully supports loading the PEM crypto material, but when the certificate (.cer file) is later re-issued, the server needs to be restarted to see it.
I have handled this up until now by adding a custom channel init handler to add the logic to reload the cert and add an appropriate SSLHandler built from that. But now I‘m wanting to use Aleph, and it expects a Netty SSLContext object for TLS.
This seems like a topical and general problem with the growing popularity of Let‘s Encrypt and its relatively short-lived certs, and I‘d like to solve it properly. Which means a Netty-compatible way to create an SSLContext that will reload its certificate(s) if they change on disk.
Some approaches I‘ve come up with:
-
Make a dynamic trust manager/trust store, then plug that into the Netty SSLContextBuilder. Could use this is a starting point https://jcalcote.wordpress.com/2010/06/22/managing-a-dynamic-java-trust-store/, and take some of the code to load the key/cert from Programmatically Obtain KeyStore from PEM (Netty’s PEM -> KeyStore logic is not public in the SSLContext class). Upside: works outside Netty too. Downside: complicated and doesn’t reuse Netty’s existing logic to load PEM keys and certs.
-
Add this as a Netty-supported option.
Can anyone point me to a solution, or suggest the best way forward to building one?
Answering my own question.
The answer is: don‘t do it at this level. Instead, have something outside the Netty stack monitor the cert, and when the cert changes remove the existing SSL handler from the pipeline and replace it with a new one with a SSLContext created from the new cert.
-
Yea I have this issue, I am sure as many others. Its a PITA on the java side as it is. Although I found this way back and it may allow bypassing of the keystore. netty.io/wiki/forked-tomcat-native.html – Mr00Anderson Mar 8 at 18:33