Romain,
On 12/23/20 10:43, Romain Manni-Bucau wrote:
Well there are a few points to take into account here:
> [snip]
>
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
+1
I know this works for sure, because I worked to make sure it did. I use
it on a reporting server that's been running under this configuration
for months. certbot + scripts = working :) I partially built that as a
proof-of-concept for the "Let's Encrypt Apache Tomcat" presentation I
have done in the past. The initial version didn't have automatic reload,
so we (markt, really) built the reloadSsl capability as a "first step"
to something that would actually work.
Mladen, I know you are anxious to get this done but to say that nobody
here is interested is disingenuous. We are volunteers and we have
day-jobs, families, and holidays here and there that might interfere
with your schedule. I'm sorry about that, but it's the truth. If you
want Tomcat to support ACME "out of the box", we can move towards that
but you can't have it by 09:00 on Monday.
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
+1 (x1000)
This can be done in a Valve. Romain has already built this as a
ServletContextListener so it's very self-contained. I had to read it
through several times to understand how the ACME verification step was
being completed (the magic is that it drops a file onto the filesystem,
which I didn't expect, honestly). If you use a Valve, you can respond
directly without using a filesystem-based approach.
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
This is why, for me, a tomcat-letsencrypt module is the most relevant
solution.
If owned by Tomcat project perfect (this is the best IMHO), if not it will
still cover the same features so still good.
This can be a very straightforward project if you want it to be.
If you build it as a Valve, it will require the use of some internal
Tomcat APIs (e.g. Valve!) but it will not require that any part of
Tomcat be modified. This is good, especially if you want your
contribution to be accepted.
Valves also already have a timed-execution scheme that you can hook-into
(it's the backgroundProcess() call which will be called at intervals).
Valves get a crack at every request that comes through the system. If
you see a request to /.well-known/acme-challenge/[token] you can respond
immediately. Otherwise, just allow the request to process normally.
It will be a lot of straightforward than Romain's code IMHO.
The big problem is a dependency on an ACME client. Tomcat is not going
to want to have an ACME client as a built-dependency, and may not want
to have it as a deployment dependency. Take a look at the existing
libraries Tomcat uses. The list is *very* short, and we'd like to keep
it that way.
If you want Tomcat to be able to handle ACME out of the box, you are
going to have to make it somehow possible to use a plugable ACME API so
Tomcat doesn't have to supply one (it's not exactly OOTB, then, is it?)
or you are gong to have to package it separately, like tomcat-pool.
If you able to build this as a "simple" Valve and also without any
third-party dependencies (which may be silly, since ACME clients should
be trivially re-usable and re-building one in Tomcat seems like a waste
of time), then adding a acmeSupport="true" setting in Tomcat's <Host>
should be pretty trivial: we just have to arrange for acmeSupport="true"
to trigger the automated installation of a Valve in the valve pipeline
during startup. This is how the authenticators work: implemented as a
Valve, triggered by XML configuration in WEB-INF/web.xml.
But the point is that it is modular, can be developed independently, and
can use existing Tomcat infrastructure, code, APIs, etc. without lots of
changes to suit your view of how things should work.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
