|Re: [jetty-users] TLS ALPN ACME Lets Encrypt challange|
Update on the ACME story,currently I am testing against the pebble ACME test server and I am getting the following results on acme-tls-01 ALPN test runs:
2022-12-22T15:11:03,610 | DEBUG | qtp238290217-245 | SslContextFactory | 100 - org.eclipse.jetty.util - 9.4.43.v20210629 | Selecting alias: keyType=RSA, sni=localhost, sniRequired=false, certs=[X509@43e83c08(acme_challenge_key,h=[localhost, acme.invalid],a=,w=), X509@5b914e12(digital.gaston-schul.com (r3),h=[digital.gaston-schul.com],a=,w=)] 2022-12-22T15:11:03,611 | DEBUG | qtp238290217-245 | SslContextFactory | 100 - org.eclipse.jetty.util - 9.4.43.v20210629 | Selected alias=acme_challenge_key 2022-12-22T15:11:03,611 | DEBUG | qtp238290217-245 | SniX509ExtendedKeyManager | 100 - org.eclipse.jetty.util - 9.4.43.v20210629 | Matched SNI localhost with alias acme_challenge_key, certificate X509@43e83c08(acme_challenge_key,h=[localhost, acme.invalid],a=,w=) from aliases [acme_challenge_key, digital.gaston-schul.com (r3)] 2022-12-22T15:11:03,612 | DEBUG | qtp238290217-245 | SniX509ExtendedKeyManager | 100 - org.eclipse.jetty.util - 9.4.43.v20210629 | Chose explicit alias=acme_challenge_key keyType=RSA on sun.security.ssl.SSLEngineImpl@60cd0272 2022-12-22T15:11:03,615 | DEBUG | qtp238290217-245 | ACMEServerConnectionFactory | 100 - org.eclipse.jetty.util - 9.4.43.v20210629 | proto=acme-tls/1 tls=TLSv1.2 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 acceptable=true 2022-12-22T15:11:03,623 | DEBUG | qtp238290217-245 | ACMEServerConnectionFactory | 100 - org.eclipse.jetty.util - 9.4.43.v20210629 | Creating ACME server connection 2022-12-22T15:11:03,623 | DEBUG | qtp238290217-245 | ACMEServerConnection | 100 - org.eclipse.jetty.util - 9.4.43.v20210629 | Closing endpoint 2022-12-22T15:11:04,639 | INFO | AcmeQuartzScheduler_Worker-1 | JobRunShell | 190 - org.quartz-scheduler.quartz - 2.3.2 | Job acme.action.job.group.ACMERenewJob threw a JobExecutionException: org.quartz.JobExecutionException: Challenge has failed due to Failed to connect to [::1]:8444 for the tls-alpn-01 challenge
The pebble Certificate and Key-Pair are stored in the key-store and Jetty picks it up by hot reloading, then I trigger the challenge the SNI gets matched and I close the connection because the handshake should be all it needs transferring the challenge certificate.
But I get a failed challenge due to connection failure. Should I not close the connection?
On 02/12/2022 11:09, Lothar Kimmeringer wrote:
Am 02.12.2022 um 10:10 schrieb Info:I am curious if the code for the SSLContextFactory and Keystore is open-sourced somewhere?It's not but I don't see a problem in sharing it. But I'm not sure if it makes much sense because the reason why I've implemented one is very specific. Essentially I've overwritte doStart and doStop to delay its actual call in the derived class unless the part of the system is up that provides the certificates. When that's the case setKeyStore is called (with my implementation of a KeyStore) and after that doStart. This is a solution I've came up in 2013 when starting to use Jetty 9.0. There might be better solutions now (but if I understood Simone correctly, it doesn't sound like there are) but I'll stick with it until the corresponding unit tests stop working ;-) But this implementation solves a very specific requirement, which is why I doubt the source is useful for this particular topic. Same for the KeyStore. Not open source but nothing special, either. You just implement the engine-methods providing aliases, certificates and keys. I've also implemented my own versions of KeyManager and TrustManager to "help" the ContextFactory to decide what certificate/key to use which is the point where an ALPN-implementation should be based in my eyes.Maybe we can ponder a AMCE KeyManager together?I'm currently busy with a lot of other stuff (which is why ALPN- support is only on a list at the moment), so I'm not sure if it makes sense to wait for my availability. But looking at the API the KeyManager-implementation might be simple and the magic should take place inchooseEngineServerAlias(String keyType, Principal issuers, SSLEngine engine)if engine.getApplicationProtocol() return the information that ALPN is used, return the ACME-certificate and return the "normal" one if not. Thanks and cheers, Lothar
Back to the top