java-tutorials VS SSLContext-Kickstart

Hi, I have been working on a small library to make hot reloading of a ssl configuration for a server and http client possible. I was just curious why we needed to restart the server or recreate a http client with new ssl configuration when the keystores needed to be updated. I wanted to learn how the ssl configuration is handled in java and was just curious if I could be able to bypass this limitation and reload the ssl configuration instantly. An alternative would be to use nginx as a proxy with ssl configuration for a server setup, but I was a bit bored and wanted to achieve this just in java. In the above demo I demonstrate a spring boot with embedded jetty server, however similar behaviour is possible with akka or other servers which use SSLContext, SSLSocketFactory, SSLEngine, TrustManager or KeyManager. The server has an initial ssl configuration and it will get updated by an admin application from the terminal through an https request, but it can also use a file listener to update it. If the keystores on the filesystem get replaced or updated it can also pick that up or fetch it from a database based on a trigger or something else. The demo can be found here https://github.com/Hakky54/java-tutorials/tree/main/instant-server-ssl-reloading I use my own library to have this setup working, which is available here: https://github.com/Hakky54/sslcontext-kickstart

The example project is here: GitHub - Instant server ssl reloading

Thank you u/darri I am glad to hear you are also ok with the name. And regarding the support for modules I created an issue so you can keep track of the changes: https://github.com/Hakky54/sslcontext-kickstart/issues/332 This will be indeed a major version.

Yess, but this tool is a CLI app made from java. If you want to do it within your own java application, you can import the following library: GitHub - sslcontext-kickstart. Here is the documentation for extracting the certificates programatically: https://github.com/Hakky54/sslcontext-kickstart#extracting-server-certificates

I am a maintainer/owner of an opensource library related to security and today someone on GitHub asked me whether it would be possible to make it FIPS 140-2 compliant. I was not sure how to react, sure I would love to put some effort to make it compliant by getting it tested and having a certification for it so U.S. and Canadian developers can use it easier for their projects, however I discovered that it can cost $10.000 which is in my opinion a bit too much for an opensource library maintained by myself for free and anyone can use it for free. I don't earn anything from it, I just love writing software and try to make my life easier with creating some libraries and reusing it and sharing it with the community so they can also benefit of it. I would be happy if U.S and Canadian developers could more easily use my library, but is there an alternative? Can't they just use it as is or is there a different path for small opensource projects?

Hi, I have been working on a small library to make hot reloading of a ssl configuration for a server and http client possible. I was just curious why we needed to restart the server or recreate a http client with new ssl configuration when the keystores needed to be updated. I wanted to learn how the ssl configuration is handled in java and was just curious if I could be able to bypass this limitation and reload the ssl configuration instantly. An alternative would be to use nginx as a proxy with ssl configuration for a server setup, but I was a bit bored and wanted to achieve this just in java. In the above demo I demonstrate a spring boot with embedded jetty server, however similar behaviour is possible with akka or other servers which use SSLContext, SSLSocketFactory, SSLEngine, TrustManager or KeyManager. The server has an initial ssl configuration and it will get updated by an admin application from the terminal through an https request, but it can also use a file listener to update it. If the keystores on the filesystem get replaced or updated it can also pick that up or fetch it from a database based on a trigger or something else. The demo can be found here https://github.com/Hakky54/java-tutorials/tree/main/instant-server-ssl-reloading I use my own library to have this setup working, which is available here: https://github.com/Hakky54/sslcontext-kickstart

It uses my own library: GitHub - SSLContext Kickstart

Ah, yes that is a nice way to get the root certificate. But it looks like this method will only work when the server is also including the root ca right? Maybe I am overseeing something. I just found a different method, see here for a WIP implementation: https://github.com/Hakky54/sslcontext-kickstart/pull/83/files Maybe you can share your opinion regarding this solution?

I wanted to help myself out from the verbosity make my life easier. One library to configure them all! It should be painless to use, easy to test and debug, and fun to set-it-up. The project is available at GitHub - SSLContext-Kickstart

I also want to provide some context to make this question more clear. I created sslcontext-kickstart which is just a high-level library for configuring ssl for a server or client. The library has additional separate dependencies which the end-user can use to make it more easy to use for their use case. So the core library has only a dependency on slf4j-api. However there are separate libraries which contain mappers which I also created for apache4, apache5, netty and jetty which relay on the core library. Apache4, apache5, netty and jetty are currently a compile scoped dependency and therefor the end-user will also get the version which is specified in my pom. Let's assume someone is using the apache4 version. So should the end-user exclude the dependency manually when they are using my library and don't want the specific transitive apache4 dependency? Or should I mark apache4 as provided scope type. In that way there will be no transitive dependency, however the end-user should have the apache4 dependency present on their classpath or else they will get a runtime exception when they use my library.