Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] TLS ALPN ACME Lets Encrypt challange

Hi,

all points known and noted, yes our Jetty is old and I was working on making the front-end nodes loosely coupled from the back-end so I can more easily upgrade those nodes exposed to the WAN.

THEN the real world comes along with a automatic certificate renewal feature that requires a refresh every 90 days having the servers already running Lets Encrypt certificates. So the patch has to hold for now and for this purpose.

I am even up to more horrible things (pun intended), implementing an on the fly update-able org.eclipse.jetty.util.ssl.SslContextFactory with select-able keys. Examples galore on the net.


On 01/12/2022 15:11, Joakim Erdfelt wrote:
Inline ...

On Thu, Dec 1, 2022 at 7:24 AM Info <info@xxxxxxxxxx> wrote:

Hi Simone,

What does this mean exactly?
OpenJDK8ServerALPNProcessor works fine in OSGi, so you should not need
to override anything.

My current Jetty version OpenJDK8ServerALPNProcessor   uses:

	if (ALPN.class.getClassLoader()!=null)

But because my JDK version already contains the ALPN classes natively this is needed:

	alpnSelector = SSLEngine.class.getMethod("setHandshakeApplicationProtocolSelector", BiFunction.class);

etc... So I copied that from a later Jetty implementation for now.


I've seen this scenario before, in a few different ways. 

1. You are using an IBM based JVM.
2. You are using a non-official Jetty JAR (or building your own in the wrong way, or using a badly made uber jar).
3. You don't have the correct dependencies for your Runtime JVM.
4. You are not keeping up with the rapid pace of change on the public internet with SSL/TLS.

For #1 above, all IBM JVMs are thoroughly brain-dead and fundamentally broken when it comes to SSL/TLS/Cipher Suites.
Mainly because they refuse to actually use the standards and specs as intended and are leaning on the "backward compatibility" (to their old pre standards JVM implementation) excuse, making most standards compliant code not function on their JVMs.
I don't recommend using IBM JVMs if you are using SSL/TLS.
But if you do need to use them, you have tons of configuration to maintain and custom code to write to "bridge" the standard compliant operation of Jetty to the IBM "backwards" behaviors.

For #2 above, this usually means the META-INF/services entries are missing and/or bad in your non-official Jetty JARs.

For #3 above, you should be using the correct dependency for your JVM.

If your runtime is Java 9+, then you would use the jetty-alpn-java-server.

If your runtime is Java 8, then you would use the jetty-alpn-openjdk8-server.
Your description of `if (ALPN.class.getClassLoader()!=null)` means you are using an ancient version of Jetty.
Your "so i copied that from a later Jetty implementation" is troubling, you know that 90+ files were changed in Jetty to support ALPN in OpenJDK 8, right?
There's been 1,600 commits between Jetty 9.4.27 (the last version of Jetty with your old solution) and Jetty 9.4.49 (the current version of 9.4.x) - 59 of which are directly in the ALPN tree.
Upgrade your Jetty version properly, don't use this partial / incomplete solution.

For #4 above, when working with SSL/TLS, you have to keep things up to date (this is not optional if you are on the public internet).
This includes your JVM and your Jetty versions.
Most people don't realize that your JVMs have an expiration date, specifically for users of SSL/TLS. (if you don't use SSL/TLS, then you can ignore the expiration date).

- Joakim

_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users

Back to the top