Re: [jetty-users] TLS ALPN ACME Lets Encrypt challange

[Lothar Kimmeringer <job@xxxxxxxxxxxxxx>]

Am 30.11.2022 um 19:56 schrieb Simone Bordet:
> Hi,
>
> On Wed, Nov 30, 2022 at 7:29 PM Lothar Kimmeringer <job@xxxxxxxxxxxxxx> wrote:
> > The client in question is acme4j and the part between the ACME-
> > server and that client up to the point where the necessary
> > data is available for the creation of the certificate is done
> > there. But then you need to make sure that said certificate
> > is used by the corresponding ALPN processor which is where
> > Maurice's question was pointed (I suppose because that's my
> > question at this point after reading the thread). [1]
>
> Sure. Preparing the certificate with the right extensions is outside
> of Jetty's scope.

Never doubted that ;-), acme4j comes with an utility-class that
allows you to create the corresponding certificate.

> Let's say you do it manually although I imagine you can do it automatically.
> You prepare the certificate into a KeyStore, point Jetty at that
> KeyStore and start Jetty with
> "jetty.alpn.protocols=acme-tls/1,http/1.1".

Let's say, I want to do that during runtime without a (production)
server being required to be shut down. The authorization process ALPN
might be required at any given time, i.e. you have a passed
authorization up until today and the next time you want to refresh
your existing certificate the ACME-server tells you that you need to
do it again.

That means that you need a mechanism that allows me to tell
the ALPN-processor to use a particular (and different)
certificate for a TLS-request containing a specific SNI.

> This sets up your "TLS server" (as per wording of the RFC) with
> support for ACME TLS-ALPN-01 and for HTTP/1.1.
>
> At this point a browser connecting to your TLS server will receive an
> "insecure site, self-signed certificate" message, but you can persist
> and browse.

That's quite a bummer if we're talking about a production HTTP-server
that currently serves important stuff that immediately stops
working because all of them get this warning as well. The special
certificate should only be used for TLS-requests with a specific
SNI in the handshake (and should stop serving the certificate
after the authorization process is finished).

So starting in an exclusive "ACME-authorization" mode like your
suggestion would lead in my eyes, isn't an option which is why
I have this question, how to "get access" to the ALPN-processor
and be able to provide certificates to be used dynamically. BTW:
I already have my own SSLContextFactory creating my own KeyStore-
instances that allow me to get certificates from a database rather
than a file. So the dynamic retrieval of certificates as such
isn't the problem here, just the "how to tell the processor about it".


Thanks and cheers, Lothar