You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mladen Adamović <ml...@gmail.com> on 2020/12/19 10:12:58 UTC
feature request: reload SSL certificate automatically after X days
(configuration option)
Hi guys,
*Shortly*: Tomcat should have either Connector or SSLHostConfig option to
automatically reload certificate from the same file after X days, i.e.
reloadAfterDays=10 to force Tomcat to reload the certificate automatically
after 10 days.
*Long*:
SSL certificates have a period of expiration and in the case of
Letsencrypt, it's set to 3 months as they think everyone should have the
renewal mechanism automatically.
As the Letsencrypt is the most popular SSL issuing authority (source:
https://trends.builtwith.com/ssl/LetsEncrypt ), I think Tomcat should have
an integration with Letsencrypt working flawlessly.
We are currently using the script to renew the certificate (I can share our
integration details with whoever is interested, please email me if you are
interested), but it's restarting Tomcat.
As Tomcat shall not be restarted ever (ideally), I think Tomcat should have
an option to reload certificate, without a dependency to Tomcat source code
and "hacks" like some available on StackOverflow:
https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates).
Those hacks are no good as:
1) code to reload certificate should not run inside Java code, as
letsencrypt is invoked through Linux
2) each application uses that Stackoverflow hack have additional compile
and run dependency set to Tomcat (which is very bad).
I have a proposal on how this should be fixed: Tomcat should have a
server.xml options something like certificateReloadAfterDays or
reloadAfterDays
I see this is moved to SSLHostConfig, we are still using old params.
Do you agree on this feature?
If so... I'm not lazy to try to do it myself, but as I haven't ever written
Tomcat code neither know procedures (I have been coding professionally
since 2006, but I never committed to Maven or Git project before, lol), is
there someone else who is keen on doing this feature?
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 23 déc. 2020 à 22:23, Mladen Adamović <ml...@gmail.com> a
écrit :
> On Wed, Dec 23, 2020 at 9:13 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > 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.
> >
>
> Aha, you are for writing Tomcat specific ACME library without dependencies.
> First, I have never used Tomcat without Tomcat Native in production. I
> don't know if Tomcat without Native is currently feasible in production for
> SSL connector (what is the performance overhead?)
> I will try tomorrow to see on removing jose4j and bouncycastle dependencies
> from acme4j.
>
Tomcat works well without natives ;).
Dropping acme lib to do it in plain java is not crazy at all if you only
target http challenge.
> > 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.
> >
>
> I don't understand this from the code. Pipeline has its order so it's
> important that this Valve is put in the right position?
>
Sure but host have a pipeline then context one so set on the host as first
valve you have what you want and face all contexts.
On Host level, Netbeans didn't show me how setConfigClass is used.
> I think I should take a rest and tomorrow install IntelliJ and Eclipse as
> it seems Netbeans not working for Tomcat source for me properly.
>
AFAIK netbeans does but maybe the setup is not complete.
That said just a plain grep works too here ;).
Personally I would suggest to debug the pipeline(s) to understand it
better, helps generally.
>
>
> >
> > > On Wed, Dec 23, 2020 at 7:02 PM Christopher Schultz <
> > > chris@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 <
> > > > rmannibucau@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-unsubscribe@tomcat.apache.org
> > > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > > >
> > > >
> > >
> >
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Mladen Adamović <ml...@gmail.com>.
On Wed, Dec 23, 2020 at 9:13 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> 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.
>
Aha, you are for writing Tomcat specific ACME library without dependencies.
First, I have never used Tomcat without Tomcat Native in production. I
don't know if Tomcat without Native is currently feasible in production for
SSL connector (what is the performance overhead?)
I will try tomorrow to see on removing jose4j and bouncycastle dependencies
from acme4j.
> 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.
>
I don't understand this from the code. Pipeline has its order so it's
important that this Valve is put in the right position?
On Host level, Netbeans didn't show me how setConfigClass is used.
I think I should take a rest and tomorrow install IntelliJ and Eclipse as
it seems Netbeans not working for Tomcat source for me properly.
>
> > On Wed, Dec 23, 2020 at 7:02 PM Christopher Schultz <
> > chris@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 <
> > > rmannibucau@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-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > >
> > >
> >
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 23 déc. 2020 à 20:39, Mladen Adamović <ml...@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 <
> chris@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 <
> > rmannibucau@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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Mladen Adamović <ml...@gmail.com>.
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).
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?
On Wed, Dec 23, 2020 at 7:02 PM Christopher Schultz <
chris@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 <
> rmannibucau@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mladen,
On 12/23/20 11:24, Mladen Adamović wrote:
> On Wed, Dec 23, 2020 at 4:44 PM Romain Manni-Bucau <rm...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mladen,
On 12/23/20 09:07, Mladen Adamović wrote:
> hmmm.. at least for us, Certbot fetches acme-challenge on HTTP connector.
> According to
> https://github.com/payara/Payara/blob/master/appserver/packager/appserver-core/src/main/resources/bin/letsencrypt.py
> an app most likely should have a HTTP connector for Letsencrypt.
>
> Then it really doesn't matter AFAIK, if Servet is used or a Valve for most
> cases. Whatever dev thinks fits more in the nature of the system.
Romain is right: if you have configured blanket authentication
requirements for your web application, they will be applied *before* a
Servlet is invoked and Let's Encrypt doesn't generally provide
authentication to the application handling its ACME reply.
Stated more simply: if your application requests username+password, then
your application cannot be used to respond to ACME requests.
If you use a Valve, you can have the ACME-handling code execute before
the authenticator. That's how you get around the authentication "problem".
> I know this can be implemented outside of Tomcat (as we have that
> implementation through Servlet), I'm discussing what could be done in
> Tomcat to simplify Letsencrypt integration.
Use a Valve. ;)
-chris
> On Wed, Dec 23, 2020 at 2:01 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Le mer. 23 déc. 2020 à 12:50, Mladen Adamović <ml...@gmail.com>
>> a
>> écrit :
>>
>>> On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <
>> rmannibucau@gmail.com
>>>>
>>> wrote:
>>>
>>>> I don't think so, this connector auth is only used in very particular
>>> cases
>>>> (= never ;)): HTTP2 - we don't care, AJP - we don't care much. It is
>>> also a
>>>> kind of automatic authorization - no password or so - so will pass and
>>> not
>>>> fail.
>>>>
>>>
>>> That sounds very strange, as I have seen in the code:
>>> if (req.getRemoteUserNeedsAuthorization()) {
>>> ...
>>> } else if (!(authenticator instanceof
>> AuthenticatorBase)) {
>>> ...
>>> }
>>>
>>> public class SSLAuthenticator extends AuthenticatorBase {
>>>
>>>
>> Sure but check what makes remoteUserNeedsAuthorization true (http2 and ajp)
>> and what does the block when true (authenticate(username), no password or
>> so).
>> So not an issue IMHO.
>>
>>
>>>
>>> My point was if you have some security contraint (JWT, basic, etc...) on
>>>> /*, then your servlet will not be called for letsencrypt call whereas
>> if
>>>> you have a valve you can still handle it properly since you didn't
>> enter
>>>> the secured chain - a valve is before filter chain and can be before
>>>> authenticators in valve chain since authenticators - AuthenticatorBase
>> -
>>>> are valves.
>>>>
>>>
>>> Authenticator Valve's seems to me to have a different treatment than
>> other
>>> Valves which are accessed through Pipeline.
>>>
>>
>> This is true since it can be obtained from the context and its call can be
>> forced, but here again the question is when.
>> If you check callers then it shouldn't be the case until you add another
>> valve doing it and if so you can still set the LetsEncryptValve before and
>> bypass it - can even be set on the host and not the context.
>>
>>
>>>
>>>
>>>
>>>> In other words: no code change required in tomcat internals.
>>>>
>>>
>>> I don't understand this yet. If the implementation would use serverl.xml
>> to
>>> change StandardContextValve to something else?
>>>
>>
>> No, change nothing, just add a valve on the host for example through <Valve
>> className.... /> tag.
>>
>>
>>>
>>> I've tried to figure out what are you doing in meecrowave and my IDE
>>> (Netbeans) shows me Usage of LetsEncryptValve [no occurrences]
>>>
>>
>> Maybe use another IDE ;) (joking ;)):
>>
>> https://github.com/apache/openwebbeans-meecrowave/blob/433a691b246f9eeda2273e794ddbb7970691cc5f/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt/LetsEncryptSetup.java#L44
>> The MeecrowaveAwareInstanceCustomizer instance enables to "code" the
>> server.xml but it is equivalent to previous proposal (<Valve/>).
>>
>>
>>>
>>> How this LetsEncryptValve is actually "injected" into meecrowave
>> Pipeline ?
>>> Or how it is used internally?
>>> I didn't see any Reflection code on Valves or Valve base by searching
>>> source code.
>>>
>>>
>>>
>>>
>>>>
>>>> Romain Manni-Bucau
>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>> <http://rmannibucau.wordpress.com> | Github <
>>>> https://github.com/rmannibucau> |
>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>> <
>>>>
>>>
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>>>
>>>>
>>>>
>>>> Le mer. 23 déc. 2020 à 11:23, Mladen Adamović <
>> mladen.adamovic@gmail.com
>>>>
>>>> a
>>>> écrit :
>>>>
>>>>> Thank you Romain, do you then think the place to check for ACME Valve
>>> (if
>>>>> that would the be appropriate naming) would be in
>>>>> CoyoteAdapter.postParseRequest line 814
>>>>> before doConnectorAuthenticationAuthorization(...) ?
>>>>>
>>>>>
>>>>> On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau <
>>>> rmannibucau@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Side note: using a servlet generally does not work if you have any
>>>>> security
>>>>>> on the webapp + requires a webapp whereas using a valve solves
>> these
>>>> two
>>>>>> issues.
>>>>>>
>>>>>> Romain Manni-Bucau
>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog
>>>>>> <http://rmannibucau.wordpress.com> | Github <
>>>>>> https://github.com/rmannibucau> |
>>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
>>>>>> <
>>>>>>
>>>>>
>>>>
>>>
>> https://www.packtpub.com/application-development/java-ee-8-high-performance
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Le mer. 23 déc. 2020 à 09:15, Mladen Adamović <
>>>> mladen.adamovic@gmail.com
>>>>>>
>>>>>> a
>>>>>> écrit :
>>>>>>
>>>>>>> As I haven't received more replies on this topic, I'm guessing
>>>> project
>>>>>>> maintainers are not interested in reviewing and including the
>> code
>>>> for
>>>>>>> simpler Letsencrypt integration and discussing the mentioned SSL
>>>>>>> documentation improvements?
>>>>>>>
>>>>>>> Enabling AMCE response servlet (good idea by default) would be a
>>> good
>>>>>> step
>>>>>>> in my opinion?
>>>>>>>
>>>>>>> My procedure is explained here:
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
>>>>>>> and the step "Configure HTTP redirect application with support to
>>>> ACME
>>>>>>> challenge" could be integrated into Tomcat easily.
>>>>>>>
>>>>>>> In the case that is integrated, I can write a new improved
>>>>>>> tutorial/process.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Dec 19, 2020 at 11:09 PM Mladen Adamović <
>>>>>>> mladen.adamovic@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau <
>>>>>>> rmannibucau@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> It moves the problem elsewhere, how would the CLI communicate
>>> with
>>>>>>> tomcat?
>>>>>>>>> JMX, HTTP uses a port, a file based communication would be
>>>> probably
>>>>>>> worse
>>>>>>>>> because of perms and other admin issues (and just not working
>> in
>>>>> k8s).
>>>>>>>>>
>>>>>>>>
>>>>>>>> I don't see other sane ways actually. So it seems a web-based
>>>> manager
>>>>>>> with
>>>>>>>> curl is there to stay (for the time being at least).
>>>>>>>>
>>>>>>>> To Chris: It's somewhat weird that the user needs a web manager
>>>> just
>>>>>> for
>>>>>>>> curl-ing certification renewal.
>>>>>>>>
>>>>>>>> To everyone:
>>>>>>>> I have a suggestion on improving Documentation regarding SSL.
>>>>>>>> https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
>>>>>>>> Currently, it states
>>>>>>>> Configuration
>>>>>>>> Prepare the Certificate Keystore
>>>>>>>> Tomcat currently operates only on JKS, PKCS11 or PKCS12 format
>>>>>> keystores.
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>>
>>>>>>>> I think it should start with
>>>>>>>> Configuration
>>>>>>>> Option 1) Use Tomcat Native
>>>>>>>> which would showcase a path to something like:
>>>>>>>>
>>>>>>>> <!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443 -->
>>>>>>>> <Connector
>>>>>>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>>>>>> port="8443"
>>>>>>>> maxThreads="150"
>>>>>>>> SSLEnabled="true" >
>>>>>>>> <SSLHostConfig>
>>>>>>>> <Certificate
>>>>>>>> certificateKeyFile="conf/localhost-rsa-key.pem"
>>>>>>>> certificateFile="conf/localhost-rsa-cert.pem"
>>>>>>>> certificateChainFile="conf/localhost-rsa-chain.pem"
>>>>>>>> type="RSA"
>>>>>>>> />
>>>>>>>> </SSLHostConfig>
>>>>>>>> </Connector>
>>>>>>>>
>>>>>>>> Option 2) Without Tomcat Native
>>>>>>>>
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't know what is the formal process for improving the
>>>>> documentation
>>>>>>>> here?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
>>>>>>>>>>> mladen.adamovic@gmail.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> a
>>>>>>>>>>>>> écrit :
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz
>> <
>>>>>>>>>>>>>> chris@christopherschultz.net> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Why not use cron? You can do this with a single
>>> "curl"
>>>>>>> command
>>>>>>>>>> and
>>>>>>>>>>>> the
>>>>>>>>>>>>>>> Manager+JMXProxyServlet.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We are not using Tomcat manager app.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why someone should be forced to use Manager, to
>>>> read/setup
>>>>>> the
>>>>>>>>>>>>>> documentation regarding JMXProxyServlet, create an
>>>>>> additional
>>>>>>>>>>>>>> servlet (where does it have dependency on?) only to
>>>> reload
>>>>>>>>>>>> automatically
>>>>>>>>>>>>>> certificates?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm proposing a solution with the simple
>> SSLHostConfig
>>>>>>>>> parameter.
>>>>>>>>>>> It's
>>>>>>>>>>>> a
>>>>>>>>>>>>>> user friendly. Simple, intuitive.
>>>>>>>>>>>>>> No need for using manager, no need to create a
>>> specific
>>>>>>> servlet
>>>>>>>>>>>> somewhere
>>>>>>>>>>>>>> in your code. Just a single server.xml argument.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also, *another idea*, I'm contributing this code
>> (see
>>>>> below)
>>>>>>> we
>>>>>>>>> are
>>>>>>>>>>>> using
>>>>>>>>>>>>>> for Letsencrypt ACME challenge.
>>>>>>>>>>>>>> Tomcat could also have an option, i.e. in web.xml to
>>>>>>>>> automatically
>>>>>>>>>>>>> support
>>>>>>>>>>>>>> Letsencrypt ACME challenge.
>>>>>>>>>>>>>> Idea for web.xml
>>>>>>>>>>>>>> <servlet>
>>>>>>>>>>>>>>
>> <servlet-name>Letsencrypt-acme</servlet-name>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
>>>>>>>>>>>>>> <init-param>
>>>>>>>>>>>>>> etc.
>>>>>>>>>>>>>> </servlet>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We are using
>>>>>>>>>>>>>> @WebServlet(name = "LetsencryptAcmeChallenge",
>>>>> urlPatterns =
>>>>>>>>>>>>>> {"/.well-known/acme-challenge/*"})
>>>>>>>>>>>>>> public class LetsencryptAcmeChallenge extends
>>>> HttpServlet
>>>>> {
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /**
>>>>>>>>>>>>>> * Processes requests for both HTTP
>> <code>GET</code>
>>>> and
>>>>>>>>>>>>>> <code>POST</code> methods.
>>>>>>>>>>>>>> *
>>>>>>>>>>>>>> * @param request servlet request
>>>>>>>>>>>>>> * @param response servlet response
>>>>>>>>>>>>>> * @throws ServletException if a servlet-specific
>>>> error
>>>>>>> occurs
>>>>>>>>>>>>>> * @throws IOException if an I/O error occurs
>>>>>>>>>>>>>> */
>>>>>>>>>>>>>> protected void processRequest(HttpServletRequest
>>>>> request,
>>>>>>>>>>>>>> HttpServletResponse response)
>>>>>>>>>>>>>> throws ServletException, IOException {
>>>>>>>>>>>>>> String requestUrl =
>>>>> request.getRequestURL().toString();
>>>>>>>>>>>>>> if
>>>>> (requestUrl.contains(".well-known/acme-challenge/"))
>>>>>> {
>>>>>>>>>>>>>> int indexFilename =
>> requestUrl.lastIndexOf("/")
>>> +
>>>> 1;
>>>>>>>>>>>>>> boolean wasError = true;
>>>>>>>>>>>>>> if (indexFilename > 0 && indexFilename <
>>>>>>>>>> requestUrl.length()) {
>>>>>>>>>>>>>> String filename =
>>>>>> requestUrl.substring(indexFilename);
>>>>>>>>>>>>>> File existingFile = new
>>>>>>>>>>>>>>
>>>>>>> File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/"
>>>>>>>>> +
>>>>>>>>>>>>>> filename);
>>>>>>>>>>>>>> if (existingFile.exists()) {
>>>>>>>>>>>>>> response.setContentType("text/plain");
>>>>>>>>>>>>>> OutputStream out =
>>> response.getOutputStream();
>>>>>>>>>>>>>> FileInputStream in = new
>>>>>>>>> FileInputStream(existingFile);
>>>>>>>>>>>>>>
>>> FilesOperations.inputStreamToOutputStream(in,
>>>>>> out);
>>>>>>>>>>>>>> wasError = false;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> if (wasError) {
>>>>>>>>>>>>>> throw new ServletException("invalid
>> requestUrl
>>>> " +
>>>>>>>>>>> requestUrl);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> from FilesOperations:
>>>>>>>>>>>>>> public static void
>>>>>> inputStreamToOutputStream(InputStream
>>>>>>>>> in,
>>>>>>>>>>>>>> OutputStream out) throws IOException {
>>>>>>>>>>>>>> try {
>>>>>>>>>>>>>> byte[ ] buf = new byte[32 * 1024]; //
>>> 32K
>>>>>> buffer
>>>>>>>>>>>>>> int bytesRead;
>>>>>>>>>>>>>> while ((bytesRead = in.read(buf)) !=
>> -1) {
>>>>>>>>>>>>>> out.write(buf, 0, bytesRead);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> } finally {
>>>>>>>>>>>>>> if (in != null) {
>>>>>>>>>>>>>> in.close();
>>>>>>>>>>>>>> out.close();
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *Long*:
>>>>>>>>>>>>>>>> SSL certificates have a period of expiration and
>>> in
>>>>> the
>>>>>>>>> case of
>>>>>>>>>>>>>>>> Letsencrypt, it's set to 3 months as they think
>>>>> everyone
>>>>>>>>> should
>>>>>>>>>>>> have
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> renewal mechanism automatically.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As the Letsencrypt is the most popular SSL
>> issuing
>>>>>>> authority
>>>>>>>>>>>> (source:
>>>>>>>>>>>>>>>> https://trends.builtwith.com/ssl/LetsEncrypt
>> ), I
>>>>> think
>>>>>>>>> Tomcat
>>>>>>>>>>>>> should
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>> an integration with Letsencrypt working
>>> flawlessly.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We are currently using the script to renew the
>>>>>> certificate
>>>>>>>>> (I
>>>>>>>>>> can
>>>>>>>>>>>>> share
>>>>>>>>>>>>>>> our
>>>>>>>>>>>>>>>> integration details with whoever is interested,
>>>> please
>>>>>>>>> email me
>>>>>>>>>>> if
>>>>>>>>>>>>> you
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>> interested), but it's restarting Tomcat.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As Tomcat shall not be restarted ever
>> (ideally), I
>>>>> think
>>>>>>>>> Tomcat
>>>>>>>>>>>>> should
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>> an option to reload certificate, without a
>>>> dependency
>>>>> to
>>>>>>>>> Tomcat
>>>>>>>>>>>>> source
>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>> and "hacks" like some available on
>> StackOverflow:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
>>>>>>>>>>>>>>> ).
>>>>>>>>>>>>>>>> Those hacks are no good as:
>>>>>>>>>>>>>>>> 1) code to reload certificate should not run
>>> inside
>>>>> Java
>>>>>>>>> code,
>>>>>>>>>> as
>>>>>>>>>>>>>>>> letsencrypt is invoked through Linux
>>>>>>>>>>>>>>>> 2) each application uses that Stackoverflow hack
>>>> have
>>>>>>>>>> additional
>>>>>>>>>>>>>> compile
>>>>>>>>>>>>>>>> and run dependency set to Tomcat (which is very
>>>> bad).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have a proposal on how this should be fixed:
>>>> Tomcat
>>>>>>> should
>>>>>>>>>>> have a
>>>>>>>>>>>>>>>> server.xml options something like
>>>>>>>>> certificateReloadAfterDays or
>>>>>>>>>>>>>>>> reloadAfterDays
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I see this is moved to SSLHostConfig, we are
>> still
>>>>> using
>>>>>>> old
>>>>>>>>>>>> params.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Do you agree on this feature?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If so... I'm not lazy to try to do it myself,
>> but
>>>> as I
>>>>>>>>> haven't
>>>>>>>>>>> ever
>>>>>>>>>>>>>>> written
>>>>>>>>>>>>>>>> Tomcat code neither know procedures (I have been
>>>>> coding
>>>>>>>>>>>>> professionally
>>>>>>>>>>>>>>>> since 2006, but I never committed to Maven or
>> Git
>>>>>> project
>>>>>>>>>> before,
>>>>>>>>>>>>> lol),
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>> there someone else who is keen on doing this
>>>> feature?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Have a look at this:
>>>>>>>>>>>>>>>
>>>>>>>>>
>> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -chris
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>>>> dev-unsubscribe@tomcat.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>> dev-help@tomcat.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 23 déc. 2020 à 17:24, Mladen Adamović <ml...@gmail.com> a
écrit :
> On Wed, Dec 23, 2020 at 4:44 PM Romain Manni-Bucau <rm...@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/
>
>
Was just answering your point that user complains. It works, that's a fact.
If (once hopefully) we get a tomcat-letsencrypt module we'll get issues
that it does not work for some people. This is always the case each time
you create something new so real point is can we make it better.
Being embed we can refresh when needed instead of randomly so I think we
can make it better, but it already works and it will not solve the entry
cost users have I think.
>
> > 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, it means implementing a Valve.
We don't modify tomcat internals each time we implement a servlet and it is
~the same there ;).
>
>
>
> > 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 ;-)
>
Joke apart, they have their usage and in such a setup one big gain is to
reduce the number of requests to let's encrypt (compared to a backend with
hundreds of instances, the front will likely just get ~10 instances) and
have a different lifecycle than the app.
>
>
>
>
> >
> > 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.
> >
> > Hope it makes sense.
> >
> >
> > >
> > >
> > >
> > >
> > > > Do you see anything else which would need to change? The reloadSSL
> > method
> > > > was added for letsencrypt already so guess this adjustment work is
> > > already
> > > > done.
> > >
> > >
> > > There are currently two options, through manager or through service
> > > restart. It seems that there is no consensus here to add the 3th
> option.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > > >
> > > > >
> > > > > On Wed, Dec 23, 2020 at 2:01 PM Romain Manni-Bucau <
> > > > rmannibucau@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Le mer. 23 déc. 2020 à 12:50, Mladen Adamović <
> > > > mladen.adamovic@gmail.com
> > > > > >
> > > > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <
> > > > > > rmannibucau@gmail.com
> > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I don't think so, this connector auth is only used in very
> > > > particular
> > > > > > > cases
> > > > > > > > (= never ;)): HTTP2 - we don't care, AJP - we don't care
> much.
> > It
> > > > is
> > > > > > > also a
> > > > > > > > kind of automatic authorization - no password or so - so will
> > > pass
> > > > > and
> > > > > > > not
> > > > > > > > fail.
> > > > > > > >
> > > > > > >
> > > > > > > That sounds very strange, as I have seen in the code:
> > > > > > > if (req.getRemoteUserNeedsAuthorization()) {
> > > > > > > ...
> > > > > > > } else if (!(authenticator instanceof
> > > > > > AuthenticatorBase)) {
> > > > > > > ...
> > > > > > > }
> > > > > > >
> > > > > > > public class SSLAuthenticator extends AuthenticatorBase {
> > > > > > >
> > > > > > >
> > > > > > Sure but check what makes remoteUserNeedsAuthorization true
> (http2
> > > and
> > > > > ajp)
> > > > > > and what does the block when true (authenticate(username), no
> > > password
> > > > or
> > > > > > so).
> > > > > > So not an issue IMHO.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > My point was if you have some security contraint (JWT, basic,
> > > etc...)
> > > > > on
> > > > > > > > /*, then your servlet will not be called for letsencrypt call
> > > > whereas
> > > > > > if
> > > > > > > > you have a valve you can still handle it properly since you
> > > didn't
> > > > > > enter
> > > > > > > > the secured chain - a valve is before filter chain and can be
> > > > before
> > > > > > > > authenticators in valve chain since authenticators -
> > > > > AuthenticatorBase
> > > > > > -
> > > > > > > > are valves.
> > > > > > > >
> > > > > > >
> > > > > > > Authenticator Valve's seems to me to have a different treatment
> > > than
> > > > > > other
> > > > > > > Valves which are accessed through Pipeline.
> > > > > > >
> > > > > >
> > > > > > This is true since it can be obtained from the context and its
> call
> > > can
> > > > > be
> > > > > > forced, but here again the question is when.
> > > > > > If you check callers then it shouldn't be the case until you add
> > > > another
> > > > > > valve doing it and if so you can still set the LetsEncryptValve
> > > before
> > > > > and
> > > > > > bypass it - can even be set on the host and not the context.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > In other words: no code change required in tomcat internals.
> > > > > > > >
> > > > > > >
> > > > > > > I don't understand this yet. If the implementation would use
> > > > > serverl.xml
> > > > > > to
> > > > > > > change StandardContextValve to something else?
> > > > > > >
> > > > > >
> > > > > > No, change nothing, just add a valve on the host for example
> > through
> > > > > <Valve
> > > > > > className.... /> tag.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > I've tried to figure out what are you doing in meecrowave and
> my
> > > IDE
> > > > > > > (Netbeans) shows me Usage of LetsEncryptValve [no occurrences]
> > > > > > >
> > > > > >
> > > > > > Maybe use another IDE ;) (joking ;)):
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/openwebbeans-meecrowave/blob/433a691b246f9eeda2273e794ddbb7970691cc5f/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt/LetsEncryptSetup.java#L44
> > > > > > The MeecrowaveAwareInstanceCustomizer instance enables to "code"
> > the
> > > > > > server.xml but it is equivalent to previous proposal (<Valve/>).
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > How this LetsEncryptValve is actually "injected" into
> meecrowave
> > > > > > Pipeline ?
> > > > > > > Or how it is used internally?
> > > > > > > I didn't see any Reflection code on Valves or Valve base by
> > > searching
> > > > > > > source code.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Romain Manni-Bucau
> > > > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > > https://github.com/rmannibucau> |
> > > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > > > <
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Le mer. 23 déc. 2020 à 11:23, Mladen Adamović <
> > > > > > mladen.adamovic@gmail.com
> > > > > > > >
> > > > > > > > a
> > > > > > > > écrit :
> > > > > > > >
> > > > > > > > > Thank you Romain, do you then think the place to check for
> > ACME
> > > > > Valve
> > > > > > > (if
> > > > > > > > > that would the be appropriate naming) would be in
> > > > > > > > > CoyoteAdapter.postParseRequest line 814
> > > > > > > > > before doConnectorAuthenticationAuthorization(...) ?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau <
> > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Side note: using a servlet generally does not work if you
> > > have
> > > > > any
> > > > > > > > > security
> > > > > > > > > > on the webapp + requires a webapp whereas using a valve
> > > solves
> > > > > > these
> > > > > > > > two
> > > > > > > > > > issues.
> > > > > > > > > >
> > > > > > > > > > Romain Manni-Bucau
> > > > > > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > > > > https://github.com/rmannibucau> |
> > > > > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> |
> Book
> > > > > > > > > > <
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Le mer. 23 déc. 2020 à 09:15, Mladen Adamović <
> > > > > > > > mladen.adamovic@gmail.com
> > > > > > > > > >
> > > > > > > > > > a
> > > > > > > > > > écrit :
> > > > > > > > > >
> > > > > > > > > > > As I haven't received more replies on this topic, I'm
> > > > guessing
> > > > > > > > project
> > > > > > > > > > > maintainers are not interested in reviewing and
> including
> > > the
> > > > > > code
> > > > > > > > for
> > > > > > > > > > > simpler Letsencrypt integration and discussing the
> > > mentioned
> > > > > SSL
> > > > > > > > > > > documentation improvements?
> > > > > > > > > > >
> > > > > > > > > > > Enabling AMCE response servlet (good idea by default)
> > would
> > > > be
> > > > > a
> > > > > > > good
> > > > > > > > > > step
> > > > > > > > > > > in my opinion?
> > > > > > > > > > >
> > > > > > > > > > > My procedure is explained here:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
> > > > > > > > > > > and the step "Configure HTTP redirect application with
> > > > support
> > > > > to
> > > > > > > > ACME
> > > > > > > > > > > challenge" could be integrated into Tomcat easily.
> > > > > > > > > > >
> > > > > > > > > > > In the case that is integrated, I can write a new
> > improved
> > > > > > > > > > > tutorial/process.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Sat, Dec 19, 2020 at 11:09 PM Mladen Adamović <
> > > > > > > > > > > mladen.adamovic@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau <
> > > > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >> It moves the problem elsewhere, how would the CLI
> > > > > communicate
> > > > > > > with
> > > > > > > > > > > tomcat?
> > > > > > > > > > > >> JMX, HTTP uses a port, a file based communication
> > would
> > > be
> > > > > > > > probably
> > > > > > > > > > > worse
> > > > > > > > > > > >> because of perms and other admin issues (and just
> not
> > > > > working
> > > > > > in
> > > > > > > > > k8s).
> > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > > > I don't see other sane ways actually. So it seems a
> > > > web-based
> > > > > > > > manager
> > > > > > > > > > > with
> > > > > > > > > > > > curl is there to stay (for the time being at least).
> > > > > > > > > > > >
> > > > > > > > > > > > To Chris: It's somewhat weird that the user needs a
> web
> > > > > manager
> > > > > > > > just
> > > > > > > > > > for
> > > > > > > > > > > > curl-ing certification renewal.
> > > > > > > > > > > >
> > > > > > > > > > > > To everyone:
> > > > > > > > > > > > I have a suggestion on improving Documentation
> > regarding
> > > > SSL.
> > > > > > > > > > > >
> > https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
> > > > > > > > > > > > Currently, it states
> > > > > > > > > > > > Configuration
> > > > > > > > > > > > Prepare the Certificate Keystore
> > > > > > > > > > > > Tomcat currently operates only on JKS, PKCS11 or
> PKCS12
> > > > > format
> > > > > > > > > > keystores.
> > > > > > > > > > > >
> > > > > > > > > > > > ...
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I think it should start with
> > > > > > > > > > > > Configuration
> > > > > > > > > > > > Option 1) Use Tomcat Native
> > > > > > > > > > > > which would showcase a path to something like:
> > > > > > > > > > > >
> > > > > > > > > > > > <!-- Define an SSL Coyote HTTP/1.1 Connector on port
> > 8443
> > > > -->
> > > > > > > > > > > > <Connector
> > > > > > > > > > > >
> > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > > > > > > > > > > > port="8443"
> > > > > > > > > > > > maxThreads="150"
> > > > > > > > > > > > SSLEnabled="true" >
> > > > > > > > > > > > <SSLHostConfig>
> > > > > > > > > > > > <Certificate
> > > > > > > > > > > >
> certificateKeyFile="conf/localhost-rsa-key.pem"
> > > > > > > > > > > > certificateFile="conf/localhost-rsa-cert.pem"
> > > > > > > > > > > >
> > > certificateChainFile="conf/localhost-rsa-chain.pem"
> > > > > > > > > > > > type="RSA"
> > > > > > > > > > > > />
> > > > > > > > > > > > </SSLHostConfig>
> > > > > > > > > > > > </Connector>
> > > > > > > > > > > >
> > > > > > > > > > > > Option 2) Without Tomcat Native
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > ...
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I don't know what is the formal process for improving
> > the
> > > > > > > > > documentation
> > > > > > > > > > > > here?
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > >
> > > > > > > > > > > >> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen
> Adamović
> > <
> > > > > > > > > > > >> > > mladen.adamovic@gmail.com
> > > > > > > > > > > >> > > > >
> > > > > > > > > > > >> > > > > a
> > > > > > > > > > > >> > > > > écrit :
> > > > > > > > > > > >> > > > >
> > > > > > > > > > > >> > > > > > On Sat, Dec 19, 2020 at 2:29 PM
> Christopher
> > > > > Schultz
> > > > > > <
> > > > > > > > > > > >> > > > > > chris@christopherschultz.net> wrote:
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > > > Why not use cron? You can do this with a
> > > > single
> > > > > > > "curl"
> > > > > > > > > > > command
> > > > > > > > > > > >> > and
> > > > > > > > > > > >> > > > the
> > > > > > > > > > > >> > > > > > > Manager+JMXProxyServlet.
> > > > > > > > > > > >> > > > > > >
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > > We are not using Tomcat manager app.
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > > Why someone should be forced to use
> Manager,
> > > to
> > > > > > > > read/setup
> > > > > > > > > > the
> > > > > > > > > > > >> > > > > > documentation regarding JMXProxyServlet,
> > > create
> > > > an
> > > > > > > > > > additional
> > > > > > > > > > > >> > > > > > servlet (where does it have dependency
> on?)
> > > only
> > > > > to
> > > > > > > > reload
> > > > > > > > > > > >> > > > automatically
> > > > > > > > > > > >> > > > > > certificates?
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > > I'm proposing a solution with the simple
> > > > > > SSLHostConfig
> > > > > > > > > > > >> parameter.
> > > > > > > > > > > >> > > It's
> > > > > > > > > > > >> > > > a
> > > > > > > > > > > >> > > > > > user friendly. Simple, intuitive.
> > > > > > > > > > > >> > > > > > No need for using manager, no need to
> > create a
> > > > > > > specific
> > > > > > > > > > > servlet
> > > > > > > > > > > >> > > > somewhere
> > > > > > > > > > > >> > > > > > in your code. Just a single server.xml
> > > argument.
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > > Also, *another idea*, I'm contributing
> this
> > > code
> > > > > > (see
> > > > > > > > > below)
> > > > > > > > > > > we
> > > > > > > > > > > >> are
> > > > > > > > > > > >> > > > using
> > > > > > > > > > > >> > > > > > for Letsencrypt ACME challenge.
> > > > > > > > > > > >> > > > > > Tomcat could also have an option, i.e. in
> > > > web.xml
> > > > > to
> > > > > > > > > > > >> automatically
> > > > > > > > > > > >> > > > > support
> > > > > > > > > > > >> > > > > > Letsencrypt ACME challenge.
> > > > > > > > > > > >> > > > > > Idea for web.xml
> > > > > > > > > > > >> > > > > > <servlet>
> > > > > > > > > > > >> > > > > >
> > > > > > <servlet-name>Letsencrypt-acme</servlet-name>
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> > > > > > > > > > > >> > > > > > <init-param>
> > > > > > > > > > > >> > > > > > etc.
> > > > > > > > > > > >> > > > > > </servlet>
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > > We are using
> > > > > > > > > > > >> > > > > > @WebServlet(name =
> > "LetsencryptAcmeChallenge",
> > > > > > > > > urlPatterns =
> > > > > > > > > > > >> > > > > > {"/.well-known/acme-challenge/*"})
> > > > > > > > > > > >> > > > > > public class LetsencryptAcmeChallenge
> > extends
> > > > > > > > HttpServlet
> > > > > > > > > {
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > > /**
> > > > > > > > > > > >> > > > > > * Processes requests for both HTTP
> > > > > > <code>GET</code>
> > > > > > > > and
> > > > > > > > > > > >> > > > > > <code>POST</code> methods.
> > > > > > > > > > > >> > > > > > *
> > > > > > > > > > > >> > > > > > * @param request servlet request
> > > > > > > > > > > >> > > > > > * @param response servlet response
> > > > > > > > > > > >> > > > > > * @throws ServletException if a
> > > > > servlet-specific
> > > > > > > > error
> > > > > > > > > > > occurs
> > > > > > > > > > > >> > > > > > * @throws IOException if an I/O error
> > > occurs
> > > > > > > > > > > >> > > > > > */
> > > > > > > > > > > >> > > > > > protected void
> > > > processRequest(HttpServletRequest
> > > > > > > > > request,
> > > > > > > > > > > >> > > > > > HttpServletResponse response)
> > > > > > > > > > > >> > > > > > throws ServletException,
> IOException {
> > > > > > > > > > > >> > > > > > String requestUrl =
> > > > > > > > > request.getRequestURL().toString();
> > > > > > > > > > > >> > > > > > if
> > > > > > > > > (requestUrl.contains(".well-known/acme-challenge/"))
> > > > > > > > > > {
> > > > > > > > > > > >> > > > > > int indexFilename =
> > > > > > requestUrl.lastIndexOf("/")
> > > > > > > +
> > > > > > > > 1;
> > > > > > > > > > > >> > > > > > boolean wasError = true;
> > > > > > > > > > > >> > > > > > if (indexFilename > 0 &&
> > indexFilename <
> > > > > > > > > > > >> > requestUrl.length()) {
> > > > > > > > > > > >> > > > > > String filename =
> > > > > > > > > > requestUrl.substring(indexFilename);
> > > > > > > > > > > >> > > > > > File existingFile = new
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > >
> > > > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/"
> > > > > > > > > > > >> +
> > > > > > > > > > > >> > > > > > filename);
> > > > > > > > > > > >> > > > > > if (existingFile.exists()) {
> > > > > > > > > > > >> > > > > >
> > > response.setContentType("text/plain");
> > > > > > > > > > > >> > > > > > OutputStream out =
> > > > > > > response.getOutputStream();
> > > > > > > > > > > >> > > > > > FileInputStream in = new
> > > > > > > > > > > >> FileInputStream(existingFile);
> > > > > > > > > > > >> > > > > >
> > > > > > > FilesOperations.inputStreamToOutputStream(in,
> > > > > > > > > > out);
> > > > > > > > > > > >> > > > > > wasError = false;
> > > > > > > > > > > >> > > > > > }
> > > > > > > > > > > >> > > > > > }
> > > > > > > > > > > >> > > > > > if (wasError) {
> > > > > > > > > > > >> > > > > > throw new
> ServletException("invalid
> > > > > > requestUrl
> > > > > > > > " +
> > > > > > > > > > > >> > > requestUrl);
> > > > > > > > > > > >> > > > > > }
> > > > > > > > > > > >> > > > > > }
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > > from FilesOperations:
> > > > > > > > > > > >> > > > > > public static void
> > > > > > > > > > inputStreamToOutputStream(InputStream
> > > > > > > > > > > >> in,
> > > > > > > > > > > >> > > > > > OutputStream out) throws IOException {
> > > > > > > > > > > >> > > > > > try {
> > > > > > > > > > > >> > > > > > byte[ ] buf = new byte[32 *
> > > 1024];
> > > > > //
> > > > > > > 32K
> > > > > > > > > > buffer
> > > > > > > > > > > >> > > > > > int bytesRead;
> > > > > > > > > > > >> > > > > > while ((bytesRead =
> > in.read(buf))
> > > !=
> > > > > > -1) {
> > > > > > > > > > > >> > > > > > out.write(buf, 0,
> > bytesRead);
> > > > > > > > > > > >> > > > > > }
> > > > > > > > > > > >> > > > > > } finally {
> > > > > > > > > > > >> > > > > > if (in != null) {
> > > > > > > > > > > >> > > > > > in.close();
> > > > > > > > > > > >> > > > > > out.close();
> > > > > > > > > > > >> > > > > > }
> > > > > > > > > > > >> > > > > > }
> > > > > > > > > > > >> > > > > > }
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > > > > > *Long*:
> > > > > > > > > > > >> > > > > > > > SSL certificates have a period of
> > > expiration
> > > > > and
> > > > > > > in
> > > > > > > > > the
> > > > > > > > > > > >> case of
> > > > > > > > > > > >> > > > > > > > Letsencrypt, it's set to 3 months as
> > they
> > > > > think
> > > > > > > > > everyone
> > > > > > > > > > > >> should
> > > > > > > > > > > >> > > > have
> > > > > > > > > > > >> > > > > > the
> > > > > > > > > > > >> > > > > > > > renewal mechanism automatically.
> > > > > > > > > > > >> > > > > > > >
> > > > > > > > > > > >> > > > > > > > As the Letsencrypt is the most popular
> > SSL
> > > > > > issuing
> > > > > > > > > > > authority
> > > > > > > > > > > >> > > > (source:
> > > > > > > > > > > >> > > > > > > >
> > > > https://trends.builtwith.com/ssl/LetsEncrypt
> > > > > > ), I
> > > > > > > > > think
> > > > > > > > > > > >> Tomcat
> > > > > > > > > > > >> > > > > should
> > > > > > > > > > > >> > > > > > > have
> > > > > > > > > > > >> > > > > > > > an integration with Letsencrypt
> working
> > > > > > > flawlessly.
> > > > > > > > > > > >> > > > > > > >
> > > > > > > > > > > >> > > > > > > > We are currently using the script to
> > renew
> > > > the
> > > > > > > > > > certificate
> > > > > > > > > > > >> (I
> > > > > > > > > > > >> > can
> > > > > > > > > > > >> > > > > share
> > > > > > > > > > > >> > > > > > > our
> > > > > > > > > > > >> > > > > > > > integration details with whoever is
> > > > > interested,
> > > > > > > > please
> > > > > > > > > > > >> email me
> > > > > > > > > > > >> > > if
> > > > > > > > > > > >> > > > > you
> > > > > > > > > > > >> > > > > > > are
> > > > > > > > > > > >> > > > > > > > interested), but it's restarting
> Tomcat.
> > > > > > > > > > > >> > > > > > > >
> > > > > > > > > > > >> > > > > > > > As Tomcat shall not be restarted ever
> > > > > > (ideally), I
> > > > > > > > > think
> > > > > > > > > > > >> Tomcat
> > > > > > > > > > > >> > > > > should
> > > > > > > > > > > >> > > > > > > have
> > > > > > > > > > > >> > > > > > > > an option to reload certificate,
> > without a
> > > > > > > > dependency
> > > > > > > > > to
> > > > > > > > > > > >> Tomcat
> > > > > > > > > > > >> > > > > source
> > > > > > > > > > > >> > > > > > > code
> > > > > > > > > > > >> > > > > > > > and "hacks" like some available on
> > > > > > StackOverflow:
> > > > > > > > > > > >> > > > > > > >
> > > > > > > > > > > >> > > > > > >
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> > > > > > > > > > > >> > > > > > > ).
> > > > > > > > > > > >> > > > > > > > Those hacks are no good as:
> > > > > > > > > > > >> > > > > > > > 1) code to reload certificate should
> not
> > > run
> > > > > > > inside
> > > > > > > > > Java
> > > > > > > > > > > >> code,
> > > > > > > > > > > >> > as
> > > > > > > > > > > >> > > > > > > > letsencrypt is invoked through Linux
> > > > > > > > > > > >> > > > > > > > 2) each application uses that
> > > Stackoverflow
> > > > > hack
> > > > > > > > have
> > > > > > > > > > > >> > additional
> > > > > > > > > > > >> > > > > > compile
> > > > > > > > > > > >> > > > > > > > and run dependency set to Tomcat
> (which
> > is
> > > > > very
> > > > > > > > bad).
> > > > > > > > > > > >> > > > > > > >
> > > > > > > > > > > >> > > > > > > > I have a proposal on how this should
> be
> > > > fixed:
> > > > > > > > Tomcat
> > > > > > > > > > > should
> > > > > > > > > > > >> > > have a
> > > > > > > > > > > >> > > > > > > > server.xml options something like
> > > > > > > > > > > >> certificateReloadAfterDays or
> > > > > > > > > > > >> > > > > > > > reloadAfterDays
> > > > > > > > > > > >> > > > > > > >
> > > > > > > > > > > >> > > > > > > > I see this is moved to SSLHostConfig,
> we
> > > are
> > > > > > still
> > > > > > > > > using
> > > > > > > > > > > old
> > > > > > > > > > > >> > > > params.
> > > > > > > > > > > >> > > > > > > >
> > > > > > > > > > > >> > > > > > > > Do you agree on this feature?
> > > > > > > > > > > >> > > > > > > >
> > > > > > > > > > > >> > > > > > > > If so... I'm not lazy to try to do it
> > > > myself,
> > > > > > but
> > > > > > > > as I
> > > > > > > > > > > >> haven't
> > > > > > > > > > > >> > > ever
> > > > > > > > > > > >> > > > > > > written
> > > > > > > > > > > >> > > > > > > > Tomcat code neither know procedures (I
> > > have
> > > > > been
> > > > > > > > > coding
> > > > > > > > > > > >> > > > > professionally
> > > > > > > > > > > >> > > > > > > > since 2006, but I never committed to
> > Maven
> > > > or
> > > > > > Git
> > > > > > > > > > project
> > > > > > > > > > > >> > before,
> > > > > > > > > > > >> > > > > lol),
> > > > > > > > > > > >> > > > > > > is
> > > > > > > > > > > >> > > > > > > > there someone else who is keen on
> doing
> > > this
> > > > > > > > feature?
> > > > > > > > > > > >> > > > > > >
> > > > > > > > > > > >> > > > > > > Have a look at this:
> > > > > > > > > > > >> > > > > > >
> > > > > > > > > > > >>
> > > > > > http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> > > > > > > > > > > >> > > > > > >
> > > > > > > > > > > >> > > > > > > -chris
> > > > > > > > > > > >> > > > > > >
> > > > > > > > > > > >> > > > > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > > > > > >> > > > > > > To unsubscribe, e-mail:
> > > > > > > > > dev-unsubscribe@tomcat.apache.org
> > > > > > > > > > > >> > > > > > > For additional commands, e-mail:
> > > > > > > > > > dev-help@tomcat.apache.org
> > > > > > > > > > > >> > > > > > >
> > > > > > > > > > > >> > > > > > >
> > > > > > > > > > > >> > > > > >
> > > > > > > > > > > >> > > > >
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> >
> > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > > <
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon
> > > >
> > > Virus-free.
> > > www.avast.com
> > > <
> > >
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
> > > >
> > > <#m_-1856320879832207330_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > >
> >
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Mladen Adamović <ml...@gmail.com>.
On Wed, Dec 23, 2020 at 4:44 PM Romain Manni-Bucau <rm...@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/
> 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?
> 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 ;-)
>
> 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.
>
> Hope it makes sense.
>
>
> >
> >
> >
> >
> > > Do you see anything else which would need to change? The reloadSSL
> method
> > > was added for letsencrypt already so guess this adjustment work is
> > already
> > > done.
> >
> >
> > There are currently two options, through manager or through service
> > restart. It seems that there is no consensus here to add the 3th option.
> >
> >
> >
> >
> >
> >
> >
> > >
> > > >
> > > >
> > > > On Wed, Dec 23, 2020 at 2:01 PM Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > > wrote:
> > > >
> > > > > Le mer. 23 déc. 2020 à 12:50, Mladen Adamović <
> > > mladen.adamovic@gmail.com
> > > > >
> > > > > a
> > > > > écrit :
> > > > >
> > > > > > On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <
> > > > > rmannibucau@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I don't think so, this connector auth is only used in very
> > > particular
> > > > > > cases
> > > > > > > (= never ;)): HTTP2 - we don't care, AJP - we don't care much.
> It
> > > is
> > > > > > also a
> > > > > > > kind of automatic authorization - no password or so - so will
> > pass
> > > > and
> > > > > > not
> > > > > > > fail.
> > > > > > >
> > > > > >
> > > > > > That sounds very strange, as I have seen in the code:
> > > > > > if (req.getRemoteUserNeedsAuthorization()) {
> > > > > > ...
> > > > > > } else if (!(authenticator instanceof
> > > > > AuthenticatorBase)) {
> > > > > > ...
> > > > > > }
> > > > > >
> > > > > > public class SSLAuthenticator extends AuthenticatorBase {
> > > > > >
> > > > > >
> > > > > Sure but check what makes remoteUserNeedsAuthorization true (http2
> > and
> > > > ajp)
> > > > > and what does the block when true (authenticate(username), no
> > password
> > > or
> > > > > so).
> > > > > So not an issue IMHO.
> > > > >
> > > > >
> > > > > >
> > > > > > My point was if you have some security contraint (JWT, basic,
> > etc...)
> > > > on
> > > > > > > /*, then your servlet will not be called for letsencrypt call
> > > whereas
> > > > > if
> > > > > > > you have a valve you can still handle it properly since you
> > didn't
> > > > > enter
> > > > > > > the secured chain - a valve is before filter chain and can be
> > > before
> > > > > > > authenticators in valve chain since authenticators -
> > > > AuthenticatorBase
> > > > > -
> > > > > > > are valves.
> > > > > > >
> > > > > >
> > > > > > Authenticator Valve's seems to me to have a different treatment
> > than
> > > > > other
> > > > > > Valves which are accessed through Pipeline.
> > > > > >
> > > > >
> > > > > This is true since it can be obtained from the context and its call
> > can
> > > > be
> > > > > forced, but here again the question is when.
> > > > > If you check callers then it shouldn't be the case until you add
> > > another
> > > > > valve doing it and if so you can still set the LetsEncryptValve
> > before
> > > > and
> > > > > bypass it - can even be set on the host and not the context.
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > In other words: no code change required in tomcat internals.
> > > > > > >
> > > > > >
> > > > > > I don't understand this yet. If the implementation would use
> > > > serverl.xml
> > > > > to
> > > > > > change StandardContextValve to something else?
> > > > > >
> > > > >
> > > > > No, change nothing, just add a valve on the host for example
> through
> > > > <Valve
> > > > > className.... /> tag.
> > > > >
> > > > >
> > > > > >
> > > > > > I've tried to figure out what are you doing in meecrowave and my
> > IDE
> > > > > > (Netbeans) shows me Usage of LetsEncryptValve [no occurrences]
> > > > > >
> > > > >
> > > > > Maybe use another IDE ;) (joking ;)):
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/openwebbeans-meecrowave/blob/433a691b246f9eeda2273e794ddbb7970691cc5f/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt/LetsEncryptSetup.java#L44
> > > > > The MeecrowaveAwareInstanceCustomizer instance enables to "code"
> the
> > > > > server.xml but it is equivalent to previous proposal (<Valve/>).
> > > > >
> > > > >
> > > > > >
> > > > > > How this LetsEncryptValve is actually "injected" into meecrowave
> > > > > Pipeline ?
> > > > > > Or how it is used internally?
> > > > > > I didn't see any Reflection code on Valves or Valve base by
> > searching
> > > > > > source code.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Romain Manni-Bucau
> > > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > https://github.com/rmannibucau> |
> > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > > <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Le mer. 23 déc. 2020 à 11:23, Mladen Adamović <
> > > > > mladen.adamovic@gmail.com
> > > > > > >
> > > > > > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > > Thank you Romain, do you then think the place to check for
> ACME
> > > > Valve
> > > > > > (if
> > > > > > > > that would the be appropriate naming) would be in
> > > > > > > > CoyoteAdapter.postParseRequest line 814
> > > > > > > > before doConnectorAuthenticationAuthorization(...) ?
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau <
> > > > > > > rmannibucau@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Side note: using a servlet generally does not work if you
> > have
> > > > any
> > > > > > > > security
> > > > > > > > > on the webapp + requires a webapp whereas using a valve
> > solves
> > > > > these
> > > > > > > two
> > > > > > > > > issues.
> > > > > > > > >
> > > > > > > > > Romain Manni-Bucau
> > > > > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > > > https://github.com/rmannibucau> |
> > > > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > > > > <
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Le mer. 23 déc. 2020 à 09:15, Mladen Adamović <
> > > > > > > mladen.adamovic@gmail.com
> > > > > > > > >
> > > > > > > > > a
> > > > > > > > > écrit :
> > > > > > > > >
> > > > > > > > > > As I haven't received more replies on this topic, I'm
> > > guessing
> > > > > > > project
> > > > > > > > > > maintainers are not interested in reviewing and including
> > the
> > > > > code
> > > > > > > for
> > > > > > > > > > simpler Letsencrypt integration and discussing the
> > mentioned
> > > > SSL
> > > > > > > > > > documentation improvements?
> > > > > > > > > >
> > > > > > > > > > Enabling AMCE response servlet (good idea by default)
> would
> > > be
> > > > a
> > > > > > good
> > > > > > > > > step
> > > > > > > > > > in my opinion?
> > > > > > > > > >
> > > > > > > > > > My procedure is explained here:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
> > > > > > > > > > and the step "Configure HTTP redirect application with
> > > support
> > > > to
> > > > > > > ACME
> > > > > > > > > > challenge" could be integrated into Tomcat easily.
> > > > > > > > > >
> > > > > > > > > > In the case that is integrated, I can write a new
> improved
> > > > > > > > > > tutorial/process.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Sat, Dec 19, 2020 at 11:09 PM Mladen Adamović <
> > > > > > > > > > mladen.adamovic@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau <
> > > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > >> It moves the problem elsewhere, how would the CLI
> > > > communicate
> > > > > > with
> > > > > > > > > > tomcat?
> > > > > > > > > > >> JMX, HTTP uses a port, a file based communication
> would
> > be
> > > > > > > probably
> > > > > > > > > > worse
> > > > > > > > > > >> because of perms and other admin issues (and just not
> > > > working
> > > > > in
> > > > > > > > k8s).
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > > > I don't see other sane ways actually. So it seems a
> > > web-based
> > > > > > > manager
> > > > > > > > > > with
> > > > > > > > > > > curl is there to stay (for the time being at least).
> > > > > > > > > > >
> > > > > > > > > > > To Chris: It's somewhat weird that the user needs a web
> > > > manager
> > > > > > > just
> > > > > > > > > for
> > > > > > > > > > > curl-ing certification renewal.
> > > > > > > > > > >
> > > > > > > > > > > To everyone:
> > > > > > > > > > > I have a suggestion on improving Documentation
> regarding
> > > SSL.
> > > > > > > > > > >
> https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
> > > > > > > > > > > Currently, it states
> > > > > > > > > > > Configuration
> > > > > > > > > > > Prepare the Certificate Keystore
> > > > > > > > > > > Tomcat currently operates only on JKS, PKCS11 or PKCS12
> > > > format
> > > > > > > > > keystores.
> > > > > > > > > > >
> > > > > > > > > > > ...
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I think it should start with
> > > > > > > > > > > Configuration
> > > > > > > > > > > Option 1) Use Tomcat Native
> > > > > > > > > > > which would showcase a path to something like:
> > > > > > > > > > >
> > > > > > > > > > > <!-- Define an SSL Coyote HTTP/1.1 Connector on port
> 8443
> > > -->
> > > > > > > > > > > <Connector
> > > > > > > > > > >
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> > > > > > > > > > > port="8443"
> > > > > > > > > > > maxThreads="150"
> > > > > > > > > > > SSLEnabled="true" >
> > > > > > > > > > > <SSLHostConfig>
> > > > > > > > > > > <Certificate
> > > > > > > > > > > certificateKeyFile="conf/localhost-rsa-key.pem"
> > > > > > > > > > > certificateFile="conf/localhost-rsa-cert.pem"
> > > > > > > > > > >
> > certificateChainFile="conf/localhost-rsa-chain.pem"
> > > > > > > > > > > type="RSA"
> > > > > > > > > > > />
> > > > > > > > > > > </SSLHostConfig>
> > > > > > > > > > > </Connector>
> > > > > > > > > > >
> > > > > > > > > > > Option 2) Without Tomcat Native
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > ...
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I don't know what is the formal process for improving
> the
> > > > > > > > documentation
> > > > > > > > > > > here?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović
> <
> > > > > > > > > > >> > > mladen.adamovic@gmail.com
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > a
> > > > > > > > > > >> > > > > écrit :
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher
> > > > Schultz
> > > > > <
> > > > > > > > > > >> > > > > > chris@christopherschultz.net> wrote:
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > > > Why not use cron? You can do this with a
> > > single
> > > > > > "curl"
> > > > > > > > > > command
> > > > > > > > > > >> > and
> > > > > > > > > > >> > > > the
> > > > > > > > > > >> > > > > > > Manager+JMXProxyServlet.
> > > > > > > > > > >> > > > > > >
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > > We are not using Tomcat manager app.
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > > Why someone should be forced to use Manager,
> > to
> > > > > > > read/setup
> > > > > > > > > the
> > > > > > > > > > >> > > > > > documentation regarding JMXProxyServlet,
> > create
> > > an
> > > > > > > > > additional
> > > > > > > > > > >> > > > > > servlet (where does it have dependency on?)
> > only
> > > > to
> > > > > > > reload
> > > > > > > > > > >> > > > automatically
> > > > > > > > > > >> > > > > > certificates?
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > > I'm proposing a solution with the simple
> > > > > SSLHostConfig
> > > > > > > > > > >> parameter.
> > > > > > > > > > >> > > It's
> > > > > > > > > > >> > > > a
> > > > > > > > > > >> > > > > > user friendly. Simple, intuitive.
> > > > > > > > > > >> > > > > > No need for using manager, no need to
> create a
> > > > > > specific
> > > > > > > > > > servlet
> > > > > > > > > > >> > > > somewhere
> > > > > > > > > > >> > > > > > in your code. Just a single server.xml
> > argument.
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > > Also, *another idea*, I'm contributing this
> > code
> > > > > (see
> > > > > > > > below)
> > > > > > > > > > we
> > > > > > > > > > >> are
> > > > > > > > > > >> > > > using
> > > > > > > > > > >> > > > > > for Letsencrypt ACME challenge.
> > > > > > > > > > >> > > > > > Tomcat could also have an option, i.e. in
> > > web.xml
> > > > to
> > > > > > > > > > >> automatically
> > > > > > > > > > >> > > > > support
> > > > > > > > > > >> > > > > > Letsencrypt ACME challenge.
> > > > > > > > > > >> > > > > > Idea for web.xml
> > > > > > > > > > >> > > > > > <servlet>
> > > > > > > > > > >> > > > > >
> > > > > <servlet-name>Letsencrypt-acme</servlet-name>
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> > > > > > > > > > >> > > > > > <init-param>
> > > > > > > > > > >> > > > > > etc.
> > > > > > > > > > >> > > > > > </servlet>
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > > We are using
> > > > > > > > > > >> > > > > > @WebServlet(name =
> "LetsencryptAcmeChallenge",
> > > > > > > > urlPatterns =
> > > > > > > > > > >> > > > > > {"/.well-known/acme-challenge/*"})
> > > > > > > > > > >> > > > > > public class LetsencryptAcmeChallenge
> extends
> > > > > > > HttpServlet
> > > > > > > > {
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > > /**
> > > > > > > > > > >> > > > > > * Processes requests for both HTTP
> > > > > <code>GET</code>
> > > > > > > and
> > > > > > > > > > >> > > > > > <code>POST</code> methods.
> > > > > > > > > > >> > > > > > *
> > > > > > > > > > >> > > > > > * @param request servlet request
> > > > > > > > > > >> > > > > > * @param response servlet response
> > > > > > > > > > >> > > > > > * @throws ServletException if a
> > > > servlet-specific
> > > > > > > error
> > > > > > > > > > occurs
> > > > > > > > > > >> > > > > > * @throws IOException if an I/O error
> > occurs
> > > > > > > > > > >> > > > > > */
> > > > > > > > > > >> > > > > > protected void
> > > processRequest(HttpServletRequest
> > > > > > > > request,
> > > > > > > > > > >> > > > > > HttpServletResponse response)
> > > > > > > > > > >> > > > > > throws ServletException, IOException {
> > > > > > > > > > >> > > > > > String requestUrl =
> > > > > > > > request.getRequestURL().toString();
> > > > > > > > > > >> > > > > > if
> > > > > > > > (requestUrl.contains(".well-known/acme-challenge/"))
> > > > > > > > > {
> > > > > > > > > > >> > > > > > int indexFilename =
> > > > > requestUrl.lastIndexOf("/")
> > > > > > +
> > > > > > > 1;
> > > > > > > > > > >> > > > > > boolean wasError = true;
> > > > > > > > > > >> > > > > > if (indexFilename > 0 &&
> indexFilename <
> > > > > > > > > > >> > requestUrl.length()) {
> > > > > > > > > > >> > > > > > String filename =
> > > > > > > > > requestUrl.substring(indexFilename);
> > > > > > > > > > >> > > > > > File existingFile = new
> > > > > > > > > > >> > > > > >
> > > > > > > > > >
> > > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/"
> > > > > > > > > > >> +
> > > > > > > > > > >> > > > > > filename);
> > > > > > > > > > >> > > > > > if (existingFile.exists()) {
> > > > > > > > > > >> > > > > >
> > response.setContentType("text/plain");
> > > > > > > > > > >> > > > > > OutputStream out =
> > > > > > response.getOutputStream();
> > > > > > > > > > >> > > > > > FileInputStream in = new
> > > > > > > > > > >> FileInputStream(existingFile);
> > > > > > > > > > >> > > > > >
> > > > > > FilesOperations.inputStreamToOutputStream(in,
> > > > > > > > > out);
> > > > > > > > > > >> > > > > > wasError = false;
> > > > > > > > > > >> > > > > > }
> > > > > > > > > > >> > > > > > }
> > > > > > > > > > >> > > > > > if (wasError) {
> > > > > > > > > > >> > > > > > throw new ServletException("invalid
> > > > > requestUrl
> > > > > > > " +
> > > > > > > > > > >> > > requestUrl);
> > > > > > > > > > >> > > > > > }
> > > > > > > > > > >> > > > > > }
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > > from FilesOperations:
> > > > > > > > > > >> > > > > > public static void
> > > > > > > > > inputStreamToOutputStream(InputStream
> > > > > > > > > > >> in,
> > > > > > > > > > >> > > > > > OutputStream out) throws IOException {
> > > > > > > > > > >> > > > > > try {
> > > > > > > > > > >> > > > > > byte[ ] buf = new byte[32 *
> > 1024];
> > > > //
> > > > > > 32K
> > > > > > > > > buffer
> > > > > > > > > > >> > > > > > int bytesRead;
> > > > > > > > > > >> > > > > > while ((bytesRead =
> in.read(buf))
> > !=
> > > > > -1) {
> > > > > > > > > > >> > > > > > out.write(buf, 0,
> bytesRead);
> > > > > > > > > > >> > > > > > }
> > > > > > > > > > >> > > > > > } finally {
> > > > > > > > > > >> > > > > > if (in != null) {
> > > > > > > > > > >> > > > > > in.close();
> > > > > > > > > > >> > > > > > out.close();
> > > > > > > > > > >> > > > > > }
> > > > > > > > > > >> > > > > > }
> > > > > > > > > > >> > > > > > }
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > > > > > *Long*:
> > > > > > > > > > >> > > > > > > > SSL certificates have a period of
> > expiration
> > > > and
> > > > > > in
> > > > > > > > the
> > > > > > > > > > >> case of
> > > > > > > > > > >> > > > > > > > Letsencrypt, it's set to 3 months as
> they
> > > > think
> > > > > > > > everyone
> > > > > > > > > > >> should
> > > > > > > > > > >> > > > have
> > > > > > > > > > >> > > > > > the
> > > > > > > > > > >> > > > > > > > renewal mechanism automatically.
> > > > > > > > > > >> > > > > > > >
> > > > > > > > > > >> > > > > > > > As the Letsencrypt is the most popular
> SSL
> > > > > issuing
> > > > > > > > > > authority
> > > > > > > > > > >> > > > (source:
> > > > > > > > > > >> > > > > > > >
> > > https://trends.builtwith.com/ssl/LetsEncrypt
> > > > > ), I
> > > > > > > > think
> > > > > > > > > > >> Tomcat
> > > > > > > > > > >> > > > > should
> > > > > > > > > > >> > > > > > > have
> > > > > > > > > > >> > > > > > > > an integration with Letsencrypt working
> > > > > > flawlessly.
> > > > > > > > > > >> > > > > > > >
> > > > > > > > > > >> > > > > > > > We are currently using the script to
> renew
> > > the
> > > > > > > > > certificate
> > > > > > > > > > >> (I
> > > > > > > > > > >> > can
> > > > > > > > > > >> > > > > share
> > > > > > > > > > >> > > > > > > our
> > > > > > > > > > >> > > > > > > > integration details with whoever is
> > > > interested,
> > > > > > > please
> > > > > > > > > > >> email me
> > > > > > > > > > >> > > if
> > > > > > > > > > >> > > > > you
> > > > > > > > > > >> > > > > > > are
> > > > > > > > > > >> > > > > > > > interested), but it's restarting Tomcat.
> > > > > > > > > > >> > > > > > > >
> > > > > > > > > > >> > > > > > > > As Tomcat shall not be restarted ever
> > > > > (ideally), I
> > > > > > > > think
> > > > > > > > > > >> Tomcat
> > > > > > > > > > >> > > > > should
> > > > > > > > > > >> > > > > > > have
> > > > > > > > > > >> > > > > > > > an option to reload certificate,
> without a
> > > > > > > dependency
> > > > > > > > to
> > > > > > > > > > >> Tomcat
> > > > > > > > > > >> > > > > source
> > > > > > > > > > >> > > > > > > code
> > > > > > > > > > >> > > > > > > > and "hacks" like some available on
> > > > > StackOverflow:
> > > > > > > > > > >> > > > > > > >
> > > > > > > > > > >> > > > > > >
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> > > > > > > > > > >> > > > > > > ).
> > > > > > > > > > >> > > > > > > > Those hacks are no good as:
> > > > > > > > > > >> > > > > > > > 1) code to reload certificate should not
> > run
> > > > > > inside
> > > > > > > > Java
> > > > > > > > > > >> code,
> > > > > > > > > > >> > as
> > > > > > > > > > >> > > > > > > > letsencrypt is invoked through Linux
> > > > > > > > > > >> > > > > > > > 2) each application uses that
> > Stackoverflow
> > > > hack
> > > > > > > have
> > > > > > > > > > >> > additional
> > > > > > > > > > >> > > > > > compile
> > > > > > > > > > >> > > > > > > > and run dependency set to Tomcat (which
> is
> > > > very
> > > > > > > bad).
> > > > > > > > > > >> > > > > > > >
> > > > > > > > > > >> > > > > > > > I have a proposal on how this should be
> > > fixed:
> > > > > > > Tomcat
> > > > > > > > > > should
> > > > > > > > > > >> > > have a
> > > > > > > > > > >> > > > > > > > server.xml options something like
> > > > > > > > > > >> certificateReloadAfterDays or
> > > > > > > > > > >> > > > > > > > reloadAfterDays
> > > > > > > > > > >> > > > > > > >
> > > > > > > > > > >> > > > > > > > I see this is moved to SSLHostConfig, we
> > are
> > > > > still
> > > > > > > > using
> > > > > > > > > > old
> > > > > > > > > > >> > > > params.
> > > > > > > > > > >> > > > > > > >
> > > > > > > > > > >> > > > > > > > Do you agree on this feature?
> > > > > > > > > > >> > > > > > > >
> > > > > > > > > > >> > > > > > > > If so... I'm not lazy to try to do it
> > > myself,
> > > > > but
> > > > > > > as I
> > > > > > > > > > >> haven't
> > > > > > > > > > >> > > ever
> > > > > > > > > > >> > > > > > > written
> > > > > > > > > > >> > > > > > > > Tomcat code neither know procedures (I
> > have
> > > > been
> > > > > > > > coding
> > > > > > > > > > >> > > > > professionally
> > > > > > > > > > >> > > > > > > > since 2006, but I never committed to
> Maven
> > > or
> > > > > Git
> > > > > > > > > project
> > > > > > > > > > >> > before,
> > > > > > > > > > >> > > > > lol),
> > > > > > > > > > >> > > > > > > is
> > > > > > > > > > >> > > > > > > > there someone else who is keen on doing
> > this
> > > > > > > feature?
> > > > > > > > > > >> > > > > > >
> > > > > > > > > > >> > > > > > > Have a look at this:
> > > > > > > > > > >> > > > > > >
> > > > > > > > > > >>
> > > > > http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> > > > > > > > > > >> > > > > > >
> > > > > > > > > > >> > > > > > > -chris
> > > > > > > > > > >> > > > > > >
> > > > > > > > > > >> > > > > > >
> > > > > > > > > > >> > >
> > > > > > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > > > > > >> > > > > > > To unsubscribe, e-mail:
> > > > > > > > dev-unsubscribe@tomcat.apache.org
> > > > > > > > > > >> > > > > > > For additional commands, e-mail:
> > > > > > > > > dev-help@tomcat.apache.org
> > > > > > > > > > >> > > > > > >
> > > > > > > > > > >> > > > > > >
> > > > > > > > > > >> > > > > >
> > > > > > > > > > >> > > > >
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> > <
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon
> > >
> > Virus-free.
> > www.avast.com
> > <
> >
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
> > >
> > <#m_-1856320879832207330_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 23 déc. 2020 à 15:36, Mladen Adamović <ml...@gmail.com> a
écrit :
> On Wed, Dec 23, 2020 at 3:17 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > I'm tempted to say either provide a default tomcat-letsencrypt module
> > "ready to activate" - and I would support you in that work - or nothing
> > since tomcat is letsencryts friendly thanks its pluggable design IMHO
> >
>
> I'm not sure what you mean by tomcat-letsencrypt module, as tomcat doesn't
> have "Module" neither Letsencrypt according to Google search.
>
I meant that for me a letsencrypt work in tomcat can lead to create such a
module in the project and release it with other modules (next to jdbc
module maybe even if it is not embed by default).
>
> Tomcat is not user friendly for Letsencrypt enough according to people who
> are posting problems on Letsencrypt forums:
> https://community.letsencrypt.org/search?q=tomcat%20order%3Alatest
> you can see many people experiencing problems.
>
> Situation in Payara is better with this script:
>
> https://github.com/payara/Payara/blob/master/appserver/packager/appserver-core/src/main/resources/bin/letsencrypt.py
> (hopefully, I didn't try).
>
Well there are a few points to take into account here:
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
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
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
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.
Hope it makes sense.
>
>
>
>
> > Do you see anything else which would need to change? The reloadSSL method
> > was added for letsencrypt already so guess this adjustment work is
> already
> > done.
>
>
> There are currently two options, through manager or through service
> restart. It seems that there is no consensus here to add the 3th option.
>
>
>
>
>
>
>
> >
> > >
> > >
> > > On Wed, Dec 23, 2020 at 2:01 PM Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > > > Le mer. 23 déc. 2020 à 12:50, Mladen Adamović <
> > mladen.adamovic@gmail.com
> > > >
> > > > a
> > > > écrit :
> > > >
> > > > > On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <
> > > > rmannibucau@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > I don't think so, this connector auth is only used in very
> > particular
> > > > > cases
> > > > > > (= never ;)): HTTP2 - we don't care, AJP - we don't care much. It
> > is
> > > > > also a
> > > > > > kind of automatic authorization - no password or so - so will
> pass
> > > and
> > > > > not
> > > > > > fail.
> > > > > >
> > > > >
> > > > > That sounds very strange, as I have seen in the code:
> > > > > if (req.getRemoteUserNeedsAuthorization()) {
> > > > > ...
> > > > > } else if (!(authenticator instanceof
> > > > AuthenticatorBase)) {
> > > > > ...
> > > > > }
> > > > >
> > > > > public class SSLAuthenticator extends AuthenticatorBase {
> > > > >
> > > > >
> > > > Sure but check what makes remoteUserNeedsAuthorization true (http2
> and
> > > ajp)
> > > > and what does the block when true (authenticate(username), no
> password
> > or
> > > > so).
> > > > So not an issue IMHO.
> > > >
> > > >
> > > > >
> > > > > My point was if you have some security contraint (JWT, basic,
> etc...)
> > > on
> > > > > > /*, then your servlet will not be called for letsencrypt call
> > whereas
> > > > if
> > > > > > you have a valve you can still handle it properly since you
> didn't
> > > > enter
> > > > > > the secured chain - a valve is before filter chain and can be
> > before
> > > > > > authenticators in valve chain since authenticators -
> > > AuthenticatorBase
> > > > -
> > > > > > are valves.
> > > > > >
> > > > >
> > > > > Authenticator Valve's seems to me to have a different treatment
> than
> > > > other
> > > > > Valves which are accessed through Pipeline.
> > > > >
> > > >
> > > > This is true since it can be obtained from the context and its call
> can
> > > be
> > > > forced, but here again the question is when.
> > > > If you check callers then it shouldn't be the case until you add
> > another
> > > > valve doing it and if so you can still set the LetsEncryptValve
> before
> > > and
> > > > bypass it - can even be set on the host and not the context.
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > > > In other words: no code change required in tomcat internals.
> > > > > >
> > > > >
> > > > > I don't understand this yet. If the implementation would use
> > > serverl.xml
> > > > to
> > > > > change StandardContextValve to something else?
> > > > >
> > > >
> > > > No, change nothing, just add a valve on the host for example through
> > > <Valve
> > > > className.... /> tag.
> > > >
> > > >
> > > > >
> > > > > I've tried to figure out what are you doing in meecrowave and my
> IDE
> > > > > (Netbeans) shows me Usage of LetsEncryptValve [no occurrences]
> > > > >
> > > >
> > > > Maybe use another IDE ;) (joking ;)):
> > > >
> > > >
> > >
> >
> https://github.com/apache/openwebbeans-meecrowave/blob/433a691b246f9eeda2273e794ddbb7970691cc5f/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt/LetsEncryptSetup.java#L44
> > > > The MeecrowaveAwareInstanceCustomizer instance enables to "code" the
> > > > server.xml but it is equivalent to previous proposal (<Valve/>).
> > > >
> > > >
> > > > >
> > > > > How this LetsEncryptValve is actually "injected" into meecrowave
> > > > Pipeline ?
> > > > > Or how it is used internally?
> > > > > I didn't see any Reflection code on Valves or Valve base by
> searching
> > > > > source code.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > https://github.com/rmannibucau> |
> > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > > >
> > > > > >
> > > > > >
> > > > > > Le mer. 23 déc. 2020 à 11:23, Mladen Adamović <
> > > > mladen.adamovic@gmail.com
> > > > > >
> > > > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > Thank you Romain, do you then think the place to check for ACME
> > > Valve
> > > > > (if
> > > > > > > that would the be appropriate naming) would be in
> > > > > > > CoyoteAdapter.postParseRequest line 814
> > > > > > > before doConnectorAuthenticationAuthorization(...) ?
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau <
> > > > > > rmannibucau@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Side note: using a servlet generally does not work if you
> have
> > > any
> > > > > > > security
> > > > > > > > on the webapp + requires a webapp whereas using a valve
> solves
> > > > these
> > > > > > two
> > > > > > > > issues.
> > > > > > > >
> > > > > > > > Romain Manni-Bucau
> > > > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > > https://github.com/rmannibucau> |
> > > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > > > <
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Le mer. 23 déc. 2020 à 09:15, Mladen Adamović <
> > > > > > mladen.adamovic@gmail.com
> > > > > > > >
> > > > > > > > a
> > > > > > > > écrit :
> > > > > > > >
> > > > > > > > > As I haven't received more replies on this topic, I'm
> > guessing
> > > > > > project
> > > > > > > > > maintainers are not interested in reviewing and including
> the
> > > > code
> > > > > > for
> > > > > > > > > simpler Letsencrypt integration and discussing the
> mentioned
> > > SSL
> > > > > > > > > documentation improvements?
> > > > > > > > >
> > > > > > > > > Enabling AMCE response servlet (good idea by default) would
> > be
> > > a
> > > > > good
> > > > > > > > step
> > > > > > > > > in my opinion?
> > > > > > > > >
> > > > > > > > > My procedure is explained here:
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
> > > > > > > > > and the step "Configure HTTP redirect application with
> > support
> > > to
> > > > > > ACME
> > > > > > > > > challenge" could be integrated into Tomcat easily.
> > > > > > > > >
> > > > > > > > > In the case that is integrated, I can write a new improved
> > > > > > > > > tutorial/process.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Sat, Dec 19, 2020 at 11:09 PM Mladen Adamović <
> > > > > > > > > mladen.adamovic@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau <
> > > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > >> It moves the problem elsewhere, how would the CLI
> > > communicate
> > > > > with
> > > > > > > > > tomcat?
> > > > > > > > > >> JMX, HTTP uses a port, a file based communication would
> be
> > > > > > probably
> > > > > > > > > worse
> > > > > > > > > >> because of perms and other admin issues (and just not
> > > working
> > > > in
> > > > > > > k8s).
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > > > I don't see other sane ways actually. So it seems a
> > web-based
> > > > > > manager
> > > > > > > > > with
> > > > > > > > > > curl is there to stay (for the time being at least).
> > > > > > > > > >
> > > > > > > > > > To Chris: It's somewhat weird that the user needs a web
> > > manager
> > > > > > just
> > > > > > > > for
> > > > > > > > > > curl-ing certification renewal.
> > > > > > > > > >
> > > > > > > > > > To everyone:
> > > > > > > > > > I have a suggestion on improving Documentation regarding
> > SSL.
> > > > > > > > > > https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
> > > > > > > > > > Currently, it states
> > > > > > > > > > Configuration
> > > > > > > > > > Prepare the Certificate Keystore
> > > > > > > > > > Tomcat currently operates only on JKS, PKCS11 or PKCS12
> > > format
> > > > > > > > keystores.
> > > > > > > > > >
> > > > > > > > > > ...
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I think it should start with
> > > > > > > > > > Configuration
> > > > > > > > > > Option 1) Use Tomcat Native
> > > > > > > > > > which would showcase a path to something like:
> > > > > > > > > >
> > > > > > > > > > <!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443
> > -->
> > > > > > > > > > <Connector
> > > > > > > > > > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > > > > > > > > > port="8443"
> > > > > > > > > > maxThreads="150"
> > > > > > > > > > SSLEnabled="true" >
> > > > > > > > > > <SSLHostConfig>
> > > > > > > > > > <Certificate
> > > > > > > > > > certificateKeyFile="conf/localhost-rsa-key.pem"
> > > > > > > > > > certificateFile="conf/localhost-rsa-cert.pem"
> > > > > > > > > >
> certificateChainFile="conf/localhost-rsa-chain.pem"
> > > > > > > > > > type="RSA"
> > > > > > > > > > />
> > > > > > > > > > </SSLHostConfig>
> > > > > > > > > > </Connector>
> > > > > > > > > >
> > > > > > > > > > Option 2) Without Tomcat Native
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > ...
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I don't know what is the formal process for improving the
> > > > > > > documentation
> > > > > > > > > > here?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> > > > > > > > > >> > > mladen.adamovic@gmail.com
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > a
> > > > > > > > > >> > > > > écrit :
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher
> > > Schultz
> > > > <
> > > > > > > > > >> > > > > > chris@christopherschultz.net> wrote:
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > > Why not use cron? You can do this with a
> > single
> > > > > "curl"
> > > > > > > > > command
> > > > > > > > > >> > and
> > > > > > > > > >> > > > the
> > > > > > > > > >> > > > > > > Manager+JMXProxyServlet.
> > > > > > > > > >> > > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > We are not using Tomcat manager app.
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > Why someone should be forced to use Manager,
> to
> > > > > > read/setup
> > > > > > > > the
> > > > > > > > > >> > > > > > documentation regarding JMXProxyServlet,
> create
> > an
> > > > > > > > additional
> > > > > > > > > >> > > > > > servlet (where does it have dependency on?)
> only
> > > to
> > > > > > reload
> > > > > > > > > >> > > > automatically
> > > > > > > > > >> > > > > > certificates?
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > I'm proposing a solution with the simple
> > > > SSLHostConfig
> > > > > > > > > >> parameter.
> > > > > > > > > >> > > It's
> > > > > > > > > >> > > > a
> > > > > > > > > >> > > > > > user friendly. Simple, intuitive.
> > > > > > > > > >> > > > > > No need for using manager, no need to create a
> > > > > specific
> > > > > > > > > servlet
> > > > > > > > > >> > > > somewhere
> > > > > > > > > >> > > > > > in your code. Just a single server.xml
> argument.
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > Also, *another idea*, I'm contributing this
> code
> > > > (see
> > > > > > > below)
> > > > > > > > > we
> > > > > > > > > >> are
> > > > > > > > > >> > > > using
> > > > > > > > > >> > > > > > for Letsencrypt ACME challenge.
> > > > > > > > > >> > > > > > Tomcat could also have an option, i.e. in
> > web.xml
> > > to
> > > > > > > > > >> automatically
> > > > > > > > > >> > > > > support
> > > > > > > > > >> > > > > > Letsencrypt ACME challenge.
> > > > > > > > > >> > > > > > Idea for web.xml
> > > > > > > > > >> > > > > > <servlet>
> > > > > > > > > >> > > > > >
> > > > <servlet-name>Letsencrypt-acme</servlet-name>
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> > > > > > > > > >> > > > > > <init-param>
> > > > > > > > > >> > > > > > etc.
> > > > > > > > > >> > > > > > </servlet>
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > We are using
> > > > > > > > > >> > > > > > @WebServlet(name = "LetsencryptAcmeChallenge",
> > > > > > > urlPatterns =
> > > > > > > > > >> > > > > > {"/.well-known/acme-challenge/*"})
> > > > > > > > > >> > > > > > public class LetsencryptAcmeChallenge extends
> > > > > > HttpServlet
> > > > > > > {
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > /**
> > > > > > > > > >> > > > > > * Processes requests for both HTTP
> > > > <code>GET</code>
> > > > > > and
> > > > > > > > > >> > > > > > <code>POST</code> methods.
> > > > > > > > > >> > > > > > *
> > > > > > > > > >> > > > > > * @param request servlet request
> > > > > > > > > >> > > > > > * @param response servlet response
> > > > > > > > > >> > > > > > * @throws ServletException if a
> > > servlet-specific
> > > > > > error
> > > > > > > > > occurs
> > > > > > > > > >> > > > > > * @throws IOException if an I/O error
> occurs
> > > > > > > > > >> > > > > > */
> > > > > > > > > >> > > > > > protected void
> > processRequest(HttpServletRequest
> > > > > > > request,
> > > > > > > > > >> > > > > > HttpServletResponse response)
> > > > > > > > > >> > > > > > throws ServletException, IOException {
> > > > > > > > > >> > > > > > String requestUrl =
> > > > > > > request.getRequestURL().toString();
> > > > > > > > > >> > > > > > if
> > > > > > > (requestUrl.contains(".well-known/acme-challenge/"))
> > > > > > > > {
> > > > > > > > > >> > > > > > int indexFilename =
> > > > requestUrl.lastIndexOf("/")
> > > > > +
> > > > > > 1;
> > > > > > > > > >> > > > > > boolean wasError = true;
> > > > > > > > > >> > > > > > if (indexFilename > 0 && indexFilename <
> > > > > > > > > >> > requestUrl.length()) {
> > > > > > > > > >> > > > > > String filename =
> > > > > > > > requestUrl.substring(indexFilename);
> > > > > > > > > >> > > > > > File existingFile = new
> > > > > > > > > >> > > > > >
> > > > > > > > >
> > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/"
> > > > > > > > > >> +
> > > > > > > > > >> > > > > > filename);
> > > > > > > > > >> > > > > > if (existingFile.exists()) {
> > > > > > > > > >> > > > > >
> response.setContentType("text/plain");
> > > > > > > > > >> > > > > > OutputStream out =
> > > > > response.getOutputStream();
> > > > > > > > > >> > > > > > FileInputStream in = new
> > > > > > > > > >> FileInputStream(existingFile);
> > > > > > > > > >> > > > > >
> > > > > FilesOperations.inputStreamToOutputStream(in,
> > > > > > > > out);
> > > > > > > > > >> > > > > > wasError = false;
> > > > > > > > > >> > > > > > }
> > > > > > > > > >> > > > > > }
> > > > > > > > > >> > > > > > if (wasError) {
> > > > > > > > > >> > > > > > throw new ServletException("invalid
> > > > requestUrl
> > > > > > " +
> > > > > > > > > >> > > requestUrl);
> > > > > > > > > >> > > > > > }
> > > > > > > > > >> > > > > > }
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > from FilesOperations:
> > > > > > > > > >> > > > > > public static void
> > > > > > > > inputStreamToOutputStream(InputStream
> > > > > > > > > >> in,
> > > > > > > > > >> > > > > > OutputStream out) throws IOException {
> > > > > > > > > >> > > > > > try {
> > > > > > > > > >> > > > > > byte[ ] buf = new byte[32 *
> 1024];
> > > //
> > > > > 32K
> > > > > > > > buffer
> > > > > > > > > >> > > > > > int bytesRead;
> > > > > > > > > >> > > > > > while ((bytesRead = in.read(buf))
> !=
> > > > -1) {
> > > > > > > > > >> > > > > > out.write(buf, 0, bytesRead);
> > > > > > > > > >> > > > > > }
> > > > > > > > > >> > > > > > } finally {
> > > > > > > > > >> > > > > > if (in != null) {
> > > > > > > > > >> > > > > > in.close();
> > > > > > > > > >> > > > > > out.close();
> > > > > > > > > >> > > > > > }
> > > > > > > > > >> > > > > > }
> > > > > > > > > >> > > > > > }
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > > > > > *Long*:
> > > > > > > > > >> > > > > > > > SSL certificates have a period of
> expiration
> > > and
> > > > > in
> > > > > > > the
> > > > > > > > > >> case of
> > > > > > > > > >> > > > > > > > Letsencrypt, it's set to 3 months as they
> > > think
> > > > > > > everyone
> > > > > > > > > >> should
> > > > > > > > > >> > > > have
> > > > > > > > > >> > > > > > the
> > > > > > > > > >> > > > > > > > renewal mechanism automatically.
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > As the Letsencrypt is the most popular SSL
> > > > issuing
> > > > > > > > > authority
> > > > > > > > > >> > > > (source:
> > > > > > > > > >> > > > > > > >
> > https://trends.builtwith.com/ssl/LetsEncrypt
> > > > ), I
> > > > > > > think
> > > > > > > > > >> Tomcat
> > > > > > > > > >> > > > > should
> > > > > > > > > >> > > > > > > have
> > > > > > > > > >> > > > > > > > an integration with Letsencrypt working
> > > > > flawlessly.
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > We are currently using the script to renew
> > the
> > > > > > > > certificate
> > > > > > > > > >> (I
> > > > > > > > > >> > can
> > > > > > > > > >> > > > > share
> > > > > > > > > >> > > > > > > our
> > > > > > > > > >> > > > > > > > integration details with whoever is
> > > interested,
> > > > > > please
> > > > > > > > > >> email me
> > > > > > > > > >> > > if
> > > > > > > > > >> > > > > you
> > > > > > > > > >> > > > > > > are
> > > > > > > > > >> > > > > > > > interested), but it's restarting Tomcat.
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > As Tomcat shall not be restarted ever
> > > > (ideally), I
> > > > > > > think
> > > > > > > > > >> Tomcat
> > > > > > > > > >> > > > > should
> > > > > > > > > >> > > > > > > have
> > > > > > > > > >> > > > > > > > an option to reload certificate, without a
> > > > > > dependency
> > > > > > > to
> > > > > > > > > >> Tomcat
> > > > > > > > > >> > > > > source
> > > > > > > > > >> > > > > > > code
> > > > > > > > > >> > > > > > > > and "hacks" like some available on
> > > > StackOverflow:
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> > > > > > > > > >> > > > > > > ).
> > > > > > > > > >> > > > > > > > Those hacks are no good as:
> > > > > > > > > >> > > > > > > > 1) code to reload certificate should not
> run
> > > > > inside
> > > > > > > Java
> > > > > > > > > >> code,
> > > > > > > > > >> > as
> > > > > > > > > >> > > > > > > > letsencrypt is invoked through Linux
> > > > > > > > > >> > > > > > > > 2) each application uses that
> Stackoverflow
> > > hack
> > > > > > have
> > > > > > > > > >> > additional
> > > > > > > > > >> > > > > > compile
> > > > > > > > > >> > > > > > > > and run dependency set to Tomcat (which is
> > > very
> > > > > > bad).
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > I have a proposal on how this should be
> > fixed:
> > > > > > Tomcat
> > > > > > > > > should
> > > > > > > > > >> > > have a
> > > > > > > > > >> > > > > > > > server.xml options something like
> > > > > > > > > >> certificateReloadAfterDays or
> > > > > > > > > >> > > > > > > > reloadAfterDays
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > I see this is moved to SSLHostConfig, we
> are
> > > > still
> > > > > > > using
> > > > > > > > > old
> > > > > > > > > >> > > > params.
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > Do you agree on this feature?
> > > > > > > > > >> > > > > > > >
> > > > > > > > > >> > > > > > > > If so... I'm not lazy to try to do it
> > myself,
> > > > but
> > > > > > as I
> > > > > > > > > >> haven't
> > > > > > > > > >> > > ever
> > > > > > > > > >> > > > > > > written
> > > > > > > > > >> > > > > > > > Tomcat code neither know procedures (I
> have
> > > been
> > > > > > > coding
> > > > > > > > > >> > > > > professionally
> > > > > > > > > >> > > > > > > > since 2006, but I never committed to Maven
> > or
> > > > Git
> > > > > > > > project
> > > > > > > > > >> > before,
> > > > > > > > > >> > > > > lol),
> > > > > > > > > >> > > > > > > is
> > > > > > > > > >> > > > > > > > there someone else who is keen on doing
> this
> > > > > > feature?
> > > > > > > > > >> > > > > > >
> > > > > > > > > >> > > > > > > Have a look at this:
> > > > > > > > > >> > > > > > >
> > > > > > > > > >>
> > > > http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> > > > > > > > > >> > > > > > >
> > > > > > > > > >> > > > > > > -chris
> > > > > > > > > >> > > > > > >
> > > > > > > > > >> > > > > > >
> > > > > > > > > >> > >
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > >> > > > > > > To unsubscribe, e-mail:
> > > > > > > dev-unsubscribe@tomcat.apache.org
> > > > > > > > > >> > > > > > > For additional commands, e-mail:
> > > > > > > > dev-help@tomcat.apache.org
> > > > > > > > > >> > > > > > >
> > > > > > > > > >> > > > > > >
> > > > > > > > > >> > > > > >
> > > > > > > > > >> > > > >
> > > > > > > > > >> > > >
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
> <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon
> >
> Virus-free.
> www.avast.com
> <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link
> >
> <#m_-1856320879832207330_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Mladen Adamović <ml...@gmail.com>.
On Wed, Dec 23, 2020 at 3:17 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> I'm tempted to say either provide a default tomcat-letsencrypt module
> "ready to activate" - and I would support you in that work - or nothing
> since tomcat is letsencryts friendly thanks its pluggable design IMHO
>
I'm not sure what you mean by tomcat-letsencrypt module, as tomcat doesn't
have "Module" neither Letsencrypt according to Google search.
Tomcat is not user friendly for Letsencrypt enough according to people who
are posting problems on Letsencrypt forums:
https://community.letsencrypt.org/search?q=tomcat%20order%3Alatest
you can see many people experiencing problems.
Situation in Payara is better with this script:
https://github.com/payara/Payara/blob/master/appserver/packager/appserver-core/src/main/resources/bin/letsencrypt.py
(hopefully, I didn't try).
> Do you see anything else which would need to change? The reloadSSL method
> was added for letsencrypt already so guess this adjustment work is already
> done.
There are currently two options, through manager or through service
restart. It seems that there is no consensus here to add the 3th option.
>
> >
> >
> > On Wed, Dec 23, 2020 at 2:01 PM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > Le mer. 23 déc. 2020 à 12:50, Mladen Adamović <
> mladen.adamovic@gmail.com
> > >
> > > a
> > > écrit :
> > >
> > > > On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <
> > > rmannibucau@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > I don't think so, this connector auth is only used in very
> particular
> > > > cases
> > > > > (= never ;)): HTTP2 - we don't care, AJP - we don't care much. It
> is
> > > > also a
> > > > > kind of automatic authorization - no password or so - so will pass
> > and
> > > > not
> > > > > fail.
> > > > >
> > > >
> > > > That sounds very strange, as I have seen in the code:
> > > > if (req.getRemoteUserNeedsAuthorization()) {
> > > > ...
> > > > } else if (!(authenticator instanceof
> > > AuthenticatorBase)) {
> > > > ...
> > > > }
> > > >
> > > > public class SSLAuthenticator extends AuthenticatorBase {
> > > >
> > > >
> > > Sure but check what makes remoteUserNeedsAuthorization true (http2 and
> > ajp)
> > > and what does the block when true (authenticate(username), no password
> or
> > > so).
> > > So not an issue IMHO.
> > >
> > >
> > > >
> > > > My point was if you have some security contraint (JWT, basic, etc...)
> > on
> > > > > /*, then your servlet will not be called for letsencrypt call
> whereas
> > > if
> > > > > you have a valve you can still handle it properly since you didn't
> > > enter
> > > > > the secured chain - a valve is before filter chain and can be
> before
> > > > > authenticators in valve chain since authenticators -
> > AuthenticatorBase
> > > -
> > > > > are valves.
> > > > >
> > > >
> > > > Authenticator Valve's seems to me to have a different treatment than
> > > other
> > > > Valves which are accessed through Pipeline.
> > > >
> > >
> > > This is true since it can be obtained from the context and its call can
> > be
> > > forced, but here again the question is when.
> > > If you check callers then it shouldn't be the case until you add
> another
> > > valve doing it and if so you can still set the LetsEncryptValve before
> > and
> > > bypass it - can even be set on the host and not the context.
> > >
> > >
> > > >
> > > >
> > > >
> > > > > In other words: no code change required in tomcat internals.
> > > > >
> > > >
> > > > I don't understand this yet. If the implementation would use
> > serverl.xml
> > > to
> > > > change StandardContextValve to something else?
> > > >
> > >
> > > No, change nothing, just add a valve on the host for example through
> > <Valve
> > > className.... /> tag.
> > >
> > >
> > > >
> > > > I've tried to figure out what are you doing in meecrowave and my IDE
> > > > (Netbeans) shows me Usage of LetsEncryptValve [no occurrences]
> > > >
> > >
> > > Maybe use another IDE ;) (joking ;)):
> > >
> > >
> >
> https://github.com/apache/openwebbeans-meecrowave/blob/433a691b246f9eeda2273e794ddbb7970691cc5f/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt/LetsEncryptSetup.java#L44
> > > The MeecrowaveAwareInstanceCustomizer instance enables to "code" the
> > > server.xml but it is equivalent to previous proposal (<Valve/>).
> > >
> > >
> > > >
> > > > How this LetsEncryptValve is actually "injected" into meecrowave
> > > Pipeline ?
> > > > Or how it is used internally?
> > > > I didn't see any Reflection code on Valves or Valve base by searching
> > > > source code.
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > <
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > >
> > > > >
> > > > >
> > > > > Le mer. 23 déc. 2020 à 11:23, Mladen Adamović <
> > > mladen.adamovic@gmail.com
> > > > >
> > > > > a
> > > > > écrit :
> > > > >
> > > > > > Thank you Romain, do you then think the place to check for ACME
> > Valve
> > > > (if
> > > > > > that would the be appropriate naming) would be in
> > > > > > CoyoteAdapter.postParseRequest line 814
> > > > > > before doConnectorAuthenticationAuthorization(...) ?
> > > > > >
> > > > > >
> > > > > > On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau <
> > > > > rmannibucau@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Side note: using a servlet generally does not work if you have
> > any
> > > > > > security
> > > > > > > on the webapp + requires a webapp whereas using a valve solves
> > > these
> > > > > two
> > > > > > > issues.
> > > > > > >
> > > > > > > Romain Manni-Bucau
> > > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > https://github.com/rmannibucau> |
> > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > > <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Le mer. 23 déc. 2020 à 09:15, Mladen Adamović <
> > > > > mladen.adamovic@gmail.com
> > > > > > >
> > > > > > > a
> > > > > > > écrit :
> > > > > > >
> > > > > > > > As I haven't received more replies on this topic, I'm
> guessing
> > > > > project
> > > > > > > > maintainers are not interested in reviewing and including the
> > > code
> > > > > for
> > > > > > > > simpler Letsencrypt integration and discussing the mentioned
> > SSL
> > > > > > > > documentation improvements?
> > > > > > > >
> > > > > > > > Enabling AMCE response servlet (good idea by default) would
> be
> > a
> > > > good
> > > > > > > step
> > > > > > > > in my opinion?
> > > > > > > >
> > > > > > > > My procedure is explained here:
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
> > > > > > > > and the step "Configure HTTP redirect application with
> support
> > to
> > > > > ACME
> > > > > > > > challenge" could be integrated into Tomcat easily.
> > > > > > > >
> > > > > > > > In the case that is integrated, I can write a new improved
> > > > > > > > tutorial/process.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Sat, Dec 19, 2020 at 11:09 PM Mladen Adamović <
> > > > > > > > mladen.adamovic@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau <
> > > > > > > > rmannibucau@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > >> It moves the problem elsewhere, how would the CLI
> > communicate
> > > > with
> > > > > > > > tomcat?
> > > > > > > > >> JMX, HTTP uses a port, a file based communication would be
> > > > > probably
> > > > > > > > worse
> > > > > > > > >> because of perms and other admin issues (and just not
> > working
> > > in
> > > > > > k8s).
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > > I don't see other sane ways actually. So it seems a
> web-based
> > > > > manager
> > > > > > > > with
> > > > > > > > > curl is there to stay (for the time being at least).
> > > > > > > > >
> > > > > > > > > To Chris: It's somewhat weird that the user needs a web
> > manager
> > > > > just
> > > > > > > for
> > > > > > > > > curl-ing certification renewal.
> > > > > > > > >
> > > > > > > > > To everyone:
> > > > > > > > > I have a suggestion on improving Documentation regarding
> SSL.
> > > > > > > > > https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
> > > > > > > > > Currently, it states
> > > > > > > > > Configuration
> > > > > > > > > Prepare the Certificate Keystore
> > > > > > > > > Tomcat currently operates only on JKS, PKCS11 or PKCS12
> > format
> > > > > > > keystores.
> > > > > > > > >
> > > > > > > > > ...
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I think it should start with
> > > > > > > > > Configuration
> > > > > > > > > Option 1) Use Tomcat Native
> > > > > > > > > which would showcase a path to something like:
> > > > > > > > >
> > > > > > > > > <!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443
> -->
> > > > > > > > > <Connector
> > > > > > > > > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > > > > > > > > port="8443"
> > > > > > > > > maxThreads="150"
> > > > > > > > > SSLEnabled="true" >
> > > > > > > > > <SSLHostConfig>
> > > > > > > > > <Certificate
> > > > > > > > > certificateKeyFile="conf/localhost-rsa-key.pem"
> > > > > > > > > certificateFile="conf/localhost-rsa-cert.pem"
> > > > > > > > > certificateChainFile="conf/localhost-rsa-chain.pem"
> > > > > > > > > type="RSA"
> > > > > > > > > />
> > > > > > > > > </SSLHostConfig>
> > > > > > > > > </Connector>
> > > > > > > > >
> > > > > > > > > Option 2) Without Tomcat Native
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ...
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I don't know what is the formal process for improving the
> > > > > > documentation
> > > > > > > > > here?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > >
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> > > > > > > > >> > > mladen.adamovic@gmail.com
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > a
> > > > > > > > >> > > > > écrit :
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher
> > Schultz
> > > <
> > > > > > > > >> > > > > > chris@christopherschultz.net> wrote:
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > > Why not use cron? You can do this with a
> single
> > > > "curl"
> > > > > > > > command
> > > > > > > > >> > and
> > > > > > > > >> > > > the
> > > > > > > > >> > > > > > > Manager+JMXProxyServlet.
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > We are not using Tomcat manager app.
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > Why someone should be forced to use Manager, to
> > > > > read/setup
> > > > > > > the
> > > > > > > > >> > > > > > documentation regarding JMXProxyServlet, create
> an
> > > > > > > additional
> > > > > > > > >> > > > > > servlet (where does it have dependency on?) only
> > to
> > > > > reload
> > > > > > > > >> > > > automatically
> > > > > > > > >> > > > > > certificates?
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > I'm proposing a solution with the simple
> > > SSLHostConfig
> > > > > > > > >> parameter.
> > > > > > > > >> > > It's
> > > > > > > > >> > > > a
> > > > > > > > >> > > > > > user friendly. Simple, intuitive.
> > > > > > > > >> > > > > > No need for using manager, no need to create a
> > > > specific
> > > > > > > > servlet
> > > > > > > > >> > > > somewhere
> > > > > > > > >> > > > > > in your code. Just a single server.xml argument.
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > Also, *another idea*, I'm contributing this code
> > > (see
> > > > > > below)
> > > > > > > > we
> > > > > > > > >> are
> > > > > > > > >> > > > using
> > > > > > > > >> > > > > > for Letsencrypt ACME challenge.
> > > > > > > > >> > > > > > Tomcat could also have an option, i.e. in
> web.xml
> > to
> > > > > > > > >> automatically
> > > > > > > > >> > > > > support
> > > > > > > > >> > > > > > Letsencrypt ACME challenge.
> > > > > > > > >> > > > > > Idea for web.xml
> > > > > > > > >> > > > > > <servlet>
> > > > > > > > >> > > > > >
> > > <servlet-name>Letsencrypt-acme</servlet-name>
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > >
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> > > > > > > > >> > > > > > <init-param>
> > > > > > > > >> > > > > > etc.
> > > > > > > > >> > > > > > </servlet>
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > We are using
> > > > > > > > >> > > > > > @WebServlet(name = "LetsencryptAcmeChallenge",
> > > > > > urlPatterns =
> > > > > > > > >> > > > > > {"/.well-known/acme-challenge/*"})
> > > > > > > > >> > > > > > public class LetsencryptAcmeChallenge extends
> > > > > HttpServlet
> > > > > > {
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > /**
> > > > > > > > >> > > > > > * Processes requests for both HTTP
> > > <code>GET</code>
> > > > > and
> > > > > > > > >> > > > > > <code>POST</code> methods.
> > > > > > > > >> > > > > > *
> > > > > > > > >> > > > > > * @param request servlet request
> > > > > > > > >> > > > > > * @param response servlet response
> > > > > > > > >> > > > > > * @throws ServletException if a
> > servlet-specific
> > > > > error
> > > > > > > > occurs
> > > > > > > > >> > > > > > * @throws IOException if an I/O error occurs
> > > > > > > > >> > > > > > */
> > > > > > > > >> > > > > > protected void
> processRequest(HttpServletRequest
> > > > > > request,
> > > > > > > > >> > > > > > HttpServletResponse response)
> > > > > > > > >> > > > > > throws ServletException, IOException {
> > > > > > > > >> > > > > > String requestUrl =
> > > > > > request.getRequestURL().toString();
> > > > > > > > >> > > > > > if
> > > > > > (requestUrl.contains(".well-known/acme-challenge/"))
> > > > > > > {
> > > > > > > > >> > > > > > int indexFilename =
> > > requestUrl.lastIndexOf("/")
> > > > +
> > > > > 1;
> > > > > > > > >> > > > > > boolean wasError = true;
> > > > > > > > >> > > > > > if (indexFilename > 0 && indexFilename <
> > > > > > > > >> > requestUrl.length()) {
> > > > > > > > >> > > > > > String filename =
> > > > > > > requestUrl.substring(indexFilename);
> > > > > > > > >> > > > > > File existingFile = new
> > > > > > > > >> > > > > >
> > > > > > > >
> File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/"
> > > > > > > > >> +
> > > > > > > > >> > > > > > filename);
> > > > > > > > >> > > > > > if (existingFile.exists()) {
> > > > > > > > >> > > > > > response.setContentType("text/plain");
> > > > > > > > >> > > > > > OutputStream out =
> > > > response.getOutputStream();
> > > > > > > > >> > > > > > FileInputStream in = new
> > > > > > > > >> FileInputStream(existingFile);
> > > > > > > > >> > > > > >
> > > > FilesOperations.inputStreamToOutputStream(in,
> > > > > > > out);
> > > > > > > > >> > > > > > wasError = false;
> > > > > > > > >> > > > > > }
> > > > > > > > >> > > > > > }
> > > > > > > > >> > > > > > if (wasError) {
> > > > > > > > >> > > > > > throw new ServletException("invalid
> > > requestUrl
> > > > > " +
> > > > > > > > >> > > requestUrl);
> > > > > > > > >> > > > > > }
> > > > > > > > >> > > > > > }
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > from FilesOperations:
> > > > > > > > >> > > > > > public static void
> > > > > > > inputStreamToOutputStream(InputStream
> > > > > > > > >> in,
> > > > > > > > >> > > > > > OutputStream out) throws IOException {
> > > > > > > > >> > > > > > try {
> > > > > > > > >> > > > > > byte[ ] buf = new byte[32 * 1024];
> > //
> > > > 32K
> > > > > > > buffer
> > > > > > > > >> > > > > > int bytesRead;
> > > > > > > > >> > > > > > while ((bytesRead = in.read(buf)) !=
> > > -1) {
> > > > > > > > >> > > > > > out.write(buf, 0, bytesRead);
> > > > > > > > >> > > > > > }
> > > > > > > > >> > > > > > } finally {
> > > > > > > > >> > > > > > if (in != null) {
> > > > > > > > >> > > > > > in.close();
> > > > > > > > >> > > > > > out.close();
> > > > > > > > >> > > > > > }
> > > > > > > > >> > > > > > }
> > > > > > > > >> > > > > > }
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > > > *Long*:
> > > > > > > > >> > > > > > > > SSL certificates have a period of expiration
> > and
> > > > in
> > > > > > the
> > > > > > > > >> case of
> > > > > > > > >> > > > > > > > Letsencrypt, it's set to 3 months as they
> > think
> > > > > > everyone
> > > > > > > > >> should
> > > > > > > > >> > > > have
> > > > > > > > >> > > > > > the
> > > > > > > > >> > > > > > > > renewal mechanism automatically.
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > As the Letsencrypt is the most popular SSL
> > > issuing
> > > > > > > > authority
> > > > > > > > >> > > > (source:
> > > > > > > > >> > > > > > > >
> https://trends.builtwith.com/ssl/LetsEncrypt
> > > ), I
> > > > > > think
> > > > > > > > >> Tomcat
> > > > > > > > >> > > > > should
> > > > > > > > >> > > > > > > have
> > > > > > > > >> > > > > > > > an integration with Letsencrypt working
> > > > flawlessly.
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > We are currently using the script to renew
> the
> > > > > > > certificate
> > > > > > > > >> (I
> > > > > > > > >> > can
> > > > > > > > >> > > > > share
> > > > > > > > >> > > > > > > our
> > > > > > > > >> > > > > > > > integration details with whoever is
> > interested,
> > > > > please
> > > > > > > > >> email me
> > > > > > > > >> > > if
> > > > > > > > >> > > > > you
> > > > > > > > >> > > > > > > are
> > > > > > > > >> > > > > > > > interested), but it's restarting Tomcat.
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > As Tomcat shall not be restarted ever
> > > (ideally), I
> > > > > > think
> > > > > > > > >> Tomcat
> > > > > > > > >> > > > > should
> > > > > > > > >> > > > > > > have
> > > > > > > > >> > > > > > > > an option to reload certificate, without a
> > > > > dependency
> > > > > > to
> > > > > > > > >> Tomcat
> > > > > > > > >> > > > > source
> > > > > > > > >> > > > > > > code
> > > > > > > > >> > > > > > > > and "hacks" like some available on
> > > StackOverflow:
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > >
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> > > > > > > > >> > > > > > > ).
> > > > > > > > >> > > > > > > > Those hacks are no good as:
> > > > > > > > >> > > > > > > > 1) code to reload certificate should not run
> > > > inside
> > > > > > Java
> > > > > > > > >> code,
> > > > > > > > >> > as
> > > > > > > > >> > > > > > > > letsencrypt is invoked through Linux
> > > > > > > > >> > > > > > > > 2) each application uses that Stackoverflow
> > hack
> > > > > have
> > > > > > > > >> > additional
> > > > > > > > >> > > > > > compile
> > > > > > > > >> > > > > > > > and run dependency set to Tomcat (which is
> > very
> > > > > bad).
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > I have a proposal on how this should be
> fixed:
> > > > > Tomcat
> > > > > > > > should
> > > > > > > > >> > > have a
> > > > > > > > >> > > > > > > > server.xml options something like
> > > > > > > > >> certificateReloadAfterDays or
> > > > > > > > >> > > > > > > > reloadAfterDays
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > I see this is moved to SSLHostConfig, we are
> > > still
> > > > > > using
> > > > > > > > old
> > > > > > > > >> > > > params.
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > Do you agree on this feature?
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > If so... I'm not lazy to try to do it
> myself,
> > > but
> > > > > as I
> > > > > > > > >> haven't
> > > > > > > > >> > > ever
> > > > > > > > >> > > > > > > written
> > > > > > > > >> > > > > > > > Tomcat code neither know procedures (I have
> > been
> > > > > > coding
> > > > > > > > >> > > > > professionally
> > > > > > > > >> > > > > > > > since 2006, but I never committed to Maven
> or
> > > Git
> > > > > > > project
> > > > > > > > >> > before,
> > > > > > > > >> > > > > lol),
> > > > > > > > >> > > > > > > is
> > > > > > > > >> > > > > > > > there someone else who is keen on doing this
> > > > > feature?
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > > > Have a look at this:
> > > > > > > > >> > > > > > >
> > > > > > > > >>
> > > http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > > > -chris
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > > >
> > > > > > > > >> > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > >> > > > > > > To unsubscribe, e-mail:
> > > > > > dev-unsubscribe@tomcat.apache.org
> > > > > > > > >> > > > > > > For additional commands, e-mail:
> > > > > > > dev-help@tomcat.apache.org
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > >
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#m_-1856320879832207330_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 23 déc. 2020 à 15:08, Mladen Adamović <ml...@gmail.com> a
écrit :
> hmmm.. at least for us, Certbot fetches acme-challenge on HTTP connector.
> According to
>
> https://github.com/payara/Payara/blob/master/appserver/packager/appserver-core/src/main/resources/bin/letsencrypt.py
> an app most likely should have a HTTP connector for Letsencrypt.
>
Why? I don't see the gain there except requiring 2 ports if you dedicate
one connector for letsencrypt.
>
> Then it really doesn't matter AFAIK, if Servet is used or a Valve for most
> cases. Whatever dev thinks fits more in the nature of the system.
>
Hmm, this is where I disagree, if you use letsencrypt in secured app then
a servlet will just not be called whereas the valve will as explained so -
IMHO indeed - it does not depend, only exception to that is when you have
no routing filter and no security in your app - not sure it is mainstream
or not but I know the opposite is common.
>
> I know this can be implemented outside of Tomcat (as we have that
> implementation through Servlet), I'm discussing what could be done in
> Tomcat to simplify Letsencrypt integration.
>
I'm tempted to say either provide a default tomcat-letsencrypt module
"ready to activate" - and I would support you in that work - or nothing
since tomcat is letsencryts friendly thanks its pluggable design IMHO
Do you see anything else which would need to change? The reloadSSL method
was added for letsencrypt already so guess this adjustment work is already
done.
>
>
> On Wed, Dec 23, 2020 at 2:01 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Le mer. 23 déc. 2020 à 12:50, Mladen Adamović <mladen.adamovic@gmail.com
> >
> > a
> > écrit :
> >
> > > On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <
> > rmannibucau@gmail.com
> > > >
> > > wrote:
> > >
> > > > I don't think so, this connector auth is only used in very particular
> > > cases
> > > > (= never ;)): HTTP2 - we don't care, AJP - we don't care much. It is
> > > also a
> > > > kind of automatic authorization - no password or so - so will pass
> and
> > > not
> > > > fail.
> > > >
> > >
> > > That sounds very strange, as I have seen in the code:
> > > if (req.getRemoteUserNeedsAuthorization()) {
> > > ...
> > > } else if (!(authenticator instanceof
> > AuthenticatorBase)) {
> > > ...
> > > }
> > >
> > > public class SSLAuthenticator extends AuthenticatorBase {
> > >
> > >
> > Sure but check what makes remoteUserNeedsAuthorization true (http2 and
> ajp)
> > and what does the block when true (authenticate(username), no password or
> > so).
> > So not an issue IMHO.
> >
> >
> > >
> > > My point was if you have some security contraint (JWT, basic, etc...)
> on
> > > > /*, then your servlet will not be called for letsencrypt call whereas
> > if
> > > > you have a valve you can still handle it properly since you didn't
> > enter
> > > > the secured chain - a valve is before filter chain and can be before
> > > > authenticators in valve chain since authenticators -
> AuthenticatorBase
> > -
> > > > are valves.
> > > >
> > >
> > > Authenticator Valve's seems to me to have a different treatment than
> > other
> > > Valves which are accessed through Pipeline.
> > >
> >
> > This is true since it can be obtained from the context and its call can
> be
> > forced, but here again the question is when.
> > If you check callers then it shouldn't be the case until you add another
> > valve doing it and if so you can still set the LetsEncryptValve before
> and
> > bypass it - can even be set on the host and not the context.
> >
> >
> > >
> > >
> > >
> > > > In other words: no code change required in tomcat internals.
> > > >
> > >
> > > I don't understand this yet. If the implementation would use
> serverl.xml
> > to
> > > change StandardContextValve to something else?
> > >
> >
> > No, change nothing, just add a valve on the host for example through
> <Valve
> > className.... /> tag.
> >
> >
> > >
> > > I've tried to figure out what are you doing in meecrowave and my IDE
> > > (Netbeans) shows me Usage of LetsEncryptValve [no occurrences]
> > >
> >
> > Maybe use another IDE ;) (joking ;)):
> >
> >
> https://github.com/apache/openwebbeans-meecrowave/blob/433a691b246f9eeda2273e794ddbb7970691cc5f/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt/LetsEncryptSetup.java#L44
> > The MeecrowaveAwareInstanceCustomizer instance enables to "code" the
> > server.xml but it is equivalent to previous proposal (<Valve/>).
> >
> >
> > >
> > > How this LetsEncryptValve is actually "injected" into meecrowave
> > Pipeline ?
> > > Or how it is used internally?
> > > I didn't see any Reflection code on Valves or Valve base by searching
> > > source code.
> > >
> > >
> > >
> > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le mer. 23 déc. 2020 à 11:23, Mladen Adamović <
> > mladen.adamovic@gmail.com
> > > >
> > > > a
> > > > écrit :
> > > >
> > > > > Thank you Romain, do you then think the place to check for ACME
> Valve
> > > (if
> > > > > that would the be appropriate naming) would be in
> > > > > CoyoteAdapter.postParseRequest line 814
> > > > > before doConnectorAuthenticationAuthorization(...) ?
> > > > >
> > > > >
> > > > > On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau <
> > > > rmannibucau@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Side note: using a servlet generally does not work if you have
> any
> > > > > security
> > > > > > on the webapp + requires a webapp whereas using a valve solves
> > these
> > > > two
> > > > > > issues.
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > https://github.com/rmannibucau> |
> > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > > >
> > > > > >
> > > > > >
> > > > > > Le mer. 23 déc. 2020 à 09:15, Mladen Adamović <
> > > > mladen.adamovic@gmail.com
> > > > > >
> > > > > > a
> > > > > > écrit :
> > > > > >
> > > > > > > As I haven't received more replies on this topic, I'm guessing
> > > > project
> > > > > > > maintainers are not interested in reviewing and including the
> > code
> > > > for
> > > > > > > simpler Letsencrypt integration and discussing the mentioned
> SSL
> > > > > > > documentation improvements?
> > > > > > >
> > > > > > > Enabling AMCE response servlet (good idea by default) would be
> a
> > > good
> > > > > > step
> > > > > > > in my opinion?
> > > > > > >
> > > > > > > My procedure is explained here:
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
> > > > > > > and the step "Configure HTTP redirect application with support
> to
> > > > ACME
> > > > > > > challenge" could be integrated into Tomcat easily.
> > > > > > >
> > > > > > > In the case that is integrated, I can write a new improved
> > > > > > > tutorial/process.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Sat, Dec 19, 2020 at 11:09 PM Mladen Adamović <
> > > > > > > mladen.adamovic@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau <
> > > > > > > rmannibucau@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > >> It moves the problem elsewhere, how would the CLI
> communicate
> > > with
> > > > > > > tomcat?
> > > > > > > >> JMX, HTTP uses a port, a file based communication would be
> > > > probably
> > > > > > > worse
> > > > > > > >> because of perms and other admin issues (and just not
> working
> > in
> > > > > k8s).
> > > > > > > >>
> > > > > > > >
> > > > > > > > I don't see other sane ways actually. So it seems a web-based
> > > > manager
> > > > > > > with
> > > > > > > > curl is there to stay (for the time being at least).
> > > > > > > >
> > > > > > > > To Chris: It's somewhat weird that the user needs a web
> manager
> > > > just
> > > > > > for
> > > > > > > > curl-ing certification renewal.
> > > > > > > >
> > > > > > > > To everyone:
> > > > > > > > I have a suggestion on improving Documentation regarding SSL.
> > > > > > > > https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
> > > > > > > > Currently, it states
> > > > > > > > Configuration
> > > > > > > > Prepare the Certificate Keystore
> > > > > > > > Tomcat currently operates only on JKS, PKCS11 or PKCS12
> format
> > > > > > keystores.
> > > > > > > >
> > > > > > > > ...
> > > > > > > >
> > > > > > > >
> > > > > > > > I think it should start with
> > > > > > > > Configuration
> > > > > > > > Option 1) Use Tomcat Native
> > > > > > > > which would showcase a path to something like:
> > > > > > > >
> > > > > > > > <!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443 -->
> > > > > > > > <Connector
> > > > > > > > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > > > > > > > port="8443"
> > > > > > > > maxThreads="150"
> > > > > > > > SSLEnabled="true" >
> > > > > > > > <SSLHostConfig>
> > > > > > > > <Certificate
> > > > > > > > certificateKeyFile="conf/localhost-rsa-key.pem"
> > > > > > > > certificateFile="conf/localhost-rsa-cert.pem"
> > > > > > > > certificateChainFile="conf/localhost-rsa-chain.pem"
> > > > > > > > type="RSA"
> > > > > > > > />
> > > > > > > > </SSLHostConfig>
> > > > > > > > </Connector>
> > > > > > > >
> > > > > > > > Option 2) Without Tomcat Native
> > > > > > > >
> > > > > > > >
> > > > > > > > ...
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > I don't know what is the formal process for improving the
> > > > > documentation
> > > > > > > > here?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > > >
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > >
> > > > > > > >> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> > > > > > > >> > > mladen.adamovic@gmail.com
> > > > > > > >> > > > >
> > > > > > > >> > > > > a
> > > > > > > >> > > > > écrit :
> > > > > > > >> > > > >
> > > > > > > >> > > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher
> Schultz
> > <
> > > > > > > >> > > > > > chris@christopherschultz.net> wrote:
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > > Why not use cron? You can do this with a single
> > > "curl"
> > > > > > > command
> > > > > > > >> > and
> > > > > > > >> > > > the
> > > > > > > >> > > > > > > Manager+JMXProxyServlet.
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > We are not using Tomcat manager app.
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > Why someone should be forced to use Manager, to
> > > > read/setup
> > > > > > the
> > > > > > > >> > > > > > documentation regarding JMXProxyServlet, create an
> > > > > > additional
> > > > > > > >> > > > > > servlet (where does it have dependency on?) only
> to
> > > > reload
> > > > > > > >> > > > automatically
> > > > > > > >> > > > > > certificates?
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > I'm proposing a solution with the simple
> > SSLHostConfig
> > > > > > > >> parameter.
> > > > > > > >> > > It's
> > > > > > > >> > > > a
> > > > > > > >> > > > > > user friendly. Simple, intuitive.
> > > > > > > >> > > > > > No need for using manager, no need to create a
> > > specific
> > > > > > > servlet
> > > > > > > >> > > > somewhere
> > > > > > > >> > > > > > in your code. Just a single server.xml argument.
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > Also, *another idea*, I'm contributing this code
> > (see
> > > > > below)
> > > > > > > we
> > > > > > > >> are
> > > > > > > >> > > > using
> > > > > > > >> > > > > > for Letsencrypt ACME challenge.
> > > > > > > >> > > > > > Tomcat could also have an option, i.e. in web.xml
> to
> > > > > > > >> automatically
> > > > > > > >> > > > > support
> > > > > > > >> > > > > > Letsencrypt ACME challenge.
> > > > > > > >> > > > > > Idea for web.xml
> > > > > > > >> > > > > > <servlet>
> > > > > > > >> > > > > >
> > <servlet-name>Letsencrypt-acme</servlet-name>
> > > > > > > >> > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> > > > > > > >> > > > > > <init-param>
> > > > > > > >> > > > > > etc.
> > > > > > > >> > > > > > </servlet>
> > > > > > > >> > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > We are using
> > > > > > > >> > > > > > @WebServlet(name = "LetsencryptAcmeChallenge",
> > > > > urlPatterns =
> > > > > > > >> > > > > > {"/.well-known/acme-challenge/*"})
> > > > > > > >> > > > > > public class LetsencryptAcmeChallenge extends
> > > > HttpServlet
> > > > > {
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > /**
> > > > > > > >> > > > > > * Processes requests for both HTTP
> > <code>GET</code>
> > > > and
> > > > > > > >> > > > > > <code>POST</code> methods.
> > > > > > > >> > > > > > *
> > > > > > > >> > > > > > * @param request servlet request
> > > > > > > >> > > > > > * @param response servlet response
> > > > > > > >> > > > > > * @throws ServletException if a
> servlet-specific
> > > > error
> > > > > > > occurs
> > > > > > > >> > > > > > * @throws IOException if an I/O error occurs
> > > > > > > >> > > > > > */
> > > > > > > >> > > > > > protected void processRequest(HttpServletRequest
> > > > > request,
> > > > > > > >> > > > > > HttpServletResponse response)
> > > > > > > >> > > > > > throws ServletException, IOException {
> > > > > > > >> > > > > > String requestUrl =
> > > > > request.getRequestURL().toString();
> > > > > > > >> > > > > > if
> > > > > (requestUrl.contains(".well-known/acme-challenge/"))
> > > > > > {
> > > > > > > >> > > > > > int indexFilename =
> > requestUrl.lastIndexOf("/")
> > > +
> > > > 1;
> > > > > > > >> > > > > > boolean wasError = true;
> > > > > > > >> > > > > > if (indexFilename > 0 && indexFilename <
> > > > > > > >> > requestUrl.length()) {
> > > > > > > >> > > > > > String filename =
> > > > > > requestUrl.substring(indexFilename);
> > > > > > > >> > > > > > File existingFile = new
> > > > > > > >> > > > > >
> > > > > > > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/"
> > > > > > > >> +
> > > > > > > >> > > > > > filename);
> > > > > > > >> > > > > > if (existingFile.exists()) {
> > > > > > > >> > > > > > response.setContentType("text/plain");
> > > > > > > >> > > > > > OutputStream out =
> > > response.getOutputStream();
> > > > > > > >> > > > > > FileInputStream in = new
> > > > > > > >> FileInputStream(existingFile);
> > > > > > > >> > > > > >
> > > FilesOperations.inputStreamToOutputStream(in,
> > > > > > out);
> > > > > > > >> > > > > > wasError = false;
> > > > > > > >> > > > > > }
> > > > > > > >> > > > > > }
> > > > > > > >> > > > > > if (wasError) {
> > > > > > > >> > > > > > throw new ServletException("invalid
> > requestUrl
> > > > " +
> > > > > > > >> > > requestUrl);
> > > > > > > >> > > > > > }
> > > > > > > >> > > > > > }
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > from FilesOperations:
> > > > > > > >> > > > > > public static void
> > > > > > inputStreamToOutputStream(InputStream
> > > > > > > >> in,
> > > > > > > >> > > > > > OutputStream out) throws IOException {
> > > > > > > >> > > > > > try {
> > > > > > > >> > > > > > byte[ ] buf = new byte[32 * 1024];
> //
> > > 32K
> > > > > > buffer
> > > > > > > >> > > > > > int bytesRead;
> > > > > > > >> > > > > > while ((bytesRead = in.read(buf)) !=
> > -1) {
> > > > > > > >> > > > > > out.write(buf, 0, bytesRead);
> > > > > > > >> > > > > > }
> > > > > > > >> > > > > > } finally {
> > > > > > > >> > > > > > if (in != null) {
> > > > > > > >> > > > > > in.close();
> > > > > > > >> > > > > > out.close();
> > > > > > > >> > > > > > }
> > > > > > > >> > > > > > }
> > > > > > > >> > > > > > }
> > > > > > > >> > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > > > *Long*:
> > > > > > > >> > > > > > > > SSL certificates have a period of expiration
> and
> > > in
> > > > > the
> > > > > > > >> case of
> > > > > > > >> > > > > > > > Letsencrypt, it's set to 3 months as they
> think
> > > > > everyone
> > > > > > > >> should
> > > > > > > >> > > > have
> > > > > > > >> > > > > > the
> > > > > > > >> > > > > > > > renewal mechanism automatically.
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > As the Letsencrypt is the most popular SSL
> > issuing
> > > > > > > authority
> > > > > > > >> > > > (source:
> > > > > > > >> > > > > > > > https://trends.builtwith.com/ssl/LetsEncrypt
> > ), I
> > > > > think
> > > > > > > >> Tomcat
> > > > > > > >> > > > > should
> > > > > > > >> > > > > > > have
> > > > > > > >> > > > > > > > an integration with Letsencrypt working
> > > flawlessly.
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > We are currently using the script to renew the
> > > > > > certificate
> > > > > > > >> (I
> > > > > > > >> > can
> > > > > > > >> > > > > share
> > > > > > > >> > > > > > > our
> > > > > > > >> > > > > > > > integration details with whoever is
> interested,
> > > > please
> > > > > > > >> email me
> > > > > > > >> > > if
> > > > > > > >> > > > > you
> > > > > > > >> > > > > > > are
> > > > > > > >> > > > > > > > interested), but it's restarting Tomcat.
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > As Tomcat shall not be restarted ever
> > (ideally), I
> > > > > think
> > > > > > > >> Tomcat
> > > > > > > >> > > > > should
> > > > > > > >> > > > > > > have
> > > > > > > >> > > > > > > > an option to reload certificate, without a
> > > > dependency
> > > > > to
> > > > > > > >> Tomcat
> > > > > > > >> > > > > source
> > > > > > > >> > > > > > > code
> > > > > > > >> > > > > > > > and "hacks" like some available on
> > StackOverflow:
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> > > > > > > >> > > > > > > ).
> > > > > > > >> > > > > > > > Those hacks are no good as:
> > > > > > > >> > > > > > > > 1) code to reload certificate should not run
> > > inside
> > > > > Java
> > > > > > > >> code,
> > > > > > > >> > as
> > > > > > > >> > > > > > > > letsencrypt is invoked through Linux
> > > > > > > >> > > > > > > > 2) each application uses that Stackoverflow
> hack
> > > > have
> > > > > > > >> > additional
> > > > > > > >> > > > > > compile
> > > > > > > >> > > > > > > > and run dependency set to Tomcat (which is
> very
> > > > bad).
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > I have a proposal on how this should be fixed:
> > > > Tomcat
> > > > > > > should
> > > > > > > >> > > have a
> > > > > > > >> > > > > > > > server.xml options something like
> > > > > > > >> certificateReloadAfterDays or
> > > > > > > >> > > > > > > > reloadAfterDays
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > I see this is moved to SSLHostConfig, we are
> > still
> > > > > using
> > > > > > > old
> > > > > > > >> > > > params.
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > Do you agree on this feature?
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > > > If so... I'm not lazy to try to do it myself,
> > but
> > > > as I
> > > > > > > >> haven't
> > > > > > > >> > > ever
> > > > > > > >> > > > > > > written
> > > > > > > >> > > > > > > > Tomcat code neither know procedures (I have
> been
> > > > > coding
> > > > > > > >> > > > > professionally
> > > > > > > >> > > > > > > > since 2006, but I never committed to Maven or
> > Git
> > > > > > project
> > > > > > > >> > before,
> > > > > > > >> > > > > lol),
> > > > > > > >> > > > > > > is
> > > > > > > >> > > > > > > > there someone else who is keen on doing this
> > > > feature?
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > > Have a look at this:
> > > > > > > >> > > > > > >
> > > > > > > >>
> > http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > > -chris
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > >
> > > > > > > >> > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > >> > > > > > > To unsubscribe, e-mail:
> > > > > dev-unsubscribe@tomcat.apache.org
> > > > > > > >> > > > > > > For additional commands, e-mail:
> > > > > > dev-help@tomcat.apache.org
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Mladen Adamović <ml...@gmail.com>.
hmmm.. at least for us, Certbot fetches acme-challenge on HTTP connector.
According to
https://github.com/payara/Payara/blob/master/appserver/packager/appserver-core/src/main/resources/bin/letsencrypt.py
an app most likely should have a HTTP connector for Letsencrypt.
Then it really doesn't matter AFAIK, if Servet is used or a Valve for most
cases. Whatever dev thinks fits more in the nature of the system.
I know this can be implemented outside of Tomcat (as we have that
implementation through Servlet), I'm discussing what could be done in
Tomcat to simplify Letsencrypt integration.
On Wed, Dec 23, 2020 at 2:01 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Le mer. 23 déc. 2020 à 12:50, Mladen Adamović <ml...@gmail.com>
> a
> écrit :
>
> > On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > wrote:
> >
> > > I don't think so, this connector auth is only used in very particular
> > cases
> > > (= never ;)): HTTP2 - we don't care, AJP - we don't care much. It is
> > also a
> > > kind of automatic authorization - no password or so - so will pass and
> > not
> > > fail.
> > >
> >
> > That sounds very strange, as I have seen in the code:
> > if (req.getRemoteUserNeedsAuthorization()) {
> > ...
> > } else if (!(authenticator instanceof
> AuthenticatorBase)) {
> > ...
> > }
> >
> > public class SSLAuthenticator extends AuthenticatorBase {
> >
> >
> Sure but check what makes remoteUserNeedsAuthorization true (http2 and ajp)
> and what does the block when true (authenticate(username), no password or
> so).
> So not an issue IMHO.
>
>
> >
> > My point was if you have some security contraint (JWT, basic, etc...) on
> > > /*, then your servlet will not be called for letsencrypt call whereas
> if
> > > you have a valve you can still handle it properly since you didn't
> enter
> > > the secured chain - a valve is before filter chain and can be before
> > > authenticators in valve chain since authenticators - AuthenticatorBase
> -
> > > are valves.
> > >
> >
> > Authenticator Valve's seems to me to have a different treatment than
> other
> > Valves which are accessed through Pipeline.
> >
>
> This is true since it can be obtained from the context and its call can be
> forced, but here again the question is when.
> If you check callers then it shouldn't be the case until you add another
> valve doing it and if so you can still set the LetsEncryptValve before and
> bypass it - can even be set on the host and not the context.
>
>
> >
> >
> >
> > > In other words: no code change required in tomcat internals.
> > >
> >
> > I don't understand this yet. If the implementation would use serverl.xml
> to
> > change StandardContextValve to something else?
> >
>
> No, change nothing, just add a valve on the host for example through <Valve
> className.... /> tag.
>
>
> >
> > I've tried to figure out what are you doing in meecrowave and my IDE
> > (Netbeans) shows me Usage of LetsEncryptValve [no occurrences]
> >
>
> Maybe use another IDE ;) (joking ;)):
>
> https://github.com/apache/openwebbeans-meecrowave/blob/433a691b246f9eeda2273e794ddbb7970691cc5f/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt/LetsEncryptSetup.java#L44
> The MeecrowaveAwareInstanceCustomizer instance enables to "code" the
> server.xml but it is equivalent to previous proposal (<Valve/>).
>
>
> >
> > How this LetsEncryptValve is actually "injected" into meecrowave
> Pipeline ?
> > Or how it is used internally?
> > I didn't see any Reflection code on Valves or Valve base by searching
> > source code.
> >
> >
> >
> >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mer. 23 déc. 2020 à 11:23, Mladen Adamović <
> mladen.adamovic@gmail.com
> > >
> > > a
> > > écrit :
> > >
> > > > Thank you Romain, do you then think the place to check for ACME Valve
> > (if
> > > > that would the be appropriate naming) would be in
> > > > CoyoteAdapter.postParseRequest line 814
> > > > before doConnectorAuthenticationAuthorization(...) ?
> > > >
> > > >
> > > > On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > > wrote:
> > > >
> > > > > Side note: using a servlet generally does not work if you have any
> > > > security
> > > > > on the webapp + requires a webapp whereas using a valve solves
> these
> > > two
> > > > > issues.
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > > <
> > > > >
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > > >
> > > > >
> > > > >
> > > > > Le mer. 23 déc. 2020 à 09:15, Mladen Adamović <
> > > mladen.adamovic@gmail.com
> > > > >
> > > > > a
> > > > > écrit :
> > > > >
> > > > > > As I haven't received more replies on this topic, I'm guessing
> > > project
> > > > > > maintainers are not interested in reviewing and including the
> code
> > > for
> > > > > > simpler Letsencrypt integration and discussing the mentioned SSL
> > > > > > documentation improvements?
> > > > > >
> > > > > > Enabling AMCE response servlet (good idea by default) would be a
> > good
> > > > > step
> > > > > > in my opinion?
> > > > > >
> > > > > > My procedure is explained here:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
> > > > > > and the step "Configure HTTP redirect application with support to
> > > ACME
> > > > > > challenge" could be integrated into Tomcat easily.
> > > > > >
> > > > > > In the case that is integrated, I can write a new improved
> > > > > > tutorial/process.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Sat, Dec 19, 2020 at 11:09 PM Mladen Adamović <
> > > > > > mladen.adamovic@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau <
> > > > > > rmannibucau@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > >> It moves the problem elsewhere, how would the CLI communicate
> > with
> > > > > > tomcat?
> > > > > > >> JMX, HTTP uses a port, a file based communication would be
> > > probably
> > > > > > worse
> > > > > > >> because of perms and other admin issues (and just not working
> in
> > > > k8s).
> > > > > > >>
> > > > > > >
> > > > > > > I don't see other sane ways actually. So it seems a web-based
> > > manager
> > > > > > with
> > > > > > > curl is there to stay (for the time being at least).
> > > > > > >
> > > > > > > To Chris: It's somewhat weird that the user needs a web manager
> > > just
> > > > > for
> > > > > > > curl-ing certification renewal.
> > > > > > >
> > > > > > > To everyone:
> > > > > > > I have a suggestion on improving Documentation regarding SSL.
> > > > > > > https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
> > > > > > > Currently, it states
> > > > > > > Configuration
> > > > > > > Prepare the Certificate Keystore
> > > > > > > Tomcat currently operates only on JKS, PKCS11 or PKCS12 format
> > > > > keystores.
> > > > > > >
> > > > > > > ...
> > > > > > >
> > > > > > >
> > > > > > > I think it should start with
> > > > > > > Configuration
> > > > > > > Option 1) Use Tomcat Native
> > > > > > > which would showcase a path to something like:
> > > > > > >
> > > > > > > <!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443 -->
> > > > > > > <Connector
> > > > > > > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > > > > > > port="8443"
> > > > > > > maxThreads="150"
> > > > > > > SSLEnabled="true" >
> > > > > > > <SSLHostConfig>
> > > > > > > <Certificate
> > > > > > > certificateKeyFile="conf/localhost-rsa-key.pem"
> > > > > > > certificateFile="conf/localhost-rsa-cert.pem"
> > > > > > > certificateChainFile="conf/localhost-rsa-chain.pem"
> > > > > > > type="RSA"
> > > > > > > />
> > > > > > > </SSLHostConfig>
> > > > > > > </Connector>
> > > > > > >
> > > > > > > Option 2) Without Tomcat Native
> > > > > > >
> > > > > > >
> > > > > > > ...
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I don't know what is the formal process for improving the
> > > > documentation
> > > > > > > here?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > > >
> > > > > > >> > > >
> > > > > > >> > > >
> > > > > > >> > > > >
> > > > > > >> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> > > > > > >> > > mladen.adamovic@gmail.com
> > > > > > >> > > > >
> > > > > > >> > > > > a
> > > > > > >> > > > > écrit :
> > > > > > >> > > > >
> > > > > > >> > > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz
> <
> > > > > > >> > > > > > chris@christopherschultz.net> wrote:
> > > > > > >> > > > > >
> > > > > > >> > > > > > > Why not use cron? You can do this with a single
> > "curl"
> > > > > > command
> > > > > > >> > and
> > > > > > >> > > > the
> > > > > > >> > > > > > > Manager+JMXProxyServlet.
> > > > > > >> > > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > > We are not using Tomcat manager app.
> > > > > > >> > > > > >
> > > > > > >> > > > > > Why someone should be forced to use Manager, to
> > > read/setup
> > > > > the
> > > > > > >> > > > > > documentation regarding JMXProxyServlet, create an
> > > > > additional
> > > > > > >> > > > > > servlet (where does it have dependency on?) only to
> > > reload
> > > > > > >> > > > automatically
> > > > > > >> > > > > > certificates?
> > > > > > >> > > > > >
> > > > > > >> > > > > > I'm proposing a solution with the simple
> SSLHostConfig
> > > > > > >> parameter.
> > > > > > >> > > It's
> > > > > > >> > > > a
> > > > > > >> > > > > > user friendly. Simple, intuitive.
> > > > > > >> > > > > > No need for using manager, no need to create a
> > specific
> > > > > > servlet
> > > > > > >> > > > somewhere
> > > > > > >> > > > > > in your code. Just a single server.xml argument.
> > > > > > >> > > > > >
> > > > > > >> > > > > > Also, *another idea*, I'm contributing this code
> (see
> > > > below)
> > > > > > we
> > > > > > >> are
> > > > > > >> > > > using
> > > > > > >> > > > > > for Letsencrypt ACME challenge.
> > > > > > >> > > > > > Tomcat could also have an option, i.e. in web.xml to
> > > > > > >> automatically
> > > > > > >> > > > > support
> > > > > > >> > > > > > Letsencrypt ACME challenge.
> > > > > > >> > > > > > Idea for web.xml
> > > > > > >> > > > > > <servlet>
> > > > > > >> > > > > >
> <servlet-name>Letsencrypt-acme</servlet-name>
> > > > > > >> > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> > > > > > >> > > > > > <init-param>
> > > > > > >> > > > > > etc.
> > > > > > >> > > > > > </servlet>
> > > > > > >> > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > > We are using
> > > > > > >> > > > > > @WebServlet(name = "LetsencryptAcmeChallenge",
> > > > urlPatterns =
> > > > > > >> > > > > > {"/.well-known/acme-challenge/*"})
> > > > > > >> > > > > > public class LetsencryptAcmeChallenge extends
> > > HttpServlet
> > > > {
> > > > > > >> > > > > >
> > > > > > >> > > > > > /**
> > > > > > >> > > > > > * Processes requests for both HTTP
> <code>GET</code>
> > > and
> > > > > > >> > > > > > <code>POST</code> methods.
> > > > > > >> > > > > > *
> > > > > > >> > > > > > * @param request servlet request
> > > > > > >> > > > > > * @param response servlet response
> > > > > > >> > > > > > * @throws ServletException if a servlet-specific
> > > error
> > > > > > occurs
> > > > > > >> > > > > > * @throws IOException if an I/O error occurs
> > > > > > >> > > > > > */
> > > > > > >> > > > > > protected void processRequest(HttpServletRequest
> > > > request,
> > > > > > >> > > > > > HttpServletResponse response)
> > > > > > >> > > > > > throws ServletException, IOException {
> > > > > > >> > > > > > String requestUrl =
> > > > request.getRequestURL().toString();
> > > > > > >> > > > > > if
> > > > (requestUrl.contains(".well-known/acme-challenge/"))
> > > > > {
> > > > > > >> > > > > > int indexFilename =
> requestUrl.lastIndexOf("/")
> > +
> > > 1;
> > > > > > >> > > > > > boolean wasError = true;
> > > > > > >> > > > > > if (indexFilename > 0 && indexFilename <
> > > > > > >> > requestUrl.length()) {
> > > > > > >> > > > > > String filename =
> > > > > requestUrl.substring(indexFilename);
> > > > > > >> > > > > > File existingFile = new
> > > > > > >> > > > > >
> > > > > > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/"
> > > > > > >> +
> > > > > > >> > > > > > filename);
> > > > > > >> > > > > > if (existingFile.exists()) {
> > > > > > >> > > > > > response.setContentType("text/plain");
> > > > > > >> > > > > > OutputStream out =
> > response.getOutputStream();
> > > > > > >> > > > > > FileInputStream in = new
> > > > > > >> FileInputStream(existingFile);
> > > > > > >> > > > > >
> > FilesOperations.inputStreamToOutputStream(in,
> > > > > out);
> > > > > > >> > > > > > wasError = false;
> > > > > > >> > > > > > }
> > > > > > >> > > > > > }
> > > > > > >> > > > > > if (wasError) {
> > > > > > >> > > > > > throw new ServletException("invalid
> requestUrl
> > > " +
> > > > > > >> > > requestUrl);
> > > > > > >> > > > > > }
> > > > > > >> > > > > > }
> > > > > > >> > > > > >
> > > > > > >> > > > > > from FilesOperations:
> > > > > > >> > > > > > public static void
> > > > > inputStreamToOutputStream(InputStream
> > > > > > >> in,
> > > > > > >> > > > > > OutputStream out) throws IOException {
> > > > > > >> > > > > > try {
> > > > > > >> > > > > > byte[ ] buf = new byte[32 * 1024]; //
> > 32K
> > > > > buffer
> > > > > > >> > > > > > int bytesRead;
> > > > > > >> > > > > > while ((bytesRead = in.read(buf)) !=
> -1) {
> > > > > > >> > > > > > out.write(buf, 0, bytesRead);
> > > > > > >> > > > > > }
> > > > > > >> > > > > > } finally {
> > > > > > >> > > > > > if (in != null) {
> > > > > > >> > > > > > in.close();
> > > > > > >> > > > > > out.close();
> > > > > > >> > > > > > }
> > > > > > >> > > > > > }
> > > > > > >> > > > > > }
> > > > > > >> > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > > > > > *Long*:
> > > > > > >> > > > > > > > SSL certificates have a period of expiration and
> > in
> > > > the
> > > > > > >> case of
> > > > > > >> > > > > > > > Letsencrypt, it's set to 3 months as they think
> > > > everyone
> > > > > > >> should
> > > > > > >> > > > have
> > > > > > >> > > > > > the
> > > > > > >> > > > > > > > renewal mechanism automatically.
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > As the Letsencrypt is the most popular SSL
> issuing
> > > > > > authority
> > > > > > >> > > > (source:
> > > > > > >> > > > > > > > https://trends.builtwith.com/ssl/LetsEncrypt
> ), I
> > > > think
> > > > > > >> Tomcat
> > > > > > >> > > > > should
> > > > > > >> > > > > > > have
> > > > > > >> > > > > > > > an integration with Letsencrypt working
> > flawlessly.
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > We are currently using the script to renew the
> > > > > certificate
> > > > > > >> (I
> > > > > > >> > can
> > > > > > >> > > > > share
> > > > > > >> > > > > > > our
> > > > > > >> > > > > > > > integration details with whoever is interested,
> > > please
> > > > > > >> email me
> > > > > > >> > > if
> > > > > > >> > > > > you
> > > > > > >> > > > > > > are
> > > > > > >> > > > > > > > interested), but it's restarting Tomcat.
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > As Tomcat shall not be restarted ever
> (ideally), I
> > > > think
> > > > > > >> Tomcat
> > > > > > >> > > > > should
> > > > > > >> > > > > > > have
> > > > > > >> > > > > > > > an option to reload certificate, without a
> > > dependency
> > > > to
> > > > > > >> Tomcat
> > > > > > >> > > > > source
> > > > > > >> > > > > > > code
> > > > > > >> > > > > > > > and "hacks" like some available on
> StackOverflow:
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> > > > > > >> > > > > > > ).
> > > > > > >> > > > > > > > Those hacks are no good as:
> > > > > > >> > > > > > > > 1) code to reload certificate should not run
> > inside
> > > > Java
> > > > > > >> code,
> > > > > > >> > as
> > > > > > >> > > > > > > > letsencrypt is invoked through Linux
> > > > > > >> > > > > > > > 2) each application uses that Stackoverflow hack
> > > have
> > > > > > >> > additional
> > > > > > >> > > > > > compile
> > > > > > >> > > > > > > > and run dependency set to Tomcat (which is very
> > > bad).
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > I have a proposal on how this should be fixed:
> > > Tomcat
> > > > > > should
> > > > > > >> > > have a
> > > > > > >> > > > > > > > server.xml options something like
> > > > > > >> certificateReloadAfterDays or
> > > > > > >> > > > > > > > reloadAfterDays
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > I see this is moved to SSLHostConfig, we are
> still
> > > > using
> > > > > > old
> > > > > > >> > > > params.
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > Do you agree on this feature?
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > > > If so... I'm not lazy to try to do it myself,
> but
> > > as I
> > > > > > >> haven't
> > > > > > >> > > ever
> > > > > > >> > > > > > > written
> > > > > > >> > > > > > > > Tomcat code neither know procedures (I have been
> > > > coding
> > > > > > >> > > > > professionally
> > > > > > >> > > > > > > > since 2006, but I never committed to Maven or
> Git
> > > > > project
> > > > > > >> > before,
> > > > > > >> > > > > lol),
> > > > > > >> > > > > > > is
> > > > > > >> > > > > > > > there someone else who is keen on doing this
> > > feature?
> > > > > > >> > > > > > >
> > > > > > >> > > > > > > Have a look at this:
> > > > > > >> > > > > > >
> > > > > > >>
> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> > > > > > >> > > > > > >
> > > > > > >> > > > > > > -chris
> > > > > > >> > > > > > >
> > > > > > >> > > > > > >
> > > > > > >> > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > >> > > > > > > To unsubscribe, e-mail:
> > > > dev-unsubscribe@tomcat.apache.org
> > > > > > >> > > > > > > For additional commands, e-mail:
> > > > > dev-help@tomcat.apache.org
> > > > > > >> > > > > > >
> > > > > > >> > > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 23 déc. 2020 à 12:50, Mladen Adamović <ml...@gmail.com> a
écrit :
> On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > I don't think so, this connector auth is only used in very particular
> cases
> > (= never ;)): HTTP2 - we don't care, AJP - we don't care much. It is
> also a
> > kind of automatic authorization - no password or so - so will pass and
> not
> > fail.
> >
>
> That sounds very strange, as I have seen in the code:
> if (req.getRemoteUserNeedsAuthorization()) {
> ...
> } else if (!(authenticator instanceof AuthenticatorBase)) {
> ...
> }
>
> public class SSLAuthenticator extends AuthenticatorBase {
>
>
Sure but check what makes remoteUserNeedsAuthorization true (http2 and ajp)
and what does the block when true (authenticate(username), no password or
so).
So not an issue IMHO.
>
> My point was if you have some security contraint (JWT, basic, etc...) on
> > /*, then your servlet will not be called for letsencrypt call whereas if
> > you have a valve you can still handle it properly since you didn't enter
> > the secured chain - a valve is before filter chain and can be before
> > authenticators in valve chain since authenticators - AuthenticatorBase -
> > are valves.
> >
>
> Authenticator Valve's seems to me to have a different treatment than other
> Valves which are accessed through Pipeline.
>
This is true since it can be obtained from the context and its call can be
forced, but here again the question is when.
If you check callers then it shouldn't be the case until you add another
valve doing it and if so you can still set the LetsEncryptValve before and
bypass it - can even be set on the host and not the context.
>
>
>
> > In other words: no code change required in tomcat internals.
> >
>
> I don't understand this yet. If the implementation would use serverl.xml to
> change StandardContextValve to something else?
>
No, change nothing, just add a valve on the host for example through <Valve
className.... /> tag.
>
> I've tried to figure out what are you doing in meecrowave and my IDE
> (Netbeans) shows me Usage of LetsEncryptValve [no occurrences]
>
Maybe use another IDE ;) (joking ;)):
https://github.com/apache/openwebbeans-meecrowave/blob/433a691b246f9eeda2273e794ddbb7970691cc5f/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt/LetsEncryptSetup.java#L44
The MeecrowaveAwareInstanceCustomizer instance enables to "code" the
server.xml but it is equivalent to previous proposal (<Valve/>).
>
> How this LetsEncryptValve is actually "injected" into meecrowave Pipeline ?
> Or how it is used internally?
> I didn't see any Reflection code on Valves or Valve base by searching
> source code.
>
>
>
>
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 23 déc. 2020 à 11:23, Mladen Adamović <mladen.adamovic@gmail.com
> >
> > a
> > écrit :
> >
> > > Thank you Romain, do you then think the place to check for ACME Valve
> (if
> > > that would the be appropriate naming) would be in
> > > CoyoteAdapter.postParseRequest line 814
> > > before doConnectorAuthenticationAuthorization(...) ?
> > >
> > >
> > > On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > > > Side note: using a servlet generally does not work if you have any
> > > security
> > > > on the webapp + requires a webapp whereas using a valve solves these
> > two
> > > > issues.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > > <
> > > >
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > > >
> > > >
> > > >
> > > > Le mer. 23 déc. 2020 à 09:15, Mladen Adamović <
> > mladen.adamovic@gmail.com
> > > >
> > > > a
> > > > écrit :
> > > >
> > > > > As I haven't received more replies on this topic, I'm guessing
> > project
> > > > > maintainers are not interested in reviewing and including the code
> > for
> > > > > simpler Letsencrypt integration and discussing the mentioned SSL
> > > > > documentation improvements?
> > > > >
> > > > > Enabling AMCE response servlet (good idea by default) would be a
> good
> > > > step
> > > > > in my opinion?
> > > > >
> > > > > My procedure is explained here:
> > > > >
> > > > >
> > > >
> > >
> >
> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
> > > > > and the step "Configure HTTP redirect application with support to
> > ACME
> > > > > challenge" could be integrated into Tomcat easily.
> > > > >
> > > > > In the case that is integrated, I can write a new improved
> > > > > tutorial/process.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Sat, Dec 19, 2020 at 11:09 PM Mladen Adamović <
> > > > > mladen.adamovic@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau <
> > > > > rmannibucau@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > >> It moves the problem elsewhere, how would the CLI communicate
> with
> > > > > tomcat?
> > > > > >> JMX, HTTP uses a port, a file based communication would be
> > probably
> > > > > worse
> > > > > >> because of perms and other admin issues (and just not working in
> > > k8s).
> > > > > >>
> > > > > >
> > > > > > I don't see other sane ways actually. So it seems a web-based
> > manager
> > > > > with
> > > > > > curl is there to stay (for the time being at least).
> > > > > >
> > > > > > To Chris: It's somewhat weird that the user needs a web manager
> > just
> > > > for
> > > > > > curl-ing certification renewal.
> > > > > >
> > > > > > To everyone:
> > > > > > I have a suggestion on improving Documentation regarding SSL.
> > > > > > https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
> > > > > > Currently, it states
> > > > > > Configuration
> > > > > > Prepare the Certificate Keystore
> > > > > > Tomcat currently operates only on JKS, PKCS11 or PKCS12 format
> > > > keystores.
> > > > > >
> > > > > > ...
> > > > > >
> > > > > >
> > > > > > I think it should start with
> > > > > > Configuration
> > > > > > Option 1) Use Tomcat Native
> > > > > > which would showcase a path to something like:
> > > > > >
> > > > > > <!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443 -->
> > > > > > <Connector
> > > > > > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > > > > > port="8443"
> > > > > > maxThreads="150"
> > > > > > SSLEnabled="true" >
> > > > > > <SSLHostConfig>
> > > > > > <Certificate
> > > > > > certificateKeyFile="conf/localhost-rsa-key.pem"
> > > > > > certificateFile="conf/localhost-rsa-cert.pem"
> > > > > > certificateChainFile="conf/localhost-rsa-chain.pem"
> > > > > > type="RSA"
> > > > > > />
> > > > > > </SSLHostConfig>
> > > > > > </Connector>
> > > > > >
> > > > > > Option 2) Without Tomcat Native
> > > > > >
> > > > > >
> > > > > > ...
> > > > > >
> > > > > >
> > > > > >
> > > > > > I don't know what is the formal process for improving the
> > > documentation
> > > > > > here?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > > >
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > >
> > > > > >> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> > > > > >> > > mladen.adamovic@gmail.com
> > > > > >> > > > >
> > > > > >> > > > > a
> > > > > >> > > > > écrit :
> > > > > >> > > > >
> > > > > >> > > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> > > > > >> > > > > > chris@christopherschultz.net> wrote:
> > > > > >> > > > > >
> > > > > >> > > > > > > Why not use cron? You can do this with a single
> "curl"
> > > > > command
> > > > > >> > and
> > > > > >> > > > the
> > > > > >> > > > > > > Manager+JMXProxyServlet.
> > > > > >> > > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > We are not using Tomcat manager app.
> > > > > >> > > > > >
> > > > > >> > > > > > Why someone should be forced to use Manager, to
> > read/setup
> > > > the
> > > > > >> > > > > > documentation regarding JMXProxyServlet, create an
> > > > additional
> > > > > >> > > > > > servlet (where does it have dependency on?) only to
> > reload
> > > > > >> > > > automatically
> > > > > >> > > > > > certificates?
> > > > > >> > > > > >
> > > > > >> > > > > > I'm proposing a solution with the simple SSLHostConfig
> > > > > >> parameter.
> > > > > >> > > It's
> > > > > >> > > > a
> > > > > >> > > > > > user friendly. Simple, intuitive.
> > > > > >> > > > > > No need for using manager, no need to create a
> specific
> > > > > servlet
> > > > > >> > > > somewhere
> > > > > >> > > > > > in your code. Just a single server.xml argument.
> > > > > >> > > > > >
> > > > > >> > > > > > Also, *another idea*, I'm contributing this code (see
> > > below)
> > > > > we
> > > > > >> are
> > > > > >> > > > using
> > > > > >> > > > > > for Letsencrypt ACME challenge.
> > > > > >> > > > > > Tomcat could also have an option, i.e. in web.xml to
> > > > > >> automatically
> > > > > >> > > > > support
> > > > > >> > > > > > Letsencrypt ACME challenge.
> > > > > >> > > > > > Idea for web.xml
> > > > > >> > > > > > <servlet>
> > > > > >> > > > > > <servlet-name>Letsencrypt-acme</servlet-name>
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> > > > > >> > > > > > <init-param>
> > > > > >> > > > > > etc.
> > > > > >> > > > > > </servlet>
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > We are using
> > > > > >> > > > > > @WebServlet(name = "LetsencryptAcmeChallenge",
> > > urlPatterns =
> > > > > >> > > > > > {"/.well-known/acme-challenge/*"})
> > > > > >> > > > > > public class LetsencryptAcmeChallenge extends
> > HttpServlet
> > > {
> > > > > >> > > > > >
> > > > > >> > > > > > /**
> > > > > >> > > > > > * Processes requests for both HTTP <code>GET</code>
> > and
> > > > > >> > > > > > <code>POST</code> methods.
> > > > > >> > > > > > *
> > > > > >> > > > > > * @param request servlet request
> > > > > >> > > > > > * @param response servlet response
> > > > > >> > > > > > * @throws ServletException if a servlet-specific
> > error
> > > > > occurs
> > > > > >> > > > > > * @throws IOException if an I/O error occurs
> > > > > >> > > > > > */
> > > > > >> > > > > > protected void processRequest(HttpServletRequest
> > > request,
> > > > > >> > > > > > HttpServletResponse response)
> > > > > >> > > > > > throws ServletException, IOException {
> > > > > >> > > > > > String requestUrl =
> > > request.getRequestURL().toString();
> > > > > >> > > > > > if
> > > (requestUrl.contains(".well-known/acme-challenge/"))
> > > > {
> > > > > >> > > > > > int indexFilename = requestUrl.lastIndexOf("/")
> +
> > 1;
> > > > > >> > > > > > boolean wasError = true;
> > > > > >> > > > > > if (indexFilename > 0 && indexFilename <
> > > > > >> > requestUrl.length()) {
> > > > > >> > > > > > String filename =
> > > > requestUrl.substring(indexFilename);
> > > > > >> > > > > > File existingFile = new
> > > > > >> > > > > >
> > > > > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/"
> > > > > >> +
> > > > > >> > > > > > filename);
> > > > > >> > > > > > if (existingFile.exists()) {
> > > > > >> > > > > > response.setContentType("text/plain");
> > > > > >> > > > > > OutputStream out =
> response.getOutputStream();
> > > > > >> > > > > > FileInputStream in = new
> > > > > >> FileInputStream(existingFile);
> > > > > >> > > > > >
> FilesOperations.inputStreamToOutputStream(in,
> > > > out);
> > > > > >> > > > > > wasError = false;
> > > > > >> > > > > > }
> > > > > >> > > > > > }
> > > > > >> > > > > > if (wasError) {
> > > > > >> > > > > > throw new ServletException("invalid requestUrl
> > " +
> > > > > >> > > requestUrl);
> > > > > >> > > > > > }
> > > > > >> > > > > > }
> > > > > >> > > > > >
> > > > > >> > > > > > from FilesOperations:
> > > > > >> > > > > > public static void
> > > > inputStreamToOutputStream(InputStream
> > > > > >> in,
> > > > > >> > > > > > OutputStream out) throws IOException {
> > > > > >> > > > > > try {
> > > > > >> > > > > > byte[ ] buf = new byte[32 * 1024]; //
> 32K
> > > > buffer
> > > > > >> > > > > > int bytesRead;
> > > > > >> > > > > > while ((bytesRead = in.read(buf)) != -1) {
> > > > > >> > > > > > out.write(buf, 0, bytesRead);
> > > > > >> > > > > > }
> > > > > >> > > > > > } finally {
> > > > > >> > > > > > if (in != null) {
> > > > > >> > > > > > in.close();
> > > > > >> > > > > > out.close();
> > > > > >> > > > > > }
> > > > > >> > > > > > }
> > > > > >> > > > > > }
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > > > *Long*:
> > > > > >> > > > > > > > SSL certificates have a period of expiration and
> in
> > > the
> > > > > >> case of
> > > > > >> > > > > > > > Letsencrypt, it's set to 3 months as they think
> > > everyone
> > > > > >> should
> > > > > >> > > > have
> > > > > >> > > > > > the
> > > > > >> > > > > > > > renewal mechanism automatically.
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > As the Letsencrypt is the most popular SSL issuing
> > > > > authority
> > > > > >> > > > (source:
> > > > > >> > > > > > > > https://trends.builtwith.com/ssl/LetsEncrypt ), I
> > > think
> > > > > >> Tomcat
> > > > > >> > > > > should
> > > > > >> > > > > > > have
> > > > > >> > > > > > > > an integration with Letsencrypt working
> flawlessly.
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > We are currently using the script to renew the
> > > > certificate
> > > > > >> (I
> > > > > >> > can
> > > > > >> > > > > share
> > > > > >> > > > > > > our
> > > > > >> > > > > > > > integration details with whoever is interested,
> > please
> > > > > >> email me
> > > > > >> > > if
> > > > > >> > > > > you
> > > > > >> > > > > > > are
> > > > > >> > > > > > > > interested), but it's restarting Tomcat.
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > As Tomcat shall not be restarted ever (ideally), I
> > > think
> > > > > >> Tomcat
> > > > > >> > > > > should
> > > > > >> > > > > > > have
> > > > > >> > > > > > > > an option to reload certificate, without a
> > dependency
> > > to
> > > > > >> Tomcat
> > > > > >> > > > > source
> > > > > >> > > > > > > code
> > > > > >> > > > > > > > and "hacks" like some available on StackOverflow:
> > > > > >> > > > > > > >
> > > > > >> > > > > > >
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> > > > > >> > > > > > > ).
> > > > > >> > > > > > > > Those hacks are no good as:
> > > > > >> > > > > > > > 1) code to reload certificate should not run
> inside
> > > Java
> > > > > >> code,
> > > > > >> > as
> > > > > >> > > > > > > > letsencrypt is invoked through Linux
> > > > > >> > > > > > > > 2) each application uses that Stackoverflow hack
> > have
> > > > > >> > additional
> > > > > >> > > > > > compile
> > > > > >> > > > > > > > and run dependency set to Tomcat (which is very
> > bad).
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > I have a proposal on how this should be fixed:
> > Tomcat
> > > > > should
> > > > > >> > > have a
> > > > > >> > > > > > > > server.xml options something like
> > > > > >> certificateReloadAfterDays or
> > > > > >> > > > > > > > reloadAfterDays
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > I see this is moved to SSLHostConfig, we are still
> > > using
> > > > > old
> > > > > >> > > > params.
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > Do you agree on this feature?
> > > > > >> > > > > > > >
> > > > > >> > > > > > > > If so... I'm not lazy to try to do it myself, but
> > as I
> > > > > >> haven't
> > > > > >> > > ever
> > > > > >> > > > > > > written
> > > > > >> > > > > > > > Tomcat code neither know procedures (I have been
> > > coding
> > > > > >> > > > > professionally
> > > > > >> > > > > > > > since 2006, but I never committed to Maven or Git
> > > > project
> > > > > >> > before,
> > > > > >> > > > > lol),
> > > > > >> > > > > > > is
> > > > > >> > > > > > > > there someone else who is keen on doing this
> > feature?
> > > > > >> > > > > > >
> > > > > >> > > > > > > Have a look at this:
> > > > > >> > > > > > >
> > > > > >> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> > > > > >> > > > > > >
> > > > > >> > > > > > > -chris
> > > > > >> > > > > > >
> > > > > >> > > > > > >
> > > > > >> > >
> > > > >
> ---------------------------------------------------------------------
> > > > > >> > > > > > > To unsubscribe, e-mail:
> > > dev-unsubscribe@tomcat.apache.org
> > > > > >> > > > > > > For additional commands, e-mail:
> > > > dev-help@tomcat.apache.org
> > > > > >> > > > > > >
> > > > > >> > > > > > >
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Mladen Adamović <ml...@gmail.com>.
On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> I don't think so, this connector auth is only used in very particular cases
> (= never ;)): HTTP2 - we don't care, AJP - we don't care much. It is also a
> kind of automatic authorization - no password or so - so will pass and not
> fail.
>
That sounds very strange, as I have seen in the code:
if (req.getRemoteUserNeedsAuthorization()) {
...
} else if (!(authenticator instanceof AuthenticatorBase)) {
...
}
public class SSLAuthenticator extends AuthenticatorBase {
My point was if you have some security contraint (JWT, basic, etc...) on
> /*, then your servlet will not be called for letsencrypt call whereas if
> you have a valve you can still handle it properly since you didn't enter
> the secured chain - a valve is before filter chain and can be before
> authenticators in valve chain since authenticators - AuthenticatorBase -
> are valves.
>
Authenticator Valve's seems to me to have a different treatment than other
Valves which are accessed through Pipeline.
> In other words: no code change required in tomcat internals.
>
I don't understand this yet. If the implementation would use serverl.xml to
change StandardContextValve to something else?
I've tried to figure out what are you doing in meecrowave and my IDE
(Netbeans) shows me Usage of LetsEncryptValve [no occurrences]
How this LetsEncryptValve is actually "injected" into meecrowave Pipeline ?
Or how it is used internally?
I didn't see any Reflection code on Valves or Valve base by searching
source code.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 23 déc. 2020 à 11:23, Mladen Adamović <ml...@gmail.com>
> a
> écrit :
>
> > Thank you Romain, do you then think the place to check for ACME Valve (if
> > that would the be appropriate naming) would be in
> > CoyoteAdapter.postParseRequest line 814
> > before doConnectorAuthenticationAuthorization(...) ?
> >
> >
> > On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > Side note: using a servlet generally does not work if you have any
> > security
> > > on the webapp + requires a webapp whereas using a valve solves these
> two
> > > issues.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mer. 23 déc. 2020 à 09:15, Mladen Adamović <
> mladen.adamovic@gmail.com
> > >
> > > a
> > > écrit :
> > >
> > > > As I haven't received more replies on this topic, I'm guessing
> project
> > > > maintainers are not interested in reviewing and including the code
> for
> > > > simpler Letsencrypt integration and discussing the mentioned SSL
> > > > documentation improvements?
> > > >
> > > > Enabling AMCE response servlet (good idea by default) would be a good
> > > step
> > > > in my opinion?
> > > >
> > > > My procedure is explained here:
> > > >
> > > >
> > >
> >
> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
> > > > and the step "Configure HTTP redirect application with support to
> ACME
> > > > challenge" could be integrated into Tomcat easily.
> > > >
> > > > In the case that is integrated, I can write a new improved
> > > > tutorial/process.
> > > >
> > > >
> > > >
> > > >
> > > > On Sat, Dec 19, 2020 at 11:09 PM Mladen Adamović <
> > > > mladen.adamovic@gmail.com>
> > > > wrote:
> > > >
> > > > > On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau <
> > > > rmannibucau@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> It moves the problem elsewhere, how would the CLI communicate with
> > > > tomcat?
> > > > >> JMX, HTTP uses a port, a file based communication would be
> probably
> > > > worse
> > > > >> because of perms and other admin issues (and just not working in
> > k8s).
> > > > >>
> > > > >
> > > > > I don't see other sane ways actually. So it seems a web-based
> manager
> > > > with
> > > > > curl is there to stay (for the time being at least).
> > > > >
> > > > > To Chris: It's somewhat weird that the user needs a web manager
> just
> > > for
> > > > > curl-ing certification renewal.
> > > > >
> > > > > To everyone:
> > > > > I have a suggestion on improving Documentation regarding SSL.
> > > > > https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
> > > > > Currently, it states
> > > > > Configuration
> > > > > Prepare the Certificate Keystore
> > > > > Tomcat currently operates only on JKS, PKCS11 or PKCS12 format
> > > keystores.
> > > > >
> > > > > ...
> > > > >
> > > > >
> > > > > I think it should start with
> > > > > Configuration
> > > > > Option 1) Use Tomcat Native
> > > > > which would showcase a path to something like:
> > > > >
> > > > > <!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443 -->
> > > > > <Connector
> > > > > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > > > > port="8443"
> > > > > maxThreads="150"
> > > > > SSLEnabled="true" >
> > > > > <SSLHostConfig>
> > > > > <Certificate
> > > > > certificateKeyFile="conf/localhost-rsa-key.pem"
> > > > > certificateFile="conf/localhost-rsa-cert.pem"
> > > > > certificateChainFile="conf/localhost-rsa-chain.pem"
> > > > > type="RSA"
> > > > > />
> > > > > </SSLHostConfig>
> > > > > </Connector>
> > > > >
> > > > > Option 2) Without Tomcat Native
> > > > >
> > > > >
> > > > > ...
> > > > >
> > > > >
> > > > >
> > > > > I don't know what is the formal process for improving the
> > documentation
> > > > > here?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > >
> > > > >> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> > > > >> > > mladen.adamovic@gmail.com
> > > > >> > > > >
> > > > >> > > > > a
> > > > >> > > > > écrit :
> > > > >> > > > >
> > > > >> > > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> > > > >> > > > > > chris@christopherschultz.net> wrote:
> > > > >> > > > > >
> > > > >> > > > > > > Why not use cron? You can do this with a single "curl"
> > > > command
> > > > >> > and
> > > > >> > > > the
> > > > >> > > > > > > Manager+JMXProxyServlet.
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > > > We are not using Tomcat manager app.
> > > > >> > > > > >
> > > > >> > > > > > Why someone should be forced to use Manager, to
> read/setup
> > > the
> > > > >> > > > > > documentation regarding JMXProxyServlet, create an
> > > additional
> > > > >> > > > > > servlet (where does it have dependency on?) only to
> reload
> > > > >> > > > automatically
> > > > >> > > > > > certificates?
> > > > >> > > > > >
> > > > >> > > > > > I'm proposing a solution with the simple SSLHostConfig
> > > > >> parameter.
> > > > >> > > It's
> > > > >> > > > a
> > > > >> > > > > > user friendly. Simple, intuitive.
> > > > >> > > > > > No need for using manager, no need to create a specific
> > > > servlet
> > > > >> > > > somewhere
> > > > >> > > > > > in your code. Just a single server.xml argument.
> > > > >> > > > > >
> > > > >> > > > > > Also, *another idea*, I'm contributing this code (see
> > below)
> > > > we
> > > > >> are
> > > > >> > > > using
> > > > >> > > > > > for Letsencrypt ACME challenge.
> > > > >> > > > > > Tomcat could also have an option, i.e. in web.xml to
> > > > >> automatically
> > > > >> > > > > support
> > > > >> > > > > > Letsencrypt ACME challenge.
> > > > >> > > > > > Idea for web.xml
> > > > >> > > > > > <servlet>
> > > > >> > > > > > <servlet-name>Letsencrypt-acme</servlet-name>
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> > > > >> > > > > > <init-param>
> > > > >> > > > > > etc.
> > > > >> > > > > > </servlet>
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > We are using
> > > > >> > > > > > @WebServlet(name = "LetsencryptAcmeChallenge",
> > urlPatterns =
> > > > >> > > > > > {"/.well-known/acme-challenge/*"})
> > > > >> > > > > > public class LetsencryptAcmeChallenge extends
> HttpServlet
> > {
> > > > >> > > > > >
> > > > >> > > > > > /**
> > > > >> > > > > > * Processes requests for both HTTP <code>GET</code>
> and
> > > > >> > > > > > <code>POST</code> methods.
> > > > >> > > > > > *
> > > > >> > > > > > * @param request servlet request
> > > > >> > > > > > * @param response servlet response
> > > > >> > > > > > * @throws ServletException if a servlet-specific
> error
> > > > occurs
> > > > >> > > > > > * @throws IOException if an I/O error occurs
> > > > >> > > > > > */
> > > > >> > > > > > protected void processRequest(HttpServletRequest
> > request,
> > > > >> > > > > > HttpServletResponse response)
> > > > >> > > > > > throws ServletException, IOException {
> > > > >> > > > > > String requestUrl =
> > request.getRequestURL().toString();
> > > > >> > > > > > if
> > (requestUrl.contains(".well-known/acme-challenge/"))
> > > {
> > > > >> > > > > > int indexFilename = requestUrl.lastIndexOf("/") +
> 1;
> > > > >> > > > > > boolean wasError = true;
> > > > >> > > > > > if (indexFilename > 0 && indexFilename <
> > > > >> > requestUrl.length()) {
> > > > >> > > > > > String filename =
> > > requestUrl.substring(indexFilename);
> > > > >> > > > > > File existingFile = new
> > > > >> > > > > >
> > > > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/"
> > > > >> +
> > > > >> > > > > > filename);
> > > > >> > > > > > if (existingFile.exists()) {
> > > > >> > > > > > response.setContentType("text/plain");
> > > > >> > > > > > OutputStream out = response.getOutputStream();
> > > > >> > > > > > FileInputStream in = new
> > > > >> FileInputStream(existingFile);
> > > > >> > > > > > FilesOperations.inputStreamToOutputStream(in,
> > > out);
> > > > >> > > > > > wasError = false;
> > > > >> > > > > > }
> > > > >> > > > > > }
> > > > >> > > > > > if (wasError) {
> > > > >> > > > > > throw new ServletException("invalid requestUrl
> " +
> > > > >> > > requestUrl);
> > > > >> > > > > > }
> > > > >> > > > > > }
> > > > >> > > > > >
> > > > >> > > > > > from FilesOperations:
> > > > >> > > > > > public static void
> > > inputStreamToOutputStream(InputStream
> > > > >> in,
> > > > >> > > > > > OutputStream out) throws IOException {
> > > > >> > > > > > try {
> > > > >> > > > > > byte[ ] buf = new byte[32 * 1024]; // 32K
> > > buffer
> > > > >> > > > > > int bytesRead;
> > > > >> > > > > > while ((bytesRead = in.read(buf)) != -1) {
> > > > >> > > > > > out.write(buf, 0, bytesRead);
> > > > >> > > > > > }
> > > > >> > > > > > } finally {
> > > > >> > > > > > if (in != null) {
> > > > >> > > > > > in.close();
> > > > >> > > > > > out.close();
> > > > >> > > > > > }
> > > > >> > > > > > }
> > > > >> > > > > > }
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > > > *Long*:
> > > > >> > > > > > > > SSL certificates have a period of expiration and in
> > the
> > > > >> case of
> > > > >> > > > > > > > Letsencrypt, it's set to 3 months as they think
> > everyone
> > > > >> should
> > > > >> > > > have
> > > > >> > > > > > the
> > > > >> > > > > > > > renewal mechanism automatically.
> > > > >> > > > > > > >
> > > > >> > > > > > > > As the Letsencrypt is the most popular SSL issuing
> > > > authority
> > > > >> > > > (source:
> > > > >> > > > > > > > https://trends.builtwith.com/ssl/LetsEncrypt ), I
> > think
> > > > >> Tomcat
> > > > >> > > > > should
> > > > >> > > > > > > have
> > > > >> > > > > > > > an integration with Letsencrypt working flawlessly.
> > > > >> > > > > > > >
> > > > >> > > > > > > > We are currently using the script to renew the
> > > certificate
> > > > >> (I
> > > > >> > can
> > > > >> > > > > share
> > > > >> > > > > > > our
> > > > >> > > > > > > > integration details with whoever is interested,
> please
> > > > >> email me
> > > > >> > > if
> > > > >> > > > > you
> > > > >> > > > > > > are
> > > > >> > > > > > > > interested), but it's restarting Tomcat.
> > > > >> > > > > > > >
> > > > >> > > > > > > > As Tomcat shall not be restarted ever (ideally), I
> > think
> > > > >> Tomcat
> > > > >> > > > > should
> > > > >> > > > > > > have
> > > > >> > > > > > > > an option to reload certificate, without a
> dependency
> > to
> > > > >> Tomcat
> > > > >> > > > > source
> > > > >> > > > > > > code
> > > > >> > > > > > > > and "hacks" like some available on StackOverflow:
> > > > >> > > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> > > > >> > > > > > > ).
> > > > >> > > > > > > > Those hacks are no good as:
> > > > >> > > > > > > > 1) code to reload certificate should not run inside
> > Java
> > > > >> code,
> > > > >> > as
> > > > >> > > > > > > > letsencrypt is invoked through Linux
> > > > >> > > > > > > > 2) each application uses that Stackoverflow hack
> have
> > > > >> > additional
> > > > >> > > > > > compile
> > > > >> > > > > > > > and run dependency set to Tomcat (which is very
> bad).
> > > > >> > > > > > > >
> > > > >> > > > > > > > I have a proposal on how this should be fixed:
> Tomcat
> > > > should
> > > > >> > > have a
> > > > >> > > > > > > > server.xml options something like
> > > > >> certificateReloadAfterDays or
> > > > >> > > > > > > > reloadAfterDays
> > > > >> > > > > > > >
> > > > >> > > > > > > > I see this is moved to SSLHostConfig, we are still
> > using
> > > > old
> > > > >> > > > params.
> > > > >> > > > > > > >
> > > > >> > > > > > > > Do you agree on this feature?
> > > > >> > > > > > > >
> > > > >> > > > > > > > If so... I'm not lazy to try to do it myself, but
> as I
> > > > >> haven't
> > > > >> > > ever
> > > > >> > > > > > > written
> > > > >> > > > > > > > Tomcat code neither know procedures (I have been
> > coding
> > > > >> > > > > professionally
> > > > >> > > > > > > > since 2006, but I never committed to Maven or Git
> > > project
> > > > >> > before,
> > > > >> > > > > lol),
> > > > >> > > > > > > is
> > > > >> > > > > > > > there someone else who is keen on doing this
> feature?
> > > > >> > > > > > >
> > > > >> > > > > > > Have a look at this:
> > > > >> > > > > > >
> > > > >> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> > > > >> > > > > > >
> > > > >> > > > > > > -chris
> > > > >> > > > > > >
> > > > >> > > > > > >
> > > > >> > >
> > > > ---------------------------------------------------------------------
> > > > >> > > > > > > To unsubscribe, e-mail:
> > dev-unsubscribe@tomcat.apache.org
> > > > >> > > > > > > For additional commands, e-mail:
> > > dev-help@tomcat.apache.org
> > > > >> > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I don't think so, this connector auth is only used in very particular cases
(= never ;)): HTTP2 - we don't care, AJP - we don't care much. It is also a
kind of automatic authorization - no password or so - so will pass and not
fail.
My point was if you have some security contraint (JWT, basic, etc...) on
/*, then your servlet will not be called for letsencrypt call whereas if
you have a valve you can still handle it properly since you didn't enter
the secured chain - a valve is before filter chain and can be before
authenticators in valve chain since authenticators - AuthenticatorBase -
are valves.
In other words: no code change required in tomcat internals.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 23 déc. 2020 à 11:23, Mladen Adamović <ml...@gmail.com> a
écrit :
> Thank you Romain, do you then think the place to check for ACME Valve (if
> that would the be appropriate naming) would be in
> CoyoteAdapter.postParseRequest line 814
> before doConnectorAuthenticationAuthorization(...) ?
>
>
> On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Side note: using a servlet generally does not work if you have any
> security
> > on the webapp + requires a webapp whereas using a valve solves these two
> > issues.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mer. 23 déc. 2020 à 09:15, Mladen Adamović <mladen.adamovic@gmail.com
> >
> > a
> > écrit :
> >
> > > As I haven't received more replies on this topic, I'm guessing project
> > > maintainers are not interested in reviewing and including the code for
> > > simpler Letsencrypt integration and discussing the mentioned SSL
> > > documentation improvements?
> > >
> > > Enabling AMCE response servlet (good idea by default) would be a good
> > step
> > > in my opinion?
> > >
> > > My procedure is explained here:
> > >
> > >
> >
> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
> > > and the step "Configure HTTP redirect application with support to ACME
> > > challenge" could be integrated into Tomcat easily.
> > >
> > > In the case that is integrated, I can write a new improved
> > > tutorial/process.
> > >
> > >
> > >
> > >
> > > On Sat, Dec 19, 2020 at 11:09 PM Mladen Adamović <
> > > mladen.adamovic@gmail.com>
> > > wrote:
> > >
> > > > On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau <
> > > rmannibucau@gmail.com>
> > > > wrote:
> > > >
> > > >> It moves the problem elsewhere, how would the CLI communicate with
> > > tomcat?
> > > >> JMX, HTTP uses a port, a file based communication would be probably
> > > worse
> > > >> because of perms and other admin issues (and just not working in
> k8s).
> > > >>
> > > >
> > > > I don't see other sane ways actually. So it seems a web-based manager
> > > with
> > > > curl is there to stay (for the time being at least).
> > > >
> > > > To Chris: It's somewhat weird that the user needs a web manager just
> > for
> > > > curl-ing certification renewal.
> > > >
> > > > To everyone:
> > > > I have a suggestion on improving Documentation regarding SSL.
> > > > https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
> > > > Currently, it states
> > > > Configuration
> > > > Prepare the Certificate Keystore
> > > > Tomcat currently operates only on JKS, PKCS11 or PKCS12 format
> > keystores.
> > > >
> > > > ...
> > > >
> > > >
> > > > I think it should start with
> > > > Configuration
> > > > Option 1) Use Tomcat Native
> > > > which would showcase a path to something like:
> > > >
> > > > <!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443 -->
> > > > <Connector
> > > > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > > > port="8443"
> > > > maxThreads="150"
> > > > SSLEnabled="true" >
> > > > <SSLHostConfig>
> > > > <Certificate
> > > > certificateKeyFile="conf/localhost-rsa-key.pem"
> > > > certificateFile="conf/localhost-rsa-cert.pem"
> > > > certificateChainFile="conf/localhost-rsa-chain.pem"
> > > > type="RSA"
> > > > />
> > > > </SSLHostConfig>
> > > > </Connector>
> > > >
> > > > Option 2) Without Tomcat Native
> > > >
> > > >
> > > > ...
> > > >
> > > >
> > > >
> > > > I don't know what is the formal process for improving the
> documentation
> > > > here?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > >
> > > >> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> > > >> > > mladen.adamovic@gmail.com
> > > >> > > > >
> > > >> > > > > a
> > > >> > > > > écrit :
> > > >> > > > >
> > > >> > > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> > > >> > > > > > chris@christopherschultz.net> wrote:
> > > >> > > > > >
> > > >> > > > > > > Why not use cron? You can do this with a single "curl"
> > > command
> > > >> > and
> > > >> > > > the
> > > >> > > > > > > Manager+JMXProxyServlet.
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > > > We are not using Tomcat manager app.
> > > >> > > > > >
> > > >> > > > > > Why someone should be forced to use Manager, to read/setup
> > the
> > > >> > > > > > documentation regarding JMXProxyServlet, create an
> > additional
> > > >> > > > > > servlet (where does it have dependency on?) only to reload
> > > >> > > > automatically
> > > >> > > > > > certificates?
> > > >> > > > > >
> > > >> > > > > > I'm proposing a solution with the simple SSLHostConfig
> > > >> parameter.
> > > >> > > It's
> > > >> > > > a
> > > >> > > > > > user friendly. Simple, intuitive.
> > > >> > > > > > No need for using manager, no need to create a specific
> > > servlet
> > > >> > > > somewhere
> > > >> > > > > > in your code. Just a single server.xml argument.
> > > >> > > > > >
> > > >> > > > > > Also, *another idea*, I'm contributing this code (see
> below)
> > > we
> > > >> are
> > > >> > > > using
> > > >> > > > > > for Letsencrypt ACME challenge.
> > > >> > > > > > Tomcat could also have an option, i.e. in web.xml to
> > > >> automatically
> > > >> > > > > support
> > > >> > > > > > Letsencrypt ACME challenge.
> > > >> > > > > > Idea for web.xml
> > > >> > > > > > <servlet>
> > > >> > > > > > <servlet-name>Letsencrypt-acme</servlet-name>
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> > > >> > > > > > <init-param>
> > > >> > > > > > etc.
> > > >> > > > > > </servlet>
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > We are using
> > > >> > > > > > @WebServlet(name = "LetsencryptAcmeChallenge",
> urlPatterns =
> > > >> > > > > > {"/.well-known/acme-challenge/*"})
> > > >> > > > > > public class LetsencryptAcmeChallenge extends HttpServlet
> {
> > > >> > > > > >
> > > >> > > > > > /**
> > > >> > > > > > * Processes requests for both HTTP <code>GET</code> and
> > > >> > > > > > <code>POST</code> methods.
> > > >> > > > > > *
> > > >> > > > > > * @param request servlet request
> > > >> > > > > > * @param response servlet response
> > > >> > > > > > * @throws ServletException if a servlet-specific error
> > > occurs
> > > >> > > > > > * @throws IOException if an I/O error occurs
> > > >> > > > > > */
> > > >> > > > > > protected void processRequest(HttpServletRequest
> request,
> > > >> > > > > > HttpServletResponse response)
> > > >> > > > > > throws ServletException, IOException {
> > > >> > > > > > String requestUrl =
> request.getRequestURL().toString();
> > > >> > > > > > if
> (requestUrl.contains(".well-known/acme-challenge/"))
> > {
> > > >> > > > > > int indexFilename = requestUrl.lastIndexOf("/") + 1;
> > > >> > > > > > boolean wasError = true;
> > > >> > > > > > if (indexFilename > 0 && indexFilename <
> > > >> > requestUrl.length()) {
> > > >> > > > > > String filename =
> > requestUrl.substring(indexFilename);
> > > >> > > > > > File existingFile = new
> > > >> > > > > >
> > > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/"
> > > >> +
> > > >> > > > > > filename);
> > > >> > > > > > if (existingFile.exists()) {
> > > >> > > > > > response.setContentType("text/plain");
> > > >> > > > > > OutputStream out = response.getOutputStream();
> > > >> > > > > > FileInputStream in = new
> > > >> FileInputStream(existingFile);
> > > >> > > > > > FilesOperations.inputStreamToOutputStream(in,
> > out);
> > > >> > > > > > wasError = false;
> > > >> > > > > > }
> > > >> > > > > > }
> > > >> > > > > > if (wasError) {
> > > >> > > > > > throw new ServletException("invalid requestUrl " +
> > > >> > > requestUrl);
> > > >> > > > > > }
> > > >> > > > > > }
> > > >> > > > > >
> > > >> > > > > > from FilesOperations:
> > > >> > > > > > public static void
> > inputStreamToOutputStream(InputStream
> > > >> in,
> > > >> > > > > > OutputStream out) throws IOException {
> > > >> > > > > > try {
> > > >> > > > > > byte[ ] buf = new byte[32 * 1024]; // 32K
> > buffer
> > > >> > > > > > int bytesRead;
> > > >> > > > > > while ((bytesRead = in.read(buf)) != -1) {
> > > >> > > > > > out.write(buf, 0, bytesRead);
> > > >> > > > > > }
> > > >> > > > > > } finally {
> > > >> > > > > > if (in != null) {
> > > >> > > > > > in.close();
> > > >> > > > > > out.close();
> > > >> > > > > > }
> > > >> > > > > > }
> > > >> > > > > > }
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > > > *Long*:
> > > >> > > > > > > > SSL certificates have a period of expiration and in
> the
> > > >> case of
> > > >> > > > > > > > Letsencrypt, it's set to 3 months as they think
> everyone
> > > >> should
> > > >> > > > have
> > > >> > > > > > the
> > > >> > > > > > > > renewal mechanism automatically.
> > > >> > > > > > > >
> > > >> > > > > > > > As the Letsencrypt is the most popular SSL issuing
> > > authority
> > > >> > > > (source:
> > > >> > > > > > > > https://trends.builtwith.com/ssl/LetsEncrypt ), I
> think
> > > >> Tomcat
> > > >> > > > > should
> > > >> > > > > > > have
> > > >> > > > > > > > an integration with Letsencrypt working flawlessly.
> > > >> > > > > > > >
> > > >> > > > > > > > We are currently using the script to renew the
> > certificate
> > > >> (I
> > > >> > can
> > > >> > > > > share
> > > >> > > > > > > our
> > > >> > > > > > > > integration details with whoever is interested, please
> > > >> email me
> > > >> > > if
> > > >> > > > > you
> > > >> > > > > > > are
> > > >> > > > > > > > interested), but it's restarting Tomcat.
> > > >> > > > > > > >
> > > >> > > > > > > > As Tomcat shall not be restarted ever (ideally), I
> think
> > > >> Tomcat
> > > >> > > > > should
> > > >> > > > > > > have
> > > >> > > > > > > > an option to reload certificate, without a dependency
> to
> > > >> Tomcat
> > > >> > > > > source
> > > >> > > > > > > code
> > > >> > > > > > > > and "hacks" like some available on StackOverflow:
> > > >> > > > > > > >
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> > > >> > > > > > > ).
> > > >> > > > > > > > Those hacks are no good as:
> > > >> > > > > > > > 1) code to reload certificate should not run inside
> Java
> > > >> code,
> > > >> > as
> > > >> > > > > > > > letsencrypt is invoked through Linux
> > > >> > > > > > > > 2) each application uses that Stackoverflow hack have
> > > >> > additional
> > > >> > > > > > compile
> > > >> > > > > > > > and run dependency set to Tomcat (which is very bad).
> > > >> > > > > > > >
> > > >> > > > > > > > I have a proposal on how this should be fixed: Tomcat
> > > should
> > > >> > > have a
> > > >> > > > > > > > server.xml options something like
> > > >> certificateReloadAfterDays or
> > > >> > > > > > > > reloadAfterDays
> > > >> > > > > > > >
> > > >> > > > > > > > I see this is moved to SSLHostConfig, we are still
> using
> > > old
> > > >> > > > params.
> > > >> > > > > > > >
> > > >> > > > > > > > Do you agree on this feature?
> > > >> > > > > > > >
> > > >> > > > > > > > If so... I'm not lazy to try to do it myself, but as I
> > > >> haven't
> > > >> > > ever
> > > >> > > > > > > written
> > > >> > > > > > > > Tomcat code neither know procedures (I have been
> coding
> > > >> > > > > professionally
> > > >> > > > > > > > since 2006, but I never committed to Maven or Git
> > project
> > > >> > before,
> > > >> > > > > lol),
> > > >> > > > > > > is
> > > >> > > > > > > > there someone else who is keen on doing this feature?
> > > >> > > > > > >
> > > >> > > > > > > Have a look at this:
> > > >> > > > > > >
> > > >> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> > > >> > > > > > >
> > > >> > > > > > > -chris
> > > >> > > > > > >
> > > >> > > > > > >
> > > >> > >
> > > ---------------------------------------------------------------------
> > > >> > > > > > > To unsubscribe, e-mail:
> dev-unsubscribe@tomcat.apache.org
> > > >> > > > > > > For additional commands, e-mail:
> > dev-help@tomcat.apache.org
> > > >> > > > > > >
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Mladen Adamović <ml...@gmail.com>.
Thank you Romain, do you then think the place to check for ACME Valve (if
that would the be appropriate naming) would be in
CoyoteAdapter.postParseRequest line 814
before doConnectorAuthenticationAuthorization(...) ?
On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Side note: using a servlet generally does not work if you have any security
> on the webapp + requires a webapp whereas using a valve solves these two
> issues.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 23 déc. 2020 à 09:15, Mladen Adamović <ml...@gmail.com>
> a
> écrit :
>
> > As I haven't received more replies on this topic, I'm guessing project
> > maintainers are not interested in reviewing and including the code for
> > simpler Letsencrypt integration and discussing the mentioned SSL
> > documentation improvements?
> >
> > Enabling AMCE response servlet (good idea by default) would be a good
> step
> > in my opinion?
> >
> > My procedure is explained here:
> >
> >
> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
> > and the step "Configure HTTP redirect application with support to ACME
> > challenge" could be integrated into Tomcat easily.
> >
> > In the case that is integrated, I can write a new improved
> > tutorial/process.
> >
> >
> >
> >
> > On Sat, Dec 19, 2020 at 11:09 PM Mladen Adamović <
> > mladen.adamovic@gmail.com>
> > wrote:
> >
> > > On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > >> It moves the problem elsewhere, how would the CLI communicate with
> > tomcat?
> > >> JMX, HTTP uses a port, a file based communication would be probably
> > worse
> > >> because of perms and other admin issues (and just not working in k8s).
> > >>
> > >
> > > I don't see other sane ways actually. So it seems a web-based manager
> > with
> > > curl is there to stay (for the time being at least).
> > >
> > > To Chris: It's somewhat weird that the user needs a web manager just
> for
> > > curl-ing certification renewal.
> > >
> > > To everyone:
> > > I have a suggestion on improving Documentation regarding SSL.
> > > https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
> > > Currently, it states
> > > Configuration
> > > Prepare the Certificate Keystore
> > > Tomcat currently operates only on JKS, PKCS11 or PKCS12 format
> keystores.
> > >
> > > ...
> > >
> > >
> > > I think it should start with
> > > Configuration
> > > Option 1) Use Tomcat Native
> > > which would showcase a path to something like:
> > >
> > > <!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443 -->
> > > <Connector
> > > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > > port="8443"
> > > maxThreads="150"
> > > SSLEnabled="true" >
> > > <SSLHostConfig>
> > > <Certificate
> > > certificateKeyFile="conf/localhost-rsa-key.pem"
> > > certificateFile="conf/localhost-rsa-cert.pem"
> > > certificateChainFile="conf/localhost-rsa-chain.pem"
> > > type="RSA"
> > > />
> > > </SSLHostConfig>
> > > </Connector>
> > >
> > > Option 2) Without Tomcat Native
> > >
> > >
> > > ...
> > >
> > >
> > >
> > > I don't know what is the formal process for improving the documentation
> > > here?
> > >
> > >
> > >
> > >
> > >
> > > > > >
> > >> > > >
> > >> > > >
> > >> > > > >
> > >> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> > >> > > mladen.adamovic@gmail.com
> > >> > > > >
> > >> > > > > a
> > >> > > > > écrit :
> > >> > > > >
> > >> > > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> > >> > > > > > chris@christopherschultz.net> wrote:
> > >> > > > > >
> > >> > > > > > > Why not use cron? You can do this with a single "curl"
> > command
> > >> > and
> > >> > > > the
> > >> > > > > > > Manager+JMXProxyServlet.
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > > We are not using Tomcat manager app.
> > >> > > > > >
> > >> > > > > > Why someone should be forced to use Manager, to read/setup
> the
> > >> > > > > > documentation regarding JMXProxyServlet, create an
> additional
> > >> > > > > > servlet (where does it have dependency on?) only to reload
> > >> > > > automatically
> > >> > > > > > certificates?
> > >> > > > > >
> > >> > > > > > I'm proposing a solution with the simple SSLHostConfig
> > >> parameter.
> > >> > > It's
> > >> > > > a
> > >> > > > > > user friendly. Simple, intuitive.
> > >> > > > > > No need for using manager, no need to create a specific
> > servlet
> > >> > > > somewhere
> > >> > > > > > in your code. Just a single server.xml argument.
> > >> > > > > >
> > >> > > > > > Also, *another idea*, I'm contributing this code (see below)
> > we
> > >> are
> > >> > > > using
> > >> > > > > > for Letsencrypt ACME challenge.
> > >> > > > > > Tomcat could also have an option, i.e. in web.xml to
> > >> automatically
> > >> > > > > support
> > >> > > > > > Letsencrypt ACME challenge.
> > >> > > > > > Idea for web.xml
> > >> > > > > > <servlet>
> > >> > > > > > <servlet-name>Letsencrypt-acme</servlet-name>
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> > >> > > > > > <init-param>
> > >> > > > > > etc.
> > >> > > > > > </servlet>
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > We are using
> > >> > > > > > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> > >> > > > > > {"/.well-known/acme-challenge/*"})
> > >> > > > > > public class LetsencryptAcmeChallenge extends HttpServlet {
> > >> > > > > >
> > >> > > > > > /**
> > >> > > > > > * Processes requests for both HTTP <code>GET</code> and
> > >> > > > > > <code>POST</code> methods.
> > >> > > > > > *
> > >> > > > > > * @param request servlet request
> > >> > > > > > * @param response servlet response
> > >> > > > > > * @throws ServletException if a servlet-specific error
> > occurs
> > >> > > > > > * @throws IOException if an I/O error occurs
> > >> > > > > > */
> > >> > > > > > protected void processRequest(HttpServletRequest request,
> > >> > > > > > HttpServletResponse response)
> > >> > > > > > throws ServletException, IOException {
> > >> > > > > > String requestUrl = request.getRequestURL().toString();
> > >> > > > > > if (requestUrl.contains(".well-known/acme-challenge/"))
> {
> > >> > > > > > int indexFilename = requestUrl.lastIndexOf("/") + 1;
> > >> > > > > > boolean wasError = true;
> > >> > > > > > if (indexFilename > 0 && indexFilename <
> > >> > requestUrl.length()) {
> > >> > > > > > String filename =
> requestUrl.substring(indexFilename);
> > >> > > > > > File existingFile = new
> > >> > > > > >
> > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/"
> > >> +
> > >> > > > > > filename);
> > >> > > > > > if (existingFile.exists()) {
> > >> > > > > > response.setContentType("text/plain");
> > >> > > > > > OutputStream out = response.getOutputStream();
> > >> > > > > > FileInputStream in = new
> > >> FileInputStream(existingFile);
> > >> > > > > > FilesOperations.inputStreamToOutputStream(in,
> out);
> > >> > > > > > wasError = false;
> > >> > > > > > }
> > >> > > > > > }
> > >> > > > > > if (wasError) {
> > >> > > > > > throw new ServletException("invalid requestUrl " +
> > >> > > requestUrl);
> > >> > > > > > }
> > >> > > > > > }
> > >> > > > > >
> > >> > > > > > from FilesOperations:
> > >> > > > > > public static void
> inputStreamToOutputStream(InputStream
> > >> in,
> > >> > > > > > OutputStream out) throws IOException {
> > >> > > > > > try {
> > >> > > > > > byte[ ] buf = new byte[32 * 1024]; // 32K
> buffer
> > >> > > > > > int bytesRead;
> > >> > > > > > while ((bytesRead = in.read(buf)) != -1) {
> > >> > > > > > out.write(buf, 0, bytesRead);
> > >> > > > > > }
> > >> > > > > > } finally {
> > >> > > > > > if (in != null) {
> > >> > > > > > in.close();
> > >> > > > > > out.close();
> > >> > > > > > }
> > >> > > > > > }
> > >> > > > > > }
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > > > *Long*:
> > >> > > > > > > > SSL certificates have a period of expiration and in the
> > >> case of
> > >> > > > > > > > Letsencrypt, it's set to 3 months as they think everyone
> > >> should
> > >> > > > have
> > >> > > > > > the
> > >> > > > > > > > renewal mechanism automatically.
> > >> > > > > > > >
> > >> > > > > > > > As the Letsencrypt is the most popular SSL issuing
> > authority
> > >> > > > (source:
> > >> > > > > > > > https://trends.builtwith.com/ssl/LetsEncrypt ), I think
> > >> Tomcat
> > >> > > > > should
> > >> > > > > > > have
> > >> > > > > > > > an integration with Letsencrypt working flawlessly.
> > >> > > > > > > >
> > >> > > > > > > > We are currently using the script to renew the
> certificate
> > >> (I
> > >> > can
> > >> > > > > share
> > >> > > > > > > our
> > >> > > > > > > > integration details with whoever is interested, please
> > >> email me
> > >> > > if
> > >> > > > > you
> > >> > > > > > > are
> > >> > > > > > > > interested), but it's restarting Tomcat.
> > >> > > > > > > >
> > >> > > > > > > > As Tomcat shall not be restarted ever (ideally), I think
> > >> Tomcat
> > >> > > > > should
> > >> > > > > > > have
> > >> > > > > > > > an option to reload certificate, without a dependency to
> > >> Tomcat
> > >> > > > > source
> > >> > > > > > > code
> > >> > > > > > > > and "hacks" like some available on StackOverflow:
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> > >> > > > > > > ).
> > >> > > > > > > > Those hacks are no good as:
> > >> > > > > > > > 1) code to reload certificate should not run inside Java
> > >> code,
> > >> > as
> > >> > > > > > > > letsencrypt is invoked through Linux
> > >> > > > > > > > 2) each application uses that Stackoverflow hack have
> > >> > additional
> > >> > > > > > compile
> > >> > > > > > > > and run dependency set to Tomcat (which is very bad).
> > >> > > > > > > >
> > >> > > > > > > > I have a proposal on how this should be fixed: Tomcat
> > should
> > >> > > have a
> > >> > > > > > > > server.xml options something like
> > >> certificateReloadAfterDays or
> > >> > > > > > > > reloadAfterDays
> > >> > > > > > > >
> > >> > > > > > > > I see this is moved to SSLHostConfig, we are still using
> > old
> > >> > > > params.
> > >> > > > > > > >
> > >> > > > > > > > Do you agree on this feature?
> > >> > > > > > > >
> > >> > > > > > > > If so... I'm not lazy to try to do it myself, but as I
> > >> haven't
> > >> > > ever
> > >> > > > > > > written
> > >> > > > > > > > Tomcat code neither know procedures (I have been coding
> > >> > > > > professionally
> > >> > > > > > > > since 2006, but I never committed to Maven or Git
> project
> > >> > before,
> > >> > > > > lol),
> > >> > > > > > > is
> > >> > > > > > > > there someone else who is keen on doing this feature?
> > >> > > > > > >
> > >> > > > > > > Have a look at this:
> > >> > > > > > >
> > >> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> > >> > > > > > >
> > >> > > > > > > -chris
> > >> > > > > > >
> > >> > > > > > >
> > >> > >
> > ---------------------------------------------------------------------
> > >> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > >> > > > > > > For additional commands, e-mail:
> dev-help@tomcat.apache.org
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Side note: using a servlet generally does not work if you have any security
on the webapp + requires a webapp whereas using a valve solves these two
issues.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 23 déc. 2020 à 09:15, Mladen Adamović <ml...@gmail.com> a
écrit :
> As I haven't received more replies on this topic, I'm guessing project
> maintainers are not interested in reviewing and including the code for
> simpler Letsencrypt integration and discussing the mentioned SSL
> documentation improvements?
>
> Enabling AMCE response servlet (good idea by default) would be a good step
> in my opinion?
>
> My procedure is explained here:
>
> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
> and the step "Configure HTTP redirect application with support to ACME
> challenge" could be integrated into Tomcat easily.
>
> In the case that is integrated, I can write a new improved
> tutorial/process.
>
>
>
>
> On Sat, Dec 19, 2020 at 11:09 PM Mladen Adamović <
> mladen.adamovic@gmail.com>
> wrote:
>
> > On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> >> It moves the problem elsewhere, how would the CLI communicate with
> tomcat?
> >> JMX, HTTP uses a port, a file based communication would be probably
> worse
> >> because of perms and other admin issues (and just not working in k8s).
> >>
> >
> > I don't see other sane ways actually. So it seems a web-based manager
> with
> > curl is there to stay (for the time being at least).
> >
> > To Chris: It's somewhat weird that the user needs a web manager just for
> > curl-ing certification renewal.
> >
> > To everyone:
> > I have a suggestion on improving Documentation regarding SSL.
> > https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
> > Currently, it states
> > Configuration
> > Prepare the Certificate Keystore
> > Tomcat currently operates only on JKS, PKCS11 or PKCS12 format keystores.
> >
> > ...
> >
> >
> > I think it should start with
> > Configuration
> > Option 1) Use Tomcat Native
> > which would showcase a path to something like:
> >
> > <!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443 -->
> > <Connector
> > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > port="8443"
> > maxThreads="150"
> > SSLEnabled="true" >
> > <SSLHostConfig>
> > <Certificate
> > certificateKeyFile="conf/localhost-rsa-key.pem"
> > certificateFile="conf/localhost-rsa-cert.pem"
> > certificateChainFile="conf/localhost-rsa-chain.pem"
> > type="RSA"
> > />
> > </SSLHostConfig>
> > </Connector>
> >
> > Option 2) Without Tomcat Native
> >
> >
> > ...
> >
> >
> >
> > I don't know what is the formal process for improving the documentation
> > here?
> >
> >
> >
> >
> >
> > > > >
> >> > > >
> >> > > >
> >> > > > >
> >> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> >> > > mladen.adamovic@gmail.com
> >> > > > >
> >> > > > > a
> >> > > > > écrit :
> >> > > > >
> >> > > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> >> > > > > > chris@christopherschultz.net> wrote:
> >> > > > > >
> >> > > > > > > Why not use cron? You can do this with a single "curl"
> command
> >> > and
> >> > > > the
> >> > > > > > > Manager+JMXProxyServlet.
> >> > > > > > >
> >> > > > > >
> >> > > > > > We are not using Tomcat manager app.
> >> > > > > >
> >> > > > > > Why someone should be forced to use Manager, to read/setup the
> >> > > > > > documentation regarding JMXProxyServlet, create an additional
> >> > > > > > servlet (where does it have dependency on?) only to reload
> >> > > > automatically
> >> > > > > > certificates?
> >> > > > > >
> >> > > > > > I'm proposing a solution with the simple SSLHostConfig
> >> parameter.
> >> > > It's
> >> > > > a
> >> > > > > > user friendly. Simple, intuitive.
> >> > > > > > No need for using manager, no need to create a specific
> servlet
> >> > > > somewhere
> >> > > > > > in your code. Just a single server.xml argument.
> >> > > > > >
> >> > > > > > Also, *another idea*, I'm contributing this code (see below)
> we
> >> are
> >> > > > using
> >> > > > > > for Letsencrypt ACME challenge.
> >> > > > > > Tomcat could also have an option, i.e. in web.xml to
> >> automatically
> >> > > > > support
> >> > > > > > Letsencrypt ACME challenge.
> >> > > > > > Idea for web.xml
> >> > > > > > <servlet>
> >> > > > > > <servlet-name>Letsencrypt-acme</servlet-name>
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> >> > > > > > <init-param>
> >> > > > > > etc.
> >> > > > > > </servlet>
> >> > > > > >
> >> > > > > >
> >> > > > > > We are using
> >> > > > > > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> >> > > > > > {"/.well-known/acme-challenge/*"})
> >> > > > > > public class LetsencryptAcmeChallenge extends HttpServlet {
> >> > > > > >
> >> > > > > > /**
> >> > > > > > * Processes requests for both HTTP <code>GET</code> and
> >> > > > > > <code>POST</code> methods.
> >> > > > > > *
> >> > > > > > * @param request servlet request
> >> > > > > > * @param response servlet response
> >> > > > > > * @throws ServletException if a servlet-specific error
> occurs
> >> > > > > > * @throws IOException if an I/O error occurs
> >> > > > > > */
> >> > > > > > protected void processRequest(HttpServletRequest request,
> >> > > > > > HttpServletResponse response)
> >> > > > > > throws ServletException, IOException {
> >> > > > > > String requestUrl = request.getRequestURL().toString();
> >> > > > > > if (requestUrl.contains(".well-known/acme-challenge/")) {
> >> > > > > > int indexFilename = requestUrl.lastIndexOf("/") + 1;
> >> > > > > > boolean wasError = true;
> >> > > > > > if (indexFilename > 0 && indexFilename <
> >> > requestUrl.length()) {
> >> > > > > > String filename = requestUrl.substring(indexFilename);
> >> > > > > > File existingFile = new
> >> > > > > >
> File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/"
> >> +
> >> > > > > > filename);
> >> > > > > > if (existingFile.exists()) {
> >> > > > > > response.setContentType("text/plain");
> >> > > > > > OutputStream out = response.getOutputStream();
> >> > > > > > FileInputStream in = new
> >> FileInputStream(existingFile);
> >> > > > > > FilesOperations.inputStreamToOutputStream(in, out);
> >> > > > > > wasError = false;
> >> > > > > > }
> >> > > > > > }
> >> > > > > > if (wasError) {
> >> > > > > > throw new ServletException("invalid requestUrl " +
> >> > > requestUrl);
> >> > > > > > }
> >> > > > > > }
> >> > > > > >
> >> > > > > > from FilesOperations:
> >> > > > > > public static void inputStreamToOutputStream(InputStream
> >> in,
> >> > > > > > OutputStream out) throws IOException {
> >> > > > > > try {
> >> > > > > > byte[ ] buf = new byte[32 * 1024]; // 32K buffer
> >> > > > > > int bytesRead;
> >> > > > > > while ((bytesRead = in.read(buf)) != -1) {
> >> > > > > > out.write(buf, 0, bytesRead);
> >> > > > > > }
> >> > > > > > } finally {
> >> > > > > > if (in != null) {
> >> > > > > > in.close();
> >> > > > > > out.close();
> >> > > > > > }
> >> > > > > > }
> >> > > > > > }
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > > > *Long*:
> >> > > > > > > > SSL certificates have a period of expiration and in the
> >> case of
> >> > > > > > > > Letsencrypt, it's set to 3 months as they think everyone
> >> should
> >> > > > have
> >> > > > > > the
> >> > > > > > > > renewal mechanism automatically.
> >> > > > > > > >
> >> > > > > > > > As the Letsencrypt is the most popular SSL issuing
> authority
> >> > > > (source:
> >> > > > > > > > https://trends.builtwith.com/ssl/LetsEncrypt ), I think
> >> Tomcat
> >> > > > > should
> >> > > > > > > have
> >> > > > > > > > an integration with Letsencrypt working flawlessly.
> >> > > > > > > >
> >> > > > > > > > We are currently using the script to renew the certificate
> >> (I
> >> > can
> >> > > > > share
> >> > > > > > > our
> >> > > > > > > > integration details with whoever is interested, please
> >> email me
> >> > > if
> >> > > > > you
> >> > > > > > > are
> >> > > > > > > > interested), but it's restarting Tomcat.
> >> > > > > > > >
> >> > > > > > > > As Tomcat shall not be restarted ever (ideally), I think
> >> Tomcat
> >> > > > > should
> >> > > > > > > have
> >> > > > > > > > an option to reload certificate, without a dependency to
> >> Tomcat
> >> > > > > source
> >> > > > > > > code
> >> > > > > > > > and "hacks" like some available on StackOverflow:
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> >> > > > > > > ).
> >> > > > > > > > Those hacks are no good as:
> >> > > > > > > > 1) code to reload certificate should not run inside Java
> >> code,
> >> > as
> >> > > > > > > > letsencrypt is invoked through Linux
> >> > > > > > > > 2) each application uses that Stackoverflow hack have
> >> > additional
> >> > > > > > compile
> >> > > > > > > > and run dependency set to Tomcat (which is very bad).
> >> > > > > > > >
> >> > > > > > > > I have a proposal on how this should be fixed: Tomcat
> should
> >> > > have a
> >> > > > > > > > server.xml options something like
> >> certificateReloadAfterDays or
> >> > > > > > > > reloadAfterDays
> >> > > > > > > >
> >> > > > > > > > I see this is moved to SSLHostConfig, we are still using
> old
> >> > > > params.
> >> > > > > > > >
> >> > > > > > > > Do you agree on this feature?
> >> > > > > > > >
> >> > > > > > > > If so... I'm not lazy to try to do it myself, but as I
> >> haven't
> >> > > ever
> >> > > > > > > written
> >> > > > > > > > Tomcat code neither know procedures (I have been coding
> >> > > > > professionally
> >> > > > > > > > since 2006, but I never committed to Maven or Git project
> >> > before,
> >> > > > > lol),
> >> > > > > > > is
> >> > > > > > > > there someone else who is keen on doing this feature?
> >> > > > > > >
> >> > > > > > > Have a look at this:
> >> > > > > > >
> >> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> >> > > > > > >
> >> > > > > > > -chris
> >> > > > > > >
> >> > > > > > >
> >> > >
> ---------------------------------------------------------------------
> >> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> > > > > > > For additional commands, e-mail: dev-help@tomcat.apache.org
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Mladen Adamović <ml...@gmail.com>.
As I haven't received more replies on this topic, I'm guessing project
maintainers are not interested in reviewing and including the code for
simpler Letsencrypt integration and discussing the mentioned SSL
documentation improvements?
Enabling AMCE response servlet (good idea by default) would be a good step
in my opinion?
My procedure is explained here:
https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
and the step "Configure HTTP redirect application with support to ACME
challenge" could be integrated into Tomcat easily.
In the case that is integrated, I can write a new improved tutorial/process.
On Sat, Dec 19, 2020 at 11:09 PM Mladen Adamović <ml...@gmail.com>
wrote:
> On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> It moves the problem elsewhere, how would the CLI communicate with tomcat?
>> JMX, HTTP uses a port, a file based communication would be probably worse
>> because of perms and other admin issues (and just not working in k8s).
>>
>
> I don't see other sane ways actually. So it seems a web-based manager with
> curl is there to stay (for the time being at least).
>
> To Chris: It's somewhat weird that the user needs a web manager just for
> curl-ing certification renewal.
>
> To everyone:
> I have a suggestion on improving Documentation regarding SSL.
> https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
> Currently, it states
> Configuration
> Prepare the Certificate Keystore
> Tomcat currently operates only on JKS, PKCS11 or PKCS12 format keystores.
>
> ...
>
>
> I think it should start with
> Configuration
> Option 1) Use Tomcat Native
> which would showcase a path to something like:
>
> <!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443 -->
> <Connector
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> port="8443"
> maxThreads="150"
> SSLEnabled="true" >
> <SSLHostConfig>
> <Certificate
> certificateKeyFile="conf/localhost-rsa-key.pem"
> certificateFile="conf/localhost-rsa-cert.pem"
> certificateChainFile="conf/localhost-rsa-chain.pem"
> type="RSA"
> />
> </SSLHostConfig>
> </Connector>
>
> Option 2) Without Tomcat Native
>
>
> ...
>
>
>
> I don't know what is the formal process for improving the documentation
> here?
>
>
>
>
>
> > > >
>> > > >
>> > > >
>> > > > >
>> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
>> > > mladen.adamovic@gmail.com
>> > > > >
>> > > > > a
>> > > > > écrit :
>> > > > >
>> > > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
>> > > > > > chris@christopherschultz.net> wrote:
>> > > > > >
>> > > > > > > Why not use cron? You can do this with a single "curl" command
>> > and
>> > > > the
>> > > > > > > Manager+JMXProxyServlet.
>> > > > > > >
>> > > > > >
>> > > > > > We are not using Tomcat manager app.
>> > > > > >
>> > > > > > Why someone should be forced to use Manager, to read/setup the
>> > > > > > documentation regarding JMXProxyServlet, create an additional
>> > > > > > servlet (where does it have dependency on?) only to reload
>> > > > automatically
>> > > > > > certificates?
>> > > > > >
>> > > > > > I'm proposing a solution with the simple SSLHostConfig
>> parameter.
>> > > It's
>> > > > a
>> > > > > > user friendly. Simple, intuitive.
>> > > > > > No need for using manager, no need to create a specific servlet
>> > > > somewhere
>> > > > > > in your code. Just a single server.xml argument.
>> > > > > >
>> > > > > > Also, *another idea*, I'm contributing this code (see below) we
>> are
>> > > > using
>> > > > > > for Letsencrypt ACME challenge.
>> > > > > > Tomcat could also have an option, i.e. in web.xml to
>> automatically
>> > > > > support
>> > > > > > Letsencrypt ACME challenge.
>> > > > > > Idea for web.xml
>> > > > > > <servlet>
>> > > > > > <servlet-name>Letsencrypt-acme</servlet-name>
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
>> > > > > > <init-param>
>> > > > > > etc.
>> > > > > > </servlet>
>> > > > > >
>> > > > > >
>> > > > > > We are using
>> > > > > > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
>> > > > > > {"/.well-known/acme-challenge/*"})
>> > > > > > public class LetsencryptAcmeChallenge extends HttpServlet {
>> > > > > >
>> > > > > > /**
>> > > > > > * Processes requests for both HTTP <code>GET</code> and
>> > > > > > <code>POST</code> methods.
>> > > > > > *
>> > > > > > * @param request servlet request
>> > > > > > * @param response servlet response
>> > > > > > * @throws ServletException if a servlet-specific error occurs
>> > > > > > * @throws IOException if an I/O error occurs
>> > > > > > */
>> > > > > > protected void processRequest(HttpServletRequest request,
>> > > > > > HttpServletResponse response)
>> > > > > > throws ServletException, IOException {
>> > > > > > String requestUrl = request.getRequestURL().toString();
>> > > > > > if (requestUrl.contains(".well-known/acme-challenge/")) {
>> > > > > > int indexFilename = requestUrl.lastIndexOf("/") + 1;
>> > > > > > boolean wasError = true;
>> > > > > > if (indexFilename > 0 && indexFilename <
>> > requestUrl.length()) {
>> > > > > > String filename = requestUrl.substring(indexFilename);
>> > > > > > File existingFile = new
>> > > > > > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/"
>> +
>> > > > > > filename);
>> > > > > > if (existingFile.exists()) {
>> > > > > > response.setContentType("text/plain");
>> > > > > > OutputStream out = response.getOutputStream();
>> > > > > > FileInputStream in = new
>> FileInputStream(existingFile);
>> > > > > > FilesOperations.inputStreamToOutputStream(in, out);
>> > > > > > wasError = false;
>> > > > > > }
>> > > > > > }
>> > > > > > if (wasError) {
>> > > > > > throw new ServletException("invalid requestUrl " +
>> > > requestUrl);
>> > > > > > }
>> > > > > > }
>> > > > > >
>> > > > > > from FilesOperations:
>> > > > > > public static void inputStreamToOutputStream(InputStream
>> in,
>> > > > > > OutputStream out) throws IOException {
>> > > > > > try {
>> > > > > > byte[ ] buf = new byte[32 * 1024]; // 32K buffer
>> > > > > > int bytesRead;
>> > > > > > while ((bytesRead = in.read(buf)) != -1) {
>> > > > > > out.write(buf, 0, bytesRead);
>> > > > > > }
>> > > > > > } finally {
>> > > > > > if (in != null) {
>> > > > > > in.close();
>> > > > > > out.close();
>> > > > > > }
>> > > > > > }
>> > > > > > }
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > > > *Long*:
>> > > > > > > > SSL certificates have a period of expiration and in the
>> case of
>> > > > > > > > Letsencrypt, it's set to 3 months as they think everyone
>> should
>> > > > have
>> > > > > > the
>> > > > > > > > renewal mechanism automatically.
>> > > > > > > >
>> > > > > > > > As the Letsencrypt is the most popular SSL issuing authority
>> > > > (source:
>> > > > > > > > https://trends.builtwith.com/ssl/LetsEncrypt ), I think
>> Tomcat
>> > > > > should
>> > > > > > > have
>> > > > > > > > an integration with Letsencrypt working flawlessly.
>> > > > > > > >
>> > > > > > > > We are currently using the script to renew the certificate
>> (I
>> > can
>> > > > > share
>> > > > > > > our
>> > > > > > > > integration details with whoever is interested, please
>> email me
>> > > if
>> > > > > you
>> > > > > > > are
>> > > > > > > > interested), but it's restarting Tomcat.
>> > > > > > > >
>> > > > > > > > As Tomcat shall not be restarted ever (ideally), I think
>> Tomcat
>> > > > > should
>> > > > > > > have
>> > > > > > > > an option to reload certificate, without a dependency to
>> Tomcat
>> > > > > source
>> > > > > > > code
>> > > > > > > > and "hacks" like some available on StackOverflow:
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
>> > > > > > > ).
>> > > > > > > > Those hacks are no good as:
>> > > > > > > > 1) code to reload certificate should not run inside Java
>> code,
>> > as
>> > > > > > > > letsencrypt is invoked through Linux
>> > > > > > > > 2) each application uses that Stackoverflow hack have
>> > additional
>> > > > > > compile
>> > > > > > > > and run dependency set to Tomcat (which is very bad).
>> > > > > > > >
>> > > > > > > > I have a proposal on how this should be fixed: Tomcat should
>> > > have a
>> > > > > > > > server.xml options something like
>> certificateReloadAfterDays or
>> > > > > > > > reloadAfterDays
>> > > > > > > >
>> > > > > > > > I see this is moved to SSLHostConfig, we are still using old
>> > > > params.
>> > > > > > > >
>> > > > > > > > Do you agree on this feature?
>> > > > > > > >
>> > > > > > > > If so... I'm not lazy to try to do it myself, but as I
>> haven't
>> > > ever
>> > > > > > > written
>> > > > > > > > Tomcat code neither know procedures (I have been coding
>> > > > > professionally
>> > > > > > > > since 2006, but I never committed to Maven or Git project
>> > before,
>> > > > > lol),
>> > > > > > > is
>> > > > > > > > there someone else who is keen on doing this feature?
>> > > > > > >
>> > > > > > > Have a look at this:
>> > > > > > >
>> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
>> > > > > > >
>> > > > > > > -chris
>> > > > > > >
>> > > > > > >
>> > > ---------------------------------------------------------------------
>> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> > > > > > > For additional commands, e-mail: dev-help@tomcat.apache.org
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Mladen Adamović <ml...@gmail.com>.
On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> It moves the problem elsewhere, how would the CLI communicate with tomcat?
> JMX, HTTP uses a port, a file based communication would be probably worse
> because of perms and other admin issues (and just not working in k8s).
>
I don't see other sane ways actually. So it seems a web-based manager with
curl is there to stay (for the time being at least).
To Chris: It's somewhat weird that the user needs a web manager just for
curl-ing certification renewal.
To everyone:
I have a suggestion on improving Documentation regarding SSL.
https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
Currently, it states
Configuration
Prepare the Certificate Keystore
Tomcat currently operates only on JKS, PKCS11 or PKCS12 format keystores.
...
I think it should start with
Configuration
Option 1) Use Tomcat Native
which would showcase a path to something like:
<!-- Define an SSL Coyote HTTP/1.1 Connector on port 8443 -->
<Connector
protocol="org.apache.coyote.http11.Http11NioProtocol"
port="8443"
maxThreads="150"
SSLEnabled="true" >
<SSLHostConfig>
<Certificate
certificateKeyFile="conf/localhost-rsa-key.pem"
certificateFile="conf/localhost-rsa-cert.pem"
certificateChainFile="conf/localhost-rsa-chain.pem"
type="RSA"
/>
</SSLHostConfig>
</Connector>
Option 2) Without Tomcat Native
...
I don't know what is the formal process for improving the documentation
here?
> > >
> > > >
> > > >
> > > > >
> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> > > mladen.adamovic@gmail.com
> > > > >
> > > > > a
> > > > > écrit :
> > > > >
> > > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> > > > > > chris@christopherschultz.net> wrote:
> > > > > >
> > > > > > > Why not use cron? You can do this with a single "curl" command
> > and
> > > > the
> > > > > > > Manager+JMXProxyServlet.
> > > > > > >
> > > > > >
> > > > > > We are not using Tomcat manager app.
> > > > > >
> > > > > > Why someone should be forced to use Manager, to read/setup the
> > > > > > documentation regarding JMXProxyServlet, create an additional
> > > > > > servlet (where does it have dependency on?) only to reload
> > > > automatically
> > > > > > certificates?
> > > > > >
> > > > > > I'm proposing a solution with the simple SSLHostConfig parameter.
> > > It's
> > > > a
> > > > > > user friendly. Simple, intuitive.
> > > > > > No need for using manager, no need to create a specific servlet
> > > > somewhere
> > > > > > in your code. Just a single server.xml argument.
> > > > > >
> > > > > > Also, *another idea*, I'm contributing this code (see below) we
> are
> > > > using
> > > > > > for Letsencrypt ACME challenge.
> > > > > > Tomcat could also have an option, i.e. in web.xml to
> automatically
> > > > > support
> > > > > > Letsencrypt ACME challenge.
> > > > > > Idea for web.xml
> > > > > > <servlet>
> > > > > > <servlet-name>Letsencrypt-acme</servlet-name>
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> > > > > > <init-param>
> > > > > > etc.
> > > > > > </servlet>
> > > > > >
> > > > > >
> > > > > > We are using
> > > > > > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> > > > > > {"/.well-known/acme-challenge/*"})
> > > > > > public class LetsencryptAcmeChallenge extends HttpServlet {
> > > > > >
> > > > > > /**
> > > > > > * Processes requests for both HTTP <code>GET</code> and
> > > > > > <code>POST</code> methods.
> > > > > > *
> > > > > > * @param request servlet request
> > > > > > * @param response servlet response
> > > > > > * @throws ServletException if a servlet-specific error occurs
> > > > > > * @throws IOException if an I/O error occurs
> > > > > > */
> > > > > > protected void processRequest(HttpServletRequest request,
> > > > > > HttpServletResponse response)
> > > > > > throws ServletException, IOException {
> > > > > > String requestUrl = request.getRequestURL().toString();
> > > > > > if (requestUrl.contains(".well-known/acme-challenge/")) {
> > > > > > int indexFilename = requestUrl.lastIndexOf("/") + 1;
> > > > > > boolean wasError = true;
> > > > > > if (indexFilename > 0 && indexFilename <
> > requestUrl.length()) {
> > > > > > String filename = requestUrl.substring(indexFilename);
> > > > > > File existingFile = new
> > > > > > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/" +
> > > > > > filename);
> > > > > > if (existingFile.exists()) {
> > > > > > response.setContentType("text/plain");
> > > > > > OutputStream out = response.getOutputStream();
> > > > > > FileInputStream in = new FileInputStream(existingFile);
> > > > > > FilesOperations.inputStreamToOutputStream(in, out);
> > > > > > wasError = false;
> > > > > > }
> > > > > > }
> > > > > > if (wasError) {
> > > > > > throw new ServletException("invalid requestUrl " +
> > > requestUrl);
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > from FilesOperations:
> > > > > > public static void inputStreamToOutputStream(InputStream in,
> > > > > > OutputStream out) throws IOException {
> > > > > > try {
> > > > > > byte[ ] buf = new byte[32 * 1024]; // 32K buffer
> > > > > > int bytesRead;
> > > > > > while ((bytesRead = in.read(buf)) != -1) {
> > > > > > out.write(buf, 0, bytesRead);
> > > > > > }
> > > > > > } finally {
> > > > > > if (in != null) {
> > > > > > in.close();
> > > > > > out.close();
> > > > > > }
> > > > > > }
> > > > > > }
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > > *Long*:
> > > > > > > > SSL certificates have a period of expiration and in the case
> of
> > > > > > > > Letsencrypt, it's set to 3 months as they think everyone
> should
> > > > have
> > > > > > the
> > > > > > > > renewal mechanism automatically.
> > > > > > > >
> > > > > > > > As the Letsencrypt is the most popular SSL issuing authority
> > > > (source:
> > > > > > > > https://trends.builtwith.com/ssl/LetsEncrypt ), I think
> Tomcat
> > > > > should
> > > > > > > have
> > > > > > > > an integration with Letsencrypt working flawlessly.
> > > > > > > >
> > > > > > > > We are currently using the script to renew the certificate (I
> > can
> > > > > share
> > > > > > > our
> > > > > > > > integration details with whoever is interested, please email
> me
> > > if
> > > > > you
> > > > > > > are
> > > > > > > > interested), but it's restarting Tomcat.
> > > > > > > >
> > > > > > > > As Tomcat shall not be restarted ever (ideally), I think
> Tomcat
> > > > > should
> > > > > > > have
> > > > > > > > an option to reload certificate, without a dependency to
> Tomcat
> > > > > source
> > > > > > > code
> > > > > > > > and "hacks" like some available on StackOverflow:
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> > > > > > > ).
> > > > > > > > Those hacks are no good as:
> > > > > > > > 1) code to reload certificate should not run inside Java
> code,
> > as
> > > > > > > > letsencrypt is invoked through Linux
> > > > > > > > 2) each application uses that Stackoverflow hack have
> > additional
> > > > > > compile
> > > > > > > > and run dependency set to Tomcat (which is very bad).
> > > > > > > >
> > > > > > > > I have a proposal on how this should be fixed: Tomcat should
> > > have a
> > > > > > > > server.xml options something like certificateReloadAfterDays
> or
> > > > > > > > reloadAfterDays
> > > > > > > >
> > > > > > > > I see this is moved to SSLHostConfig, we are still using old
> > > > params.
> > > > > > > >
> > > > > > > > Do you agree on this feature?
> > > > > > > >
> > > > > > > > If so... I'm not lazy to try to do it myself, but as I
> haven't
> > > ever
> > > > > > > written
> > > > > > > > Tomcat code neither know procedures (I have been coding
> > > > > professionally
> > > > > > > > since 2006, but I never committed to Maven or Git project
> > before,
> > > > > lol),
> > > > > > > is
> > > > > > > > there someone else who is keen on doing this feature?
> > > > > > >
> > > > > > > Have a look at this:
> > > > > > >
> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> > > > > > >
> > > > > > > -chris
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > > > > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le sam. 19 déc. 2020 à 17:34, Mladen Adamović <ml...@gmail.com> a
écrit :
> On Sat, Dec 19, 2020 at 5:06 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Code can likely be simplified but high level it is just about enabling
> > letsencrypt http dance thanks a valve and reloading the cert on update.
> >
> > Note that acme client is easy to recode to avoid any licensing work so it
> > vould be a tomcat-letsencrypt module easily IMHO.
> >
>
>
> Thinking more about this problem... instead of this reload SSL
> configuration feature, we need fully integrated support for Letsencrypt.
>
+1
>
> On a side note, Tomcat might be lacking a command line manager utility,
> having manager running on a port sounds... like we are people who avoid a
> command line, no?
>
It moves the problem elsewhere, how would the CLI communicate with tomcat?
JMX, HTTP uses a port, a file based communication would be probably worse
because of perms and other admin issues (and just not working in k8s).
Personally I think today it is not really an issue because typically it is
either automatic or it is not due to the deployers/schedulers we use today
(k8s the first one);
>
> Although I managed my own way of integration, and wrote my own ACME client,
> I don't know yet what Tomcat needs to do to be fully Letsencrypt
> integrated.
>
Think what is in meecrowave is more or less what is needed - except the
config which is not "tomcat spirit". Main issue is: will known folder be
publicly available or hidden behind a proxy preventing the integration to
work?
But I guess a default integration module can assume it is available.
>
> Are there someone currently working on easy letsencrypt integration?
> If not, Romain (or others who are reading this thread), are there existing
> devs who want to do it?
> I'm ready to join, if someone wants the assistance, but it would probably
> be helpful not to duplicate efforts.
>
Not active but happy to help if needed. In particular to get a HTTP lets
encrypt client not using acme client (plain java 11 client or even http url
connection if java 8 is required for this module).
>
> The question to project maintainers: would be interested in reviewing that
> code for inclusion in the codebase?
> (I'm not sure yet how it goes, I'm new here. Certainly, the fact that I
> never contributed code to the open-source project which wasn't started by
> me doesn't help).
>
Side note: worse case it could fit meecrowave module. Just means making an
abstract class and 2 subclasses with configuration 1. tomcat style 2.
meecrowave style. Just an idea but can be a home for that module if tomcat
is not.
>
>
>
>
>
>
> >
> >
> > > Ideally, users want Tomcat listed here: https://certbot.eff.org/ as a
> > > fully
> > > supported server.
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> > mladen.adamovic@gmail.com
> > > >
> > > > a
> > > > écrit :
> > > >
> > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> > > > > chris@christopherschultz.net> wrote:
> > > > >
> > > > > > Why not use cron? You can do this with a single "curl" command
> and
> > > the
> > > > > > Manager+JMXProxyServlet.
> > > > > >
> > > > >
> > > > > We are not using Tomcat manager app.
> > > > >
> > > > > Why someone should be forced to use Manager, to read/setup the
> > > > > documentation regarding JMXProxyServlet, create an additional
> > > > > servlet (where does it have dependency on?) only to reload
> > > automatically
> > > > > certificates?
> > > > >
> > > > > I'm proposing a solution with the simple SSLHostConfig parameter.
> > It's
> > > a
> > > > > user friendly. Simple, intuitive.
> > > > > No need for using manager, no need to create a specific servlet
> > > somewhere
> > > > > in your code. Just a single server.xml argument.
> > > > >
> > > > > Also, *another idea*, I'm contributing this code (see below) we are
> > > using
> > > > > for Letsencrypt ACME challenge.
> > > > > Tomcat could also have an option, i.e. in web.xml to automatically
> > > > support
> > > > > Letsencrypt ACME challenge.
> > > > > Idea for web.xml
> > > > > <servlet>
> > > > > <servlet-name>Letsencrypt-acme</servlet-name>
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> > > > > <init-param>
> > > > > etc.
> > > > > </servlet>
> > > > >
> > > > >
> > > > > We are using
> > > > > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> > > > > {"/.well-known/acme-challenge/*"})
> > > > > public class LetsencryptAcmeChallenge extends HttpServlet {
> > > > >
> > > > > /**
> > > > > * Processes requests for both HTTP <code>GET</code> and
> > > > > <code>POST</code> methods.
> > > > > *
> > > > > * @param request servlet request
> > > > > * @param response servlet response
> > > > > * @throws ServletException if a servlet-specific error occurs
> > > > > * @throws IOException if an I/O error occurs
> > > > > */
> > > > > protected void processRequest(HttpServletRequest request,
> > > > > HttpServletResponse response)
> > > > > throws ServletException, IOException {
> > > > > String requestUrl = request.getRequestURL().toString();
> > > > > if (requestUrl.contains(".well-known/acme-challenge/")) {
> > > > > int indexFilename = requestUrl.lastIndexOf("/") + 1;
> > > > > boolean wasError = true;
> > > > > if (indexFilename > 0 && indexFilename <
> requestUrl.length()) {
> > > > > String filename = requestUrl.substring(indexFilename);
> > > > > File existingFile = new
> > > > > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/" +
> > > > > filename);
> > > > > if (existingFile.exists()) {
> > > > > response.setContentType("text/plain");
> > > > > OutputStream out = response.getOutputStream();
> > > > > FileInputStream in = new FileInputStream(existingFile);
> > > > > FilesOperations.inputStreamToOutputStream(in, out);
> > > > > wasError = false;
> > > > > }
> > > > > }
> > > > > if (wasError) {
> > > > > throw new ServletException("invalid requestUrl " +
> > requestUrl);
> > > > > }
> > > > > }
> > > > >
> > > > > from FilesOperations:
> > > > > public static void inputStreamToOutputStream(InputStream in,
> > > > > OutputStream out) throws IOException {
> > > > > try {
> > > > > byte[ ] buf = new byte[32 * 1024]; // 32K buffer
> > > > > int bytesRead;
> > > > > while ((bytesRead = in.read(buf)) != -1) {
> > > > > out.write(buf, 0, bytesRead);
> > > > > }
> > > > > } finally {
> > > > > if (in != null) {
> > > > > in.close();
> > > > > out.close();
> > > > > }
> > > > > }
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > > *Long*:
> > > > > > > SSL certificates have a period of expiration and in the case of
> > > > > > > Letsencrypt, it's set to 3 months as they think everyone should
> > > have
> > > > > the
> > > > > > > renewal mechanism automatically.
> > > > > > >
> > > > > > > As the Letsencrypt is the most popular SSL issuing authority
> > > (source:
> > > > > > > https://trends.builtwith.com/ssl/LetsEncrypt ), I think Tomcat
> > > > should
> > > > > > have
> > > > > > > an integration with Letsencrypt working flawlessly.
> > > > > > >
> > > > > > > We are currently using the script to renew the certificate (I
> can
> > > > share
> > > > > > our
> > > > > > > integration details with whoever is interested, please email me
> > if
> > > > you
> > > > > > are
> > > > > > > interested), but it's restarting Tomcat.
> > > > > > >
> > > > > > > As Tomcat shall not be restarted ever (ideally), I think Tomcat
> > > > should
> > > > > > have
> > > > > > > an option to reload certificate, without a dependency to Tomcat
> > > > source
> > > > > > code
> > > > > > > and "hacks" like some available on StackOverflow:
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> > > > > > ).
> > > > > > > Those hacks are no good as:
> > > > > > > 1) code to reload certificate should not run inside Java code,
> as
> > > > > > > letsencrypt is invoked through Linux
> > > > > > > 2) each application uses that Stackoverflow hack have
> additional
> > > > > compile
> > > > > > > and run dependency set to Tomcat (which is very bad).
> > > > > > >
> > > > > > > I have a proposal on how this should be fixed: Tomcat should
> > have a
> > > > > > > server.xml options something like certificateReloadAfterDays or
> > > > > > > reloadAfterDays
> > > > > > >
> > > > > > > I see this is moved to SSLHostConfig, we are still using old
> > > params.
> > > > > > >
> > > > > > > Do you agree on this feature?
> > > > > > >
> > > > > > > If so... I'm not lazy to try to do it myself, but as I haven't
> > ever
> > > > > > written
> > > > > > > Tomcat code neither know procedures (I have been coding
> > > > professionally
> > > > > > > since 2006, but I never committed to Maven or Git project
> before,
> > > > lol),
> > > > > > is
> > > > > > > there someone else who is keen on doing this feature?
> > > > > >
> > > > > > Have a look at this:
> > > > > > http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> > > > > >
> > > > > > -chris
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > > > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [OT] feature request: reload SSL certificate automatically after
X days (configuration option)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mladen,
On 12/19/20 11:33, Mladen Adamović wrote:
> On Sat, Dec 19, 2020 at 5:06 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> On a side note, Tomcat might be lacking a command line manager utility,
> having manager running on a port sounds... like we are people who avoid a
> command line, no?
There is a command-line manager: it's called curl and you use it with
the Manager web application. You said you didn't want to use that, so
... I guess you are out of luck.
Anything other than curl + JMXProxyServlet will be not sane. JMX can do
pretty much anything; developing another protocol for another
command-line interface is not a good use of anyone's time.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Mladen Adamović <ml...@gmail.com>.
On Sat, Dec 19, 2020 at 5:06 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Code can likely be simplified but high level it is just about enabling
> letsencrypt http dance thanks a valve and reloading the cert on update.
>
> Note that acme client is easy to recode to avoid any licensing work so it
> vould be a tomcat-letsencrypt module easily IMHO.
>
Thinking more about this problem... instead of this reload SSL
configuration feature, we need fully integrated support for Letsencrypt.
On a side note, Tomcat might be lacking a command line manager utility,
having manager running on a port sounds... like we are people who avoid a
command line, no?
Although I managed my own way of integration, and wrote my own ACME client,
I don't know yet what Tomcat needs to do to be fully Letsencrypt
integrated.
Are there someone currently working on easy letsencrypt integration?
If not, Romain (or others who are reading this thread), are there existing
devs who want to do it?
I'm ready to join, if someone wants the assistance, but it would probably
be helpful not to duplicate efforts.
The question to project maintainers: would be interested in reviewing that
code for inclusion in the codebase?
(I'm not sure yet how it goes, I'm new here. Certainly, the fact that I
never contributed code to the open-source project which wasn't started by
me doesn't help).
>
>
> > Ideally, users want Tomcat listed here: https://certbot.eff.org/ as a
> > fully
> > supported server.
> >
> >
> >
> >
> >
> >
> > >
> > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> mladen.adamovic@gmail.com
> > >
> > > a
> > > écrit :
> > >
> > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> > > > chris@christopherschultz.net> wrote:
> > > >
> > > > > Why not use cron? You can do this with a single "curl" command and
> > the
> > > > > Manager+JMXProxyServlet.
> > > > >
> > > >
> > > > We are not using Tomcat manager app.
> > > >
> > > > Why someone should be forced to use Manager, to read/setup the
> > > > documentation regarding JMXProxyServlet, create an additional
> > > > servlet (where does it have dependency on?) only to reload
> > automatically
> > > > certificates?
> > > >
> > > > I'm proposing a solution with the simple SSLHostConfig parameter.
> It's
> > a
> > > > user friendly. Simple, intuitive.
> > > > No need for using manager, no need to create a specific servlet
> > somewhere
> > > > in your code. Just a single server.xml argument.
> > > >
> > > > Also, *another idea*, I'm contributing this code (see below) we are
> > using
> > > > for Letsencrypt ACME challenge.
> > > > Tomcat could also have an option, i.e. in web.xml to automatically
> > > support
> > > > Letsencrypt ACME challenge.
> > > > Idea for web.xml
> > > > <servlet>
> > > > <servlet-name>Letsencrypt-acme</servlet-name>
> > > >
> > > >
> > > >
> > >
> >
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> > > > <init-param>
> > > > etc.
> > > > </servlet>
> > > >
> > > >
> > > > We are using
> > > > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> > > > {"/.well-known/acme-challenge/*"})
> > > > public class LetsencryptAcmeChallenge extends HttpServlet {
> > > >
> > > > /**
> > > > * Processes requests for both HTTP <code>GET</code> and
> > > > <code>POST</code> methods.
> > > > *
> > > > * @param request servlet request
> > > > * @param response servlet response
> > > > * @throws ServletException if a servlet-specific error occurs
> > > > * @throws IOException if an I/O error occurs
> > > > */
> > > > protected void processRequest(HttpServletRequest request,
> > > > HttpServletResponse response)
> > > > throws ServletException, IOException {
> > > > String requestUrl = request.getRequestURL().toString();
> > > > if (requestUrl.contains(".well-known/acme-challenge/")) {
> > > > int indexFilename = requestUrl.lastIndexOf("/") + 1;
> > > > boolean wasError = true;
> > > > if (indexFilename > 0 && indexFilename < requestUrl.length()) {
> > > > String filename = requestUrl.substring(indexFilename);
> > > > File existingFile = new
> > > > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/" +
> > > > filename);
> > > > if (existingFile.exists()) {
> > > > response.setContentType("text/plain");
> > > > OutputStream out = response.getOutputStream();
> > > > FileInputStream in = new FileInputStream(existingFile);
> > > > FilesOperations.inputStreamToOutputStream(in, out);
> > > > wasError = false;
> > > > }
> > > > }
> > > > if (wasError) {
> > > > throw new ServletException("invalid requestUrl " +
> requestUrl);
> > > > }
> > > > }
> > > >
> > > > from FilesOperations:
> > > > public static void inputStreamToOutputStream(InputStream in,
> > > > OutputStream out) throws IOException {
> > > > try {
> > > > byte[ ] buf = new byte[32 * 1024]; // 32K buffer
> > > > int bytesRead;
> > > > while ((bytesRead = in.read(buf)) != -1) {
> > > > out.write(buf, 0, bytesRead);
> > > > }
> > > > } finally {
> > > > if (in != null) {
> > > > in.close();
> > > > out.close();
> > > > }
> > > > }
> > > > }
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > > *Long*:
> > > > > > SSL certificates have a period of expiration and in the case of
> > > > > > Letsencrypt, it's set to 3 months as they think everyone should
> > have
> > > > the
> > > > > > renewal mechanism automatically.
> > > > > >
> > > > > > As the Letsencrypt is the most popular SSL issuing authority
> > (source:
> > > > > > https://trends.builtwith.com/ssl/LetsEncrypt ), I think Tomcat
> > > should
> > > > > have
> > > > > > an integration with Letsencrypt working flawlessly.
> > > > > >
> > > > > > We are currently using the script to renew the certificate (I can
> > > share
> > > > > our
> > > > > > integration details with whoever is interested, please email me
> if
> > > you
> > > > > are
> > > > > > interested), but it's restarting Tomcat.
> > > > > >
> > > > > > As Tomcat shall not be restarted ever (ideally), I think Tomcat
> > > should
> > > > > have
> > > > > > an option to reload certificate, without a dependency to Tomcat
> > > source
> > > > > code
> > > > > > and "hacks" like some available on StackOverflow:
> > > > > >
> > > > >
> > > >
> > >
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> > > > > ).
> > > > > > Those hacks are no good as:
> > > > > > 1) code to reload certificate should not run inside Java code, as
> > > > > > letsencrypt is invoked through Linux
> > > > > > 2) each application uses that Stackoverflow hack have additional
> > > > compile
> > > > > > and run dependency set to Tomcat (which is very bad).
> > > > > >
> > > > > > I have a proposal on how this should be fixed: Tomcat should
> have a
> > > > > > server.xml options something like certificateReloadAfterDays or
> > > > > > reloadAfterDays
> > > > > >
> > > > > > I see this is moved to SSLHostConfig, we are still using old
> > params.
> > > > > >
> > > > > > Do you agree on this feature?
> > > > > >
> > > > > > If so... I'm not lazy to try to do it myself, but as I haven't
> ever
> > > > > written
> > > > > > Tomcat code neither know procedures (I have been coding
> > > professionally
> > > > > > since 2006, but I never committed to Maven or Git project before,
> > > lol),
> > > > > is
> > > > > > there someone else who is keen on doing this feature?
> > > > >
> > > > > Have a look at this:
> > > > > http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> > > > >
> > > > > -chris
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le sam. 19 déc. 2020 à 16:43, Mladen Adamović <ml...@gmail.com> a
écrit :
> On Sat, Dec 19, 2020 at 4:25 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > It sounds saner than a random reload N days since it can reload when the
> > cert changes.
> >
>
> Hi Romain,
> BTW, Letsencrypt always creates a new file:
> i.e.
> lrwxrwxrwx 1 root root 35 Dec 1 01:05 cert.pem -> ../../archive/
> numbeo.com/cert53.pem
> so random reloads should be fine AFAIK.
>
If rotation is long enough yes otherwise no so depends the letzencrypt and
cron setup.
In several cases you can end up having an expired cert for some time.
> However, if it's possible to have even more nature and easier integration
> with Letsencrypt that would be even nicer.
> I did go briefly through your code, there are many places I currently don't
> understand.
>
Code can likely be simplified but high level it is just about enabling
letsencrypt http dance thanks a valve and reloading the cert on update.
Note that acme client is easy to recode to avoid any licensing work so it
vould be a tomcat-letsencrypt module easily IMHO.
> Ideally, users want Tomcat listed here: https://certbot.eff.org/ as a
> fully
> supported server.
>
>
>
>
>
>
> >
> > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <mladen.adamovic@gmail.com
> >
> > a
> > écrit :
> >
> > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> > > chris@christopherschultz.net> wrote:
> > >
> > > > Why not use cron? You can do this with a single "curl" command and
> the
> > > > Manager+JMXProxyServlet.
> > > >
> > >
> > > We are not using Tomcat manager app.
> > >
> > > Why someone should be forced to use Manager, to read/setup the
> > > documentation regarding JMXProxyServlet, create an additional
> > > servlet (where does it have dependency on?) only to reload
> automatically
> > > certificates?
> > >
> > > I'm proposing a solution with the simple SSLHostConfig parameter. It's
> a
> > > user friendly. Simple, intuitive.
> > > No need for using manager, no need to create a specific servlet
> somewhere
> > > in your code. Just a single server.xml argument.
> > >
> > > Also, *another idea*, I'm contributing this code (see below) we are
> using
> > > for Letsencrypt ACME challenge.
> > > Tomcat could also have an option, i.e. in web.xml to automatically
> > support
> > > Letsencrypt ACME challenge.
> > > Idea for web.xml
> > > <servlet>
> > > <servlet-name>Letsencrypt-acme</servlet-name>
> > >
> > >
> > >
> >
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> > > <init-param>
> > > etc.
> > > </servlet>
> > >
> > >
> > > We are using
> > > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> > > {"/.well-known/acme-challenge/*"})
> > > public class LetsencryptAcmeChallenge extends HttpServlet {
> > >
> > > /**
> > > * Processes requests for both HTTP <code>GET</code> and
> > > <code>POST</code> methods.
> > > *
> > > * @param request servlet request
> > > * @param response servlet response
> > > * @throws ServletException if a servlet-specific error occurs
> > > * @throws IOException if an I/O error occurs
> > > */
> > > protected void processRequest(HttpServletRequest request,
> > > HttpServletResponse response)
> > > throws ServletException, IOException {
> > > String requestUrl = request.getRequestURL().toString();
> > > if (requestUrl.contains(".well-known/acme-challenge/")) {
> > > int indexFilename = requestUrl.lastIndexOf("/") + 1;
> > > boolean wasError = true;
> > > if (indexFilename > 0 && indexFilename < requestUrl.length()) {
> > > String filename = requestUrl.substring(indexFilename);
> > > File existingFile = new
> > > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/" +
> > > filename);
> > > if (existingFile.exists()) {
> > > response.setContentType("text/plain");
> > > OutputStream out = response.getOutputStream();
> > > FileInputStream in = new FileInputStream(existingFile);
> > > FilesOperations.inputStreamToOutputStream(in, out);
> > > wasError = false;
> > > }
> > > }
> > > if (wasError) {
> > > throw new ServletException("invalid requestUrl " + requestUrl);
> > > }
> > > }
> > >
> > > from FilesOperations:
> > > public static void inputStreamToOutputStream(InputStream in,
> > > OutputStream out) throws IOException {
> > > try {
> > > byte[ ] buf = new byte[32 * 1024]; // 32K buffer
> > > int bytesRead;
> > > while ((bytesRead = in.read(buf)) != -1) {
> > > out.write(buf, 0, bytesRead);
> > > }
> > > } finally {
> > > if (in != null) {
> > > in.close();
> > > out.close();
> > > }
> > > }
> > > }
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > > *Long*:
> > > > > SSL certificates have a period of expiration and in the case of
> > > > > Letsencrypt, it's set to 3 months as they think everyone should
> have
> > > the
> > > > > renewal mechanism automatically.
> > > > >
> > > > > As the Letsencrypt is the most popular SSL issuing authority
> (source:
> > > > > https://trends.builtwith.com/ssl/LetsEncrypt ), I think Tomcat
> > should
> > > > have
> > > > > an integration with Letsencrypt working flawlessly.
> > > > >
> > > > > We are currently using the script to renew the certificate (I can
> > share
> > > > our
> > > > > integration details with whoever is interested, please email me if
> > you
> > > > are
> > > > > interested), but it's restarting Tomcat.
> > > > >
> > > > > As Tomcat shall not be restarted ever (ideally), I think Tomcat
> > should
> > > > have
> > > > > an option to reload certificate, without a dependency to Tomcat
> > source
> > > > code
> > > > > and "hacks" like some available on StackOverflow:
> > > > >
> > > >
> > >
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> > > > ).
> > > > > Those hacks are no good as:
> > > > > 1) code to reload certificate should not run inside Java code, as
> > > > > letsencrypt is invoked through Linux
> > > > > 2) each application uses that Stackoverflow hack have additional
> > > compile
> > > > > and run dependency set to Tomcat (which is very bad).
> > > > >
> > > > > I have a proposal on how this should be fixed: Tomcat should have a
> > > > > server.xml options something like certificateReloadAfterDays or
> > > > > reloadAfterDays
> > > > >
> > > > > I see this is moved to SSLHostConfig, we are still using old
> params.
> > > > >
> > > > > Do you agree on this feature?
> > > > >
> > > > > If so... I'm not lazy to try to do it myself, but as I haven't ever
> > > > written
> > > > > Tomcat code neither know procedures (I have been coding
> > professionally
> > > > > since 2006, but I never committed to Maven or Git project before,
> > lol),
> > > > is
> > > > > there someone else who is keen on doing this feature?
> > > >
> > > > Have a look at this:
> > > > http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> > > >
> > > > -chris
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > > >
> > > >
> > >
> >
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Mladen Adamović <ml...@gmail.com>.
On Sat, Dec 19, 2020 at 4:25 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> It sounds saner than a random reload N days since it can reload when the
> cert changes.
>
Hi Romain,
BTW, Letsencrypt always creates a new file:
i.e.
lrwxrwxrwx 1 root root 35 Dec 1 01:05 cert.pem -> ../../archive/
numbeo.com/cert53.pem
so random reloads should be fine AFAIK.
However, if it's possible to have even more nature and easier integration
with Letsencrypt that would be even nicer.
I did go briefly through your code, there are many places I currently don't
understand.
Ideally, users want Tomcat listed here: https://certbot.eff.org/ as a fully
supported server.
>
> Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <ml...@gmail.com>
> a
> écrit :
>
> > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> > chris@christopherschultz.net> wrote:
> >
> > > Why not use cron? You can do this with a single "curl" command and the
> > > Manager+JMXProxyServlet.
> > >
> >
> > We are not using Tomcat manager app.
> >
> > Why someone should be forced to use Manager, to read/setup the
> > documentation regarding JMXProxyServlet, create an additional
> > servlet (where does it have dependency on?) only to reload automatically
> > certificates?
> >
> > I'm proposing a solution with the simple SSLHostConfig parameter. It's a
> > user friendly. Simple, intuitive.
> > No need for using manager, no need to create a specific servlet somewhere
> > in your code. Just a single server.xml argument.
> >
> > Also, *another idea*, I'm contributing this code (see below) we are using
> > for Letsencrypt ACME challenge.
> > Tomcat could also have an option, i.e. in web.xml to automatically
> support
> > Letsencrypt ACME challenge.
> > Idea for web.xml
> > <servlet>
> > <servlet-name>Letsencrypt-acme</servlet-name>
> >
> >
> >
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> > <init-param>
> > etc.
> > </servlet>
> >
> >
> > We are using
> > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> > {"/.well-known/acme-challenge/*"})
> > public class LetsencryptAcmeChallenge extends HttpServlet {
> >
> > /**
> > * Processes requests for both HTTP <code>GET</code> and
> > <code>POST</code> methods.
> > *
> > * @param request servlet request
> > * @param response servlet response
> > * @throws ServletException if a servlet-specific error occurs
> > * @throws IOException if an I/O error occurs
> > */
> > protected void processRequest(HttpServletRequest request,
> > HttpServletResponse response)
> > throws ServletException, IOException {
> > String requestUrl = request.getRequestURL().toString();
> > if (requestUrl.contains(".well-known/acme-challenge/")) {
> > int indexFilename = requestUrl.lastIndexOf("/") + 1;
> > boolean wasError = true;
> > if (indexFilename > 0 && indexFilename < requestUrl.length()) {
> > String filename = requestUrl.substring(indexFilename);
> > File existingFile = new
> > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/" +
> > filename);
> > if (existingFile.exists()) {
> > response.setContentType("text/plain");
> > OutputStream out = response.getOutputStream();
> > FileInputStream in = new FileInputStream(existingFile);
> > FilesOperations.inputStreamToOutputStream(in, out);
> > wasError = false;
> > }
> > }
> > if (wasError) {
> > throw new ServletException("invalid requestUrl " + requestUrl);
> > }
> > }
> >
> > from FilesOperations:
> > public static void inputStreamToOutputStream(InputStream in,
> > OutputStream out) throws IOException {
> > try {
> > byte[ ] buf = new byte[32 * 1024]; // 32K buffer
> > int bytesRead;
> > while ((bytesRead = in.read(buf)) != -1) {
> > out.write(buf, 0, bytesRead);
> > }
> > } finally {
> > if (in != null) {
> > in.close();
> > out.close();
> > }
> > }
> > }
> >
> >
> >
> >
> >
> >
> >
> >
> > > > *Long*:
> > > > SSL certificates have a period of expiration and in the case of
> > > > Letsencrypt, it's set to 3 months as they think everyone should have
> > the
> > > > renewal mechanism automatically.
> > > >
> > > > As the Letsencrypt is the most popular SSL issuing authority (source:
> > > > https://trends.builtwith.com/ssl/LetsEncrypt ), I think Tomcat
> should
> > > have
> > > > an integration with Letsencrypt working flawlessly.
> > > >
> > > > We are currently using the script to renew the certificate (I can
> share
> > > our
> > > > integration details with whoever is interested, please email me if
> you
> > > are
> > > > interested), but it's restarting Tomcat.
> > > >
> > > > As Tomcat shall not be restarted ever (ideally), I think Tomcat
> should
> > > have
> > > > an option to reload certificate, without a dependency to Tomcat
> source
> > > code
> > > > and "hacks" like some available on StackOverflow:
> > > >
> > >
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> > > ).
> > > > Those hacks are no good as:
> > > > 1) code to reload certificate should not run inside Java code, as
> > > > letsencrypt is invoked through Linux
> > > > 2) each application uses that Stackoverflow hack have additional
> > compile
> > > > and run dependency set to Tomcat (which is very bad).
> > > >
> > > > I have a proposal on how this should be fixed: Tomcat should have a
> > > > server.xml options something like certificateReloadAfterDays or
> > > > reloadAfterDays
> > > >
> > > > I see this is moved to SSLHostConfig, we are still using old params.
> > > >
> > > > Do you agree on this feature?
> > > >
> > > > If so... I'm not lazy to try to do it myself, but as I haven't ever
> > > written
> > > > Tomcat code neither know procedures (I have been coding
> professionally
> > > > since 2006, but I never committed to Maven or Git project before,
> lol),
> > > is
> > > > there someone else who is keen on doing this feature?
> > >
> > > Have a look at this:
> > > http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> > >
> > > -chris
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > >
> > >
> >
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
https://github.com/apache/openwebbeans-meecrowave/tree/master/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt
should be reusable just dropping the few references to meeceowave and
replacing it by valve or listener config in server.xml.
It sounds saner than a random reload N days since it can reload when the
cert changes.
Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <ml...@gmail.com> a
écrit :
> On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
> > Why not use cron? You can do this with a single "curl" command and the
> > Manager+JMXProxyServlet.
> >
>
> We are not using Tomcat manager app.
>
> Why someone should be forced to use Manager, to read/setup the
> documentation regarding JMXProxyServlet, create an additional
> servlet (where does it have dependency on?) only to reload automatically
> certificates?
>
> I'm proposing a solution with the simple SSLHostConfig parameter. It's a
> user friendly. Simple, intuitive.
> No need for using manager, no need to create a specific servlet somewhere
> in your code. Just a single server.xml argument.
>
> Also, *another idea*, I'm contributing this code (see below) we are using
> for Letsencrypt ACME challenge.
> Tomcat could also have an option, i.e. in web.xml to automatically support
> Letsencrypt ACME challenge.
> Idea for web.xml
> <servlet>
> <servlet-name>Letsencrypt-acme</servlet-name>
>
>
> <servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
> <init-param>
> etc.
> </servlet>
>
>
> We are using
> @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> {"/.well-known/acme-challenge/*"})
> public class LetsencryptAcmeChallenge extends HttpServlet {
>
> /**
> * Processes requests for both HTTP <code>GET</code> and
> <code>POST</code> methods.
> *
> * @param request servlet request
> * @param response servlet response
> * @throws ServletException if a servlet-specific error occurs
> * @throws IOException if an I/O error occurs
> */
> protected void processRequest(HttpServletRequest request,
> HttpServletResponse response)
> throws ServletException, IOException {
> String requestUrl = request.getRequestURL().toString();
> if (requestUrl.contains(".well-known/acme-challenge/")) {
> int indexFilename = requestUrl.lastIndexOf("/") + 1;
> boolean wasError = true;
> if (indexFilename > 0 && indexFilename < requestUrl.length()) {
> String filename = requestUrl.substring(indexFilename);
> File existingFile = new
> File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/" +
> filename);
> if (existingFile.exists()) {
> response.setContentType("text/plain");
> OutputStream out = response.getOutputStream();
> FileInputStream in = new FileInputStream(existingFile);
> FilesOperations.inputStreamToOutputStream(in, out);
> wasError = false;
> }
> }
> if (wasError) {
> throw new ServletException("invalid requestUrl " + requestUrl);
> }
> }
>
> from FilesOperations:
> public static void inputStreamToOutputStream(InputStream in,
> OutputStream out) throws IOException {
> try {
> byte[ ] buf = new byte[32 * 1024]; // 32K buffer
> int bytesRead;
> while ((bytesRead = in.read(buf)) != -1) {
> out.write(buf, 0, bytesRead);
> }
> } finally {
> if (in != null) {
> in.close();
> out.close();
> }
> }
> }
>
>
>
>
>
>
>
>
> > > *Long*:
> > > SSL certificates have a period of expiration and in the case of
> > > Letsencrypt, it's set to 3 months as they think everyone should have
> the
> > > renewal mechanism automatically.
> > >
> > > As the Letsencrypt is the most popular SSL issuing authority (source:
> > > https://trends.builtwith.com/ssl/LetsEncrypt ), I think Tomcat should
> > have
> > > an integration with Letsencrypt working flawlessly.
> > >
> > > We are currently using the script to renew the certificate (I can share
> > our
> > > integration details with whoever is interested, please email me if you
> > are
> > > interested), but it's restarting Tomcat.
> > >
> > > As Tomcat shall not be restarted ever (ideally), I think Tomcat should
> > have
> > > an option to reload certificate, without a dependency to Tomcat source
> > code
> > > and "hacks" like some available on StackOverflow:
> > >
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> > ).
> > > Those hacks are no good as:
> > > 1) code to reload certificate should not run inside Java code, as
> > > letsencrypt is invoked through Linux
> > > 2) each application uses that Stackoverflow hack have additional
> compile
> > > and run dependency set to Tomcat (which is very bad).
> > >
> > > I have a proposal on how this should be fixed: Tomcat should have a
> > > server.xml options something like certificateReloadAfterDays or
> > > reloadAfterDays
> > >
> > > I see this is moved to SSLHostConfig, we are still using old params.
> > >
> > > Do you agree on this feature?
> > >
> > > If so... I'm not lazy to try to do it myself, but as I haven't ever
> > written
> > > Tomcat code neither know procedures (I have been coding professionally
> > > since 2006, but I never committed to Maven or Git project before, lol),
> > is
> > > there someone else who is keen on doing this feature?
> >
> > Have a look at this:
> > http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> >
> > -chris
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Mladen Adamović <ml...@gmail.com>.
On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
chris@christopherschultz.net> wrote:
> Why not use cron? You can do this with a single "curl" command and the
> Manager+JMXProxyServlet.
>
We are not using Tomcat manager app.
Why someone should be forced to use Manager, to read/setup the
documentation regarding JMXProxyServlet, create an additional
servlet (where does it have dependency on?) only to reload automatically
certificates?
I'm proposing a solution with the simple SSLHostConfig parameter. It's a
user friendly. Simple, intuitive.
No need for using manager, no need to create a specific servlet somewhere
in your code. Just a single server.xml argument.
Also, *another idea*, I'm contributing this code (see below) we are using
for Letsencrypt ACME challenge.
Tomcat could also have an option, i.e. in web.xml to automatically support
Letsencrypt ACME challenge.
Idea for web.xml
<servlet>
<servlet-name>Letsencrypt-acme</servlet-name>
<servlet-class>org.apache.catalina.servlets.LetsencryptAcmeChallenge</servlet-class>
<init-param>
etc.
</servlet>
We are using
@WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
{"/.well-known/acme-challenge/*"})
public class LetsencryptAcmeChallenge extends HttpServlet {
/**
* Processes requests for both HTTP <code>GET</code> and
<code>POST</code> methods.
*
* @param request servlet request
* @param response servlet response
* @throws ServletException if a servlet-specific error occurs
* @throws IOException if an I/O error occurs
*/
protected void processRequest(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
String requestUrl = request.getRequestURL().toString();
if (requestUrl.contains(".well-known/acme-challenge/")) {
int indexFilename = requestUrl.lastIndexOf("/") + 1;
boolean wasError = true;
if (indexFilename > 0 && indexFilename < requestUrl.length()) {
String filename = requestUrl.substring(indexFilename);
File existingFile = new
File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/" +
filename);
if (existingFile.exists()) {
response.setContentType("text/plain");
OutputStream out = response.getOutputStream();
FileInputStream in = new FileInputStream(existingFile);
FilesOperations.inputStreamToOutputStream(in, out);
wasError = false;
}
}
if (wasError) {
throw new ServletException("invalid requestUrl " + requestUrl);
}
}
from FilesOperations:
public static void inputStreamToOutputStream(InputStream in,
OutputStream out) throws IOException {
try {
byte[ ] buf = new byte[32 * 1024]; // 32K buffer
int bytesRead;
while ((bytesRead = in.read(buf)) != -1) {
out.write(buf, 0, bytesRead);
}
} finally {
if (in != null) {
in.close();
out.close();
}
}
}
> > *Long*:
> > SSL certificates have a period of expiration and in the case of
> > Letsencrypt, it's set to 3 months as they think everyone should have the
> > renewal mechanism automatically.
> >
> > As the Letsencrypt is the most popular SSL issuing authority (source:
> > https://trends.builtwith.com/ssl/LetsEncrypt ), I think Tomcat should
> have
> > an integration with Letsencrypt working flawlessly.
> >
> > We are currently using the script to renew the certificate (I can share
> our
> > integration details with whoever is interested, please email me if you
> are
> > interested), but it's restarting Tomcat.
> >
> > As Tomcat shall not be restarted ever (ideally), I think Tomcat should
> have
> > an option to reload certificate, without a dependency to Tomcat source
> code
> > and "hacks" like some available on StackOverflow:
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> ).
> > Those hacks are no good as:
> > 1) code to reload certificate should not run inside Java code, as
> > letsencrypt is invoked through Linux
> > 2) each application uses that Stackoverflow hack have additional compile
> > and run dependency set to Tomcat (which is very bad).
> >
> > I have a proposal on how this should be fixed: Tomcat should have a
> > server.xml options something like certificateReloadAfterDays or
> > reloadAfterDays
> >
> > I see this is moved to SSLHostConfig, we are still using old params.
> >
> > Do you agree on this feature?
> >
> > If so... I'm not lazy to try to do it myself, but as I haven't ever
> written
> > Tomcat code neither know procedures (I have been coding professionally
> > since 2006, but I never committed to Maven or Git project before, lol),
> is
> > there someone else who is keen on doing this feature?
>
> Have a look at this:
> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: feature request: reload SSL certificate automatically after X
days (configuration option)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mladen,
On 12/19/20 05:12, Mladen Adamović wrote:
> Hi guys,
>
> *Shortly*: Tomcat should have either Connector or SSLHostConfig option to
> automatically reload certificate from the same file after X days, i.e.
> reloadAfterDays=10 to force Tomcat to reload the certificate automatically
> after 10 days.
Why not use cron? You can do this with a single "curl" command and the
Manager+JMXProxyServlet.
> *Long*:
> SSL certificates have a period of expiration and in the case of
> Letsencrypt, it's set to 3 months as they think everyone should have the
> renewal mechanism automatically.
>
> As the Letsencrypt is the most popular SSL issuing authority (source:
> https://trends.builtwith.com/ssl/LetsEncrypt ), I think Tomcat should have
> an integration with Letsencrypt working flawlessly.
>
> We are currently using the script to renew the certificate (I can share our
> integration details with whoever is interested, please email me if you are
> interested), but it's restarting Tomcat.
>
> As Tomcat shall not be restarted ever (ideally), I think Tomcat should have
> an option to reload certificate, without a dependency to Tomcat source code
> and "hacks" like some available on StackOverflow:
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates).
> Those hacks are no good as:
> 1) code to reload certificate should not run inside Java code, as
> letsencrypt is invoked through Linux
> 2) each application uses that Stackoverflow hack have additional compile
> and run dependency set to Tomcat (which is very bad).
>
> I have a proposal on how this should be fixed: Tomcat should have a
> server.xml options something like certificateReloadAfterDays or
> reloadAfterDays
>
> I see this is moved to SSLHostConfig, we are still using old params.
>
> Do you agree on this feature?
>
> If so... I'm not lazy to try to do it myself, but as I haven't ever written
> Tomcat code neither know procedures (I have been coding professionally
> since 2006, but I never committed to Maven or Git project before, lol), is
> there someone else who is keen on doing this feature?
Have a look at this:
http://tomcat.apache.org/presentations.html#latest-lets-encrypt
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org