|Re: [jetty-users] TLS ALPN ACME Lets Encrypt challange|
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). 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
Back to the top