| Re: [jetty-users] TLS ALPN ACME Lets Encrypt challange |
Hi Simone,
What does this mean exactly? OpenJDK8ServerALPNProcessor works fine in OSGi, so you should not need to override anything.
My current Jetty version OpenJDK8ServerALPNProcessor uses:
if (ALPN.class.getClassLoader()!=null)
But because my JDK version already contains the ALPN classes natively this is needed:
alpnSelector = SSLEngine.class.getMethod("setHandshakeApplicationProtocolSelector", BiFunction.class);
etc... So I copied that from a later Jetty implementation for
now.
I have never suggested to register an ACMEServerConnectionFactory. I repeatedly said that you don't need it.
You suggested this in the mail from the 23 and it works to avoid the log line:
If you want to avoid that log line, you can write your own ConnectionFactory and close the EndPoint from onOpen(). You can start a shell script that uses Java's keytool, or use the Java BouncyCastle APIs like we do in KeystoreGenerator.Jup, found that one and I have Bouncycastle available, and then hot reload. I am wondering if a dynamic selection of a key-pair is possible on connect.
The ACME server opens a connection to the TLS server (Jetty), Jetty completes the TLS handshake, then closes the connection. That is the "response": the bytes exchanged in the TLS handshake.
It depends on the CA if the ACME handshake should complete,
according to the RFC. Cannot find any documentation on this from
Lets Encrypt, so trial and error.
Hi, On Thu, Dec 1, 2022 at 11:57 AM Info <info@xxxxxxxxxx> wrote:Hi, a short update, I got everything up and running as you have stated with the default Jetty classes in combination with SPI FLY, the startup level of the bundles did the trick. I only had to override the OpenJDK8ServerALPNProcessor because the implemented Jetty class in my used version does not handle the JDK internal ALPN classes correctly.What does this mean exactly? OpenJDK8ServerALPNProcessor works fine in OSGi, so you should not need to override anything.Also the correct Jetty XML configuration had me chasing my tail. I now have the h2 and the acme-tls/1 protocols configured for ALPN and I have registered an ACMEServerConnectionFactory with connection like you suggested:I have never suggested to register an ACMEServerConnectionFactory. I repeatedly said that you don't need it.My understanding of the ACME TLS-ALPN-01 using ACME4J is as follows: A cron job creates a ACME4j session object. A session is used to track the communication with the ACME server (without creating a new account). ACME4J uses an internal HttpURLConnection for communication with a CA provider like Lets Encrypt. Login to your provider account with the location URL and the KeyPair using the ACME4J session object to get your account. Then I can create an order for a new certificate which then contains a Authorization that has to be processed if in PENDING state. This Authorization then contains the challenges from which i will select the TlsAlpn01Challenge . I create a self signed certificate using the byte array from the challenge and configure Jetty 443 port with this (question: how to do that).You can start a shell script that uses Java's keytool, or use the Java BouncyCastle APIs like we do in KeystoreGenerator.Then trigger the challenge and let Jetty respond to multiple TLS requests with the ALPN extension acme-tls/1 until the Authorization status is VALID. Question, what response? I guess the generated key pair is the answer the CA is waiting for not needing to complete the handshake? Or does it need to complete the handshake?The ACME server opens a connection to the TLS server (Jetty), Jetty completes the TLS handshake, then closes the connection. That is the "response": the bytes exchanged in the TLS handshake.