Thank you Simone, Comments inline...
On 06-01-2022 15:55, Simone Bordet wrote:
The problem is that the Java APIs require a single KeyStore. However, KeyStore and everything necessary for certificate retrieval/validation could be reimplemented, so you probably can write a KeyStore that handles certificates in directories. A quick search: https://github.com/Hakky54/sslcontext-kickstart http://codyaray.com/2013/04/java-ssl-with-multiple-keystores https://github.com/1and1/CompositeJKS etc.
That sounds very interesting. I would then use setKeyStore instead of setKeyStorePath and take care of the rest myself... Never thought of that.
Generating the KeyStore on-the-fly is quite simple. We do this in the test-keystore shipped with jetty-home, so no big deal. If you use 1 Jetty to handle 100s KeyStores, then you need some sort of composite KeyStore (see links above). If you use 100 Jettys each with its own KeyStore, then I would say the best is to generate the KeyStore on-the-fly.
Most Jetty instances handle somewhere around 10 tenants having mostly 1 but sometimes up to ~30 certificates. But we also have some dedicated ones.
You can configure Jetty to allow non-SNI clients, so I am not sure why you think it's not possible? See this: https://www.eclipse.org/jetty/documentation/jetty-10/operations-guide/index.html#og-protocols-ssl-sni
I know that is possible but we can only do that if the keystore holds exactly the one certificate that is needed for that parfticular Jetty. Otherwise non SNI-clients will receive some random certificate from the keystore and that raises more eyebrows than a refused connection.
Thanks for the pointers to the multi-keystore solutions. That is definitely worth a look.
Cheers, Silvio _______________________________________________ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
