[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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
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 <info@xxxxxxxxxx>
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@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users