Le mer. 23 déc. 2020 à 20:39, Mladen Adamović <mladen.adamo...@gmail.com> a écrit :
> Christopher, thank you, now I think I understand better the situation. You > were right that I was anxious about this. > > Let me try to summarize: > - there is a consensus that this could be implemented through a Valve > - there are two options for this to work: either with the full ACME client > or with the certbot (to note that Letsencrypt recommends users to use > certbot). > - Tomcat devs don't want additional dependencies towards a ACME client > (this one: https://github.com/shred/acme4j/blob/master/README.md has > additional dependencies), I understand this point > - Writing Tomcat's own ACME client probably shall not happen for various > reasons (i.e. not so many users as many users have legitimate reasons to > run Tomcat behind a proxy, except those 'suckers' who run it for the sole > purpose to have Letsencrypt/SSL with it). > I am for it, dependency free is key as soon as you modify tomcat/lib - and since it is a transversal extension it will often be there. > Two options for a Valve: > - simple responding to ACME challenge (this could go into Tomcat source > code eventually) > - dependency on Java ACME client (probably would stay separate) > > Regarding writing Valve, this would probably mean in any case most likely > providing a different ServletContext, right? > The valve does not need another context which enables to match the letsencript challenge whatever is deployed as app. > > > > > > > > > > > On Wed, Dec 23, 2020 at 7:02 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > > > Mladen, > > > > On 12/23/20 11:24, Mladen Adamović wrote: > > > On Wed, Dec 23, 2020 at 4:44 PM Romain Manni-Bucau < > > rmannibu...@gmail.com> > > > wrote: > > > > > >> 1. Usage, typically if you run in kubernetes or any managed instance > env > > >> then you don't care and will restart the instance (with graceful > > shutdown) > > >> when needed > > >> > > > > > > This is outside of my scope. > > > > > > > > >> 2. There are several tomcat instances out there using certbot (my blog > > is a > > >> tomee with certbot on for example) so can also be a lack of > > doc/knowledge > > >> > > > > > > That's well known before in the conversation, i.e. I'm running Tomcat > > with > > > SSL on numbeo.com as documented here: > > > > > > https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/ > > > > That guide does way more than necessary. Try reading this: > > http://tomcat.apache.org/presentations.html#latest-lets-encrypt > > > > (Again, if necessary.) > > > > certbot + script = working > > > > >> 3. I agree a built in module enables an easier deployment (just a > valve > > to > > >> configure with a few attributes) and everything else works OOTB but > you > > >> don't need any modification in tomcat distribution to do that - was my > > main > > >> point, all can be done in a new module without modifying tomcat > > internals > > >> for a particular deployment > > > > > > But adding a Valve or a Servlet would mean modifying Tomcat internals? > > > > No. Writing a Valve does not change any code that ships with Tomcat. > > > > Steps: > > > > 1. Write Valve, compile + package to JAR > > 2. Drop JAR in lib/ directory > > 3. Add <Valve /> to conf/server.xml > > > > No where in there is editing of any Tomcat Java source required. > > > > >> 4. In several cases tomcat will not have the SSL config but a frontend > > >> (httpd, nginx, ...) will do it so tomcat integration will not help > there > > >> > > > > > > Those suckers ;-) > > > > I know you are kidding, but if you want load-balancing and fail-over, > > you have to front Tomcat with *something*. And if you are fronting > > Tomcat, you really should be terminating TLS there as well. At which > > point, ACME-in-Tomcat is really unnecessary. > > > > That's one of the reasons we are all a little skeptical about this: most > > Tomcat installations are not one-node wonders and already have all this > > other infrastructure available. So doing ACME elsewhere is simply > > "easier" than doing it at the Tomcat level. > > > > -chris > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > >
