Reading through this issue involving Fastspring, it seems likely this is already a known issue for you guys. I figured I'd report it anyway in case it's helpful for resolving the issue, but I'm fine with this issue being closed with a simple “this is a known issue on our end and will be addressed soon”.
We've written an in-house java app to create our licenses using the provided Web API for LimeLM. Today it seems the app is failing the SSL handshake step when trying to use the API. The app runs JDK 18 and uses HttpClient.java to service the http requests to LimeLM. If it is helpful, we can provide a code snippet from our app for debugging.
Our advice is to avoid using Java to contact our web API until we can solve this problem for 2 organizations (Oracle & FastSpring) with more resources than us (but apparently no engineers with any skill in debugging TLS errors that *only* effect their TLS library).
Using TurboActivate and TurboFloat with Java will work fine. Why? Because we do not use Java's built-in TLS libraries. Across Windows, Linux, BSD, and macOS we use 4 different TLS libraries that all connect to our servers just fine.
And all major browsers connect to our servers fine.
This is a Java problem. What exactly the problem is is still being dug into (yes, it's a handshake problem, but that's not nearly enough details – and it's hard to squeeze more useful and actionable information out of Java).
We're closing this topic because it's identical to the other one.