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

Am 30.11.2022 um 19:56 schrieb Simone Bordet:

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

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

Back to the top