| Re: [jetty-users] TLS ALPN ACME Lets Encrypt challange |
Hi Simone,
some premature cheering on my behalf, I was thinking the ALPN processor would do the ACME handling but after re-reading your suggestions it is becoming clear that I need to implement something similar to the HTTP2 Jetty part. I got the HTTP2 part working and I am getting sessions created and closed, my http test-client reports that h2 is the selected protocol. So now I must create an similar ACME connectionfactory and onOpened add a ACME4J session to the jetty session, or how to combine the Jetty API with the ACME4J api?
Met vriendelijke groet / Mit freundlichen Grüßen / Kind regards,
Maurice Betzel
Principal Software Engineer
Moin Simone,
Aries SPI FLY can create startup timing issues, as stated on the project. SPI FLY MUST be up and running before any JDK service providers are resolved. Thats why I created a connection factory with a OSGi service-tracker.
The bundles are resolving now and the ALPN processor is registered and ready for the ACME challenge implementation.
Since I use OpenJDK 8u252 or later, ALPN is not needed on the extended classpath as a boot feature. I am using the mortbay ALPN bundle for reference and not the one as provided by the Jetty project, as pax-web-jetty 7.x has an optional dependency on the mortbay bundle and if it loads and initializes my ALPN processor, which is using the ALPN API, this should match due to the shared classloader between pax-web-jetty and the fragment containing the connection factory.
I created an API fragment bundle containing my AlpnServerConnectionFactory and AlpnServerConnection that the pax-web-jetty bundle will host so it can load and create the classes if the Jetty XML gets parsed. The factory has the bespoken OSGi ServiceTracker that tracks ALPNProcessor.Server services, providing the ALPN processor for the AMCE TLS challenge.
It always seems so simple once it is running, now I need a test client.
On 24/11/2022 19:13, Simone Bordet wrote:
Hi,_______________________________________________
On Thu, Nov 24, 2022 at 3:56 PM Info <info@xxxxxxxxxx> wrote:
Simone,I doubt it. We have XML files working fine with OSGi.
my suspicion is that the Jetty XML being declarative and thus not
directly handled by the OSGi runtime, is causing the timing troubles.
You still don't say what exactly is the problem you're having.
Can you setup a default HTTP/2 server?
If you can, that should be enough.
But I am right about the staging of the ACME challenge I have to performCannot parse the above.
in order to get a new Lets Encypt SSL certificate?
I don't think you must perform the ACME challenge; you receive it and
you have to answer it.
https://letsencrypt.org/how-it-works/The link does not report in detail how it would work with the
TLS-ALPN-01, which is reported here:
https://letsencrypt.org/docs/challenge-types/
Did not get to a test because Pax Web uses the org.mortbay.jetty.alpnAs I said, I don't think you should do anything wrt Jetty or OSGi.
dependency instead of the org.eclipse.jetty.alpn one, building a
fragment for that one now.
Just setup a Jetty server and add the "acme-tls/1" ALPN protocol.
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users