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
On 25/11/2022 11:49, Info wrote:
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 <i...@betzel.net> wrote:
Simone,
my suspicion is that the Jetty XML being declarative and thus not
directly handled by the OSGi runtime, is causing the timing troubles.
I doubt it. We have XML files working fine with OSGi.
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
perform
in order to get a new Lets Encypt SSL certificate?
Cannot parse the above.
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.alpn
dependency instead of the org.eclipse.jetty.alpn one, building a
fragment for that one now.
As I said, I don't think you should do anything wrt Jetty or OSGi.
Just setup a Jetty server and add the "acme-tls/1" ALPN protocol.
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
