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 
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 in
chooseEngineServerAlias(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