Re: Recognizing Certificate Updates

[Mladen Adamović]

Hi Christopher,

if I manage to write a code that I think would help others regarding
Letsencrypt/SSL issues, I'll send it to you.

In the meantime these instructions sent by Peter sounds good enough:
curl -u  "
https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfigs
“

Add a  to tomcat-users.xml


Beware not to open the Manager App to the public - just localhost.

Thank you,
Mladen


On Tue, Dec 29, 2020 at 3:42 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Mladen,
>
> On 12/29/20 03:46, Mladen Adamović wrote:
> > On Tue, Dec 29, 2020 at 3:18 AM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >>> Honestly, I thought that reloadAfterNDays param to server.xml would be
> >>> better, but admins didn't have an understanding on this topic.
> >>
> >> Don't be a jerk. We understand it. We are just saying that we want it
> >> built in stages. If you want radical changes, you'll need to work on a
> >> server without a decades-long history of being stable and reliable.
> >>
> >
> > Well, one thing is certainly correct here - that Tomcat at least in 2016
> > wasn't working properly on my server, Numbeo.com. The problem was noticed
> > in the past few months and the update to 9.0.47 solved the issue, so
> indeed
> > Tomcat doesn't have a stable and reliable history. I haven't complained
> > about it although.
> >
> > Regarding me being the jerk, I haven't seen regarding reloadAfterNDays
> > param that any project maintainer said something like: "I think that's a
> > good idea. If you create that code, I'll review it".
>
> We said "write it as a Valve and we'll review it." Maybe not word for
> word, but I've tried to be encouraging about you going in that
> direction. Everyone else seems to be ignoring you thus far. If you
> continue to be an ass, I'll ignore you, too.
>
> > So from my point of view, there wasn't understanding.
> >
> > It looked that Romain and you want a full ACME client without
> dependencies
> > so that Tomcat could run in containers with SSL, while it's a valid idea,
> > it seems I wouldn't be the one building that.
> >
> > There are a few reasons, i.e. I have "newbie Tomcat devs problems",  and
> > I'm not so motivated to work on a feature that makes more sense for big
> > corporations rather than a single small developers.
> >
> > To note even my question to explain to add Class javadoc
> > for LifecycleMBeanBase stayed unanswered so far in dev list, to my
> surprise.
>
> You posted that on December 27th at 02:45am in my time zone. I wasn't
> exactly looking at email around then. Or at all on Sunday. OR really
> much yesterday, the 28th. I'm on holiday, like a LOT of other people
> right now.
>
> Something that may seem like an emergency to you just ... is not so in
> the eyes of all the *unpaid volunteers* who work on this project.
>
> FTR, that's a base class for implementations of Lifecycle that also adds
> useful methods for any class which needs to implement both Lifecycle and
> also be an MBean. It it were to have class-level javadoc it would be
> something like "utility methods for things that subclass this class".
> So... not terribly helpful to someone who doesn't know what it was,
> originally. But it's also difficult to explain in clas-level javadoc
> *why* someone would want to extend that particular class.
>
> > Back in 2007, I was good enough so that Google picked me to develop the
> > software for them, I left to start my own business two years later, but I
> > have a history of not being a good team player, seeing the same things
> > differently than other people, and also I don't have a history of
> > contributing to open-source projects (unless started by myself), so
> > perhaps, at the end of the day, I'm not the good fit for Tomcat dev.
> > Anyway, as it looks now, I'll unsubscribe soon from the Tomcat dev email
> > list as it looks to me that I didn't fit.
>
> You can certainly take your ball and go home, but then everyone loses,
> right?
>
> If you are motivated to work on this, we are happy to help you.
>
> If you are instead motivated to insult everyone, complain that nobody is
> paying attention to your pet project, and refuse to accept the help and
> direction provided, then we aren't very interested.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Recognizing Certificate Updates

[Christopher Schultz]

Mladen,

On 12/29/20 03:46, Mladen Adamović wrote:

On Tue, Dec 29, 2020 at 3:18 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Honestly, I thought that reloadAfterNDays param to server.xml would be
better, but admins didn't have an understanding on this topic.


Don't be a jerk. We understand it. We are just saying that we want it
built in stages. If you want radical changes, you'll need to work on a
server without a decades-long history of being stable and reliable.



Well, one thing is certainly correct here - that Tomcat at least in 2016
wasn't working properly on my server, Numbeo.com. The problem was noticed
in the past few months and the update to 9.0.47 solved the issue, so indeed
Tomcat doesn't have a stable and reliable history. I haven't complained
about it although.

Regarding me being the jerk, I haven't seen regarding reloadAfterNDays
param that any project maintainer said something like: "I think that's a
good idea. If you create that code, I'll review it".


We said "write it as a Valve and we'll review it." Maybe not word for 
word, but I've tried to be encouraging about you going in that 
direction. Everyone else seems to be ignoring you thus far. If you 
continue to be an ass, I'll ignore you, too.



So from my point of view, there wasn't understanding.

It looked that Romain and you want a full ACME client without dependencies
so that Tomcat could run in containers with SSL, while it's a valid idea,
it seems I wouldn't be the one building that.

There are a few reasons, i.e. I have "newbie Tomcat devs problems",  and
I'm not so motivated to work on a feature that makes more sense for big
corporations rather than a single small developers.

To note even my question to explain to add Class javadoc
for LifecycleMBeanBase stayed unanswered so far in dev list, to my surprise.


You posted that on December 27th at 02:45am in my time zone. I wasn't 
exactly looking at email around then. Or at all on Sunday. OR really 
much yesterday, the 28th. I'm on holiday, like a LOT of other people 
right now.


Something that may seem like an emergency to you just ... is not so in 
the eyes of all the *unpaid volunteers* who work on this project.


FTR, that's a base class for implementations of Lifecycle that also adds 
useful methods for any class which needs to implement both Lifecycle and 
also be an MBean. It it were to have class-level javadoc it would be 
something like "utility methods for things that subclass this class". 
So... not terribly helpful to someone who doesn't know what it was, 
originally. But it's also difficult to explain in clas-level javadoc 
*why* someone would want to extend that particular class.



Back in 2007, I was good enough so that Google picked me to develop the
software for them, I left to start my own business two years later, but I
have a history of not being a good team player, seeing the same things
differently than other people, and also I don't have a history of
contributing to open-source projects (unless started by myself), so
perhaps, at the end of the day, I'm not the good fit for Tomcat dev.
Anyway, as it looks now, I'll unsubscribe soon from the Tomcat dev email
list as it looks to me that I didn't fit.


You can certainly take your ball and go home, but then everyone loses, 
right?


If you are motivated to work on this, we are happy to help you.

If you are instead motivated to insult everyone, complain that nobody is 
paying attention to your pet project, and refuse to accept the help and 
direction provided, then we aren't very interested.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Recognizing Certificate Updates

[Mladen Adamović]

On Tue, Dec 29, 2020 at 3:18 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> > Honestly, I thought that reloadAfterNDays param to server.xml would be
> > better, but admins didn't have an understanding on this topic.
>
> Don't be a jerk. We understand it. We are just saying that we want it
> built in stages. If you want radical changes, you'll need to work on a
> server without a decades-long history of being stable and reliable.
>

Well, one thing is certainly correct here - that Tomcat at least in 2016
wasn't working properly on my server, Numbeo.com. The problem was noticed
in the past few months and the update to 9.0.47 solved the issue, so indeed
Tomcat doesn't have a stable and reliable history. I haven't complained
about it although.

Regarding me being the jerk, I haven't seen regarding reloadAfterNDays
param that any project maintainer said something like: "I think that's a
good idea. If you create that code, I'll review it".

So from my point of view, there wasn't understanding.

It looked that Romain and you want a full ACME client without dependencies
so that Tomcat could run in containers with SSL, while it's a valid idea,
it seems I wouldn't be the one building that.

There are a few reasons, i.e. I have "newbie Tomcat devs problems",  and
I'm not so motivated to work on a feature that makes more sense for big
corporations rather than a single small developers.

To note even my question to explain to add Class javadoc
for LifecycleMBeanBase stayed unanswered so far in dev list, to my surprise.

Back in 2007, I was good enough so that Google picked me to develop the
software for them, I left to start my own business two years later, but I
have a history of not being a good team player, seeing the same things
differently than other people, and also I don't have a history of
contributing to open-source projects (unless started by myself), so
perhaps, at the end of the day, I'm not the good fit for Tomcat dev.
Anyway, as it looks now, I'll unsubscribe soon from the Tomcat dev email
list as it looks to me that I didn't fit.




>
> Thanks,
> -chris
>
> > On Sat, Dec 26, 2020 at 6:49 PM Jerry Malcolm 
> > wrote:
> >
> >> We have a production environment where we rarely reboot Tomcat.
> >> LetsEncrypt auto-updates the certificates every couple of months. But
> >> the new certificates are not loaded into Tomcat.  So when the original
> >> expiration date of the certs arrives, users get "certificate expired"
> >> even though new certs exist.  A simple reboot to load the new certs
> >> fixes it.  But we want to avoid reboots.  Are there any config
> >> parameters that tell TC to check for cert updates and reload the new
> >> certs?  Thx
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Recognizing Certificate Updates

[Christopher Schultz]

Jerry,

On 12/28/20 13:56, Jerry Malcolm wrote:
Thanks for the info.  I'll try to figure out a way to integrate this. 
The problem is that I don't really know when the certs get regen'd.  I 
have a daily cron job that calls certbot to renew. But it only renews 
when it decides it's time to renew.  TC is so good about monitoring 
other folders for changes such as war files, jar files, etc and 
automatically refreshing when it detects a file update.  I was just 
hoping that there was something buried inside TC that I had missed that 
tells TC to monitor the certs and refresh if the certs are updated.


Check out this presentation which includes scripts for this kind of 
thing. It shows how to detect that the LE key+cert have been actually 
updated. It also shows how to re-package those PEM files as a PKCS12 
keystore (or JKS if you like that kind of thing) and how to trigger a 
reload of the TLS configuration (including the keys + certificates).


https://tomcat.apache.org/presentations.html#latest-lets-encrypt

-chris


On 12/28/2020 4:12 AM, logo wrote:

Jerry,

the quotes were messed up.

See the correct command below inline.


Am 28.12.2020 um 11:10 schrieb logo :

Jerry,

Try this after regenerating the LE certs

curl -u  
"https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfigs 
" 



for all domains or

curl -u  
"https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfig=to reload>"


for just the needed domain.

Adjust the port to your SSL-Connector.

Add a  to tomcat-users.xml
    

Beware not to open the Manager App to the public - just localhost.

HTH

Peter



Am 26.12.2020 um 18:42 schrieb Jerry Malcolm :

We have a production environment where we rarely reboot Tomcat. 
LetsEncrypt auto-updates the certificates every couple of months. 
But the new certificates are not loaded into Tomcat.  So when the 
original expiration date of the certs arrives, users get 
"certificate expired" even though new certs exist.  A simple reboot 
to load the new certs fixes it.  But we want to avoid reboots.  Are 
there any config parameters that tell TC to check for cert updates 
and reload the new certs?  Thx



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Recognizing Certificate Updates

[Christopher Schultz]

Mladen,

On 12/26/20 13:25, Mladen Adamović wrote:

If you set up tomcat manager up, you can reload certificate with something
like
Stop Connector – curl http://localhost:8080/manager/jmxproxy?invoke=Catalina
%3Atype%3DConnector%2Cport%3D8443=stop
Start Connector – curl http://localhost:8080/manager/jmxproxy?invoke=Catalina
%3Atype%3DConnector%2Cport%3D8443=start
(source:
http://people.apache.org/~schultz/ApacheCon%20NA%202017/Let's%20Encrypt%20Apache%20Tomcat.pdf
  )

This is probably faster than reboot the whole tomcat, I haven't tried it.


It's very much faster than "rebooting" whether you mean rebooting the 
whole server or just restarting the Tomcat service. Not only that, but 
no in-flight requests or even those queued in the TCP/IP stack's backlog 
will be dropped. It really is a zero-downtime solution.



This looks imperfect as hell.


What is imperfect about it? Sure, it's not 100% automatic, but at least 
it's possible. Even Apache httpd can't do what we are doing.



Honestly, I thought that reloadAfterNDays param to server.xml would be
better, but admins didn't have an understanding on this topic.


Don't be a jerk. We understand it. We are just saying that we want it 
built in stages. If you want radical changes, you'll need to work on a 
server without a decades-long history of being stable and reliable.


Thanks,
-chris


On Sat, Dec 26, 2020 at 6:49 PM Jerry Malcolm 
wrote:


We have a production environment where we rarely reboot Tomcat.
LetsEncrypt auto-updates the certificates every couple of months. But
the new certificates are not loaded into Tomcat.  So when the original
expiration date of the certs arrives, users get "certificate expired"
even though new certs exist.  A simple reboot to load the new certs
fixes it.  But we want to avoid reboots.  Are there any config
parameters that tell TC to check for cert updates and reload the new
certs?  Thx


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org






-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Recognizing Certificate Updates

[Jerry Malcolm]

Thanks for the info.  I'll try to figure out a way to integrate this.  
The problem is that I don't really know when the certs get regen'd.  I 
have a daily cron job that calls certbot to renew. But it only renews 
when it decides it's time to renew.  TC is so good about monitoring 
other folders for changes such as war files, jar files, etc and 
automatically refreshing when it detects a file update.  I was just 
hoping that there was something buried inside TC that I had missed that 
tells TC to monitor the certs and refresh if the certs are updated.


On 12/28/2020 4:12 AM, logo wrote:

Jerry,

the quotes were messed up.

See the correct command below inline.


Am 28.12.2020 um 11:10 schrieb logo :

Jerry,

Try this after regenerating the LE certs

curl -u  
"https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfigs
 
"

for all domains or

curl -u  
"https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfig="

for just the needed domain.

Adjust the port to your SSL-Connector.

Add a  to tomcat-users.xml


Beware not to open the Manager App to the public - just localhost.

HTH

Peter



Am 26.12.2020 um 18:42 schrieb Jerry Malcolm :

We have a production environment where we rarely reboot Tomcat. LetsEncrypt auto-updates 
the certificates every couple of months. But the new certificates are not loaded into 
Tomcat.  So when the original expiration date of the certs arrives, users get 
"certificate expired" even though new certs exist.  A simple reboot to load the 
new certs fixes it.  But we want to avoid reboots.  Are there any config parameters that 
tell TC to check for cert updates and reload the new certs?  Thx


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Recognizing Certificate Updates

[logo]

Jerry,

the quotes were messed up.

See the correct command below inline.

> Am 28.12.2020 um 11:10 schrieb logo :
> 
> Jerry,
> 
> Try this after regenerating the LE certs
> 
> curl -u  
> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfigs
>  
> "
> 
> for all domains or
> 
> curl -u  
> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfig=  to reload>"
> 
> for just the needed domain.
> 
> Adjust the port to your SSL-Connector.
> 
> Add a  to tomcat-users.xml
>
> 
> Beware not to open the Manager App to the public - just localhost. 
> 
> HTH
> 
> Peter
> 
> 
>> Am 26.12.2020 um 18:42 schrieb Jerry Malcolm :
>> 
>> We have a production environment where we rarely reboot Tomcat. LetsEncrypt 
>> auto-updates the certificates every couple of months. But the new 
>> certificates are not loaded into Tomcat.  So when the original expiration 
>> date of the certs arrives, users get "certificate expired" even though new 
>> certs exist.  A simple reboot to load the new certs fixes it.  But we want 
>> to avoid reboots.  Are there any config parameters that tell TC to check for 
>> cert updates and reload the new certs?  Thx
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Re: Recognizing Certificate Updates

[logo]

Jerry,

Try this after regenerating the LE certs

curl -u  
"https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfigs“

for all domains or

curl -u  
"https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443=reloadSslHostConfig=“

for just the needed domain.

Adjust the port to your SSL-Connector.

Add a  to tomcat-users.xml


Beware not to open the Manager App to the public - just localhost. 

HTH

Peter


> Am 26.12.2020 um 18:42 schrieb Jerry Malcolm :
> 
> We have a production environment where we rarely reboot Tomcat. LetsEncrypt 
> auto-updates the certificates every couple of months. But the new 
> certificates are not loaded into Tomcat.  So when the original expiration 
> date of the certs arrives, users get "certificate expired" even though new 
> certs exist.  A simple reboot to load the new certs fixes it.  But we want to 
> avoid reboots.  Are there any config parameters that tell TC to check for 
> cert updates and reload the new certs?  Thx
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Recognizing Certificate Updates

[Mladen Adamović]

On Sat, Dec 26, 2020 at 6:46 PM John Larsen 
wrote:

> This is why we set up SSL through the web server instead of tomcat.
> Apache webserver -> SSL -> Mod_jk <-> Tomcat
>

It might be easier to install but performance-wise it doesn't make sense.
If you care about performances, I think you should make Tomcat only server
(to avoid pipelining through sockets).



>

Re: Recognizing Certificate Updates

[Mladen Adamović]

If you set up tomcat manager up, you can reload certificate with something
like
Stop Connector – curl http://localhost:8080/manager/jmxproxy?invoke=Catalina
%3Atype%3DConnector%2Cport%3D8443=stop
Start Connector – curl http://localhost:8080/manager/jmxproxy?invoke=Catalina
%3Atype%3DConnector%2Cport%3D8443=start
(source:
http://people.apache.org/~schultz/ApacheCon%20NA%202017/Let's%20Encrypt%20Apache%20Tomcat.pdf
 )

This is probably faster than reboot the whole tomcat, I haven't tried it.
This looks imperfect as hell.

Honestly, I thought that reloadAfterNDays param to server.xml would be
better, but admins didn't have an understanding on this topic.




On Sat, Dec 26, 2020 at 6:49 PM Jerry Malcolm 
wrote:

> We have a production environment where we rarely reboot Tomcat.
> LetsEncrypt auto-updates the certificates every couple of months. But
> the new certificates are not loaded into Tomcat.  So when the original
> expiration date of the certs arrives, users get "certificate expired"
> even though new certs exist.  A simple reboot to load the new certs
> fixes it.  But we want to avoid reboots.  Are there any config
> parameters that tell TC to check for cert updates and reload the new
> certs?  Thx
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Recognizing Certificate Updates

[John Larsen]

This is why we set up SSL through the web server instead of tomcat.
Apache webserver -> SSL -> Mod_jk <-> Tomcat

John Larsen



On Sat, Dec 26, 2020 at 10:43 AM Jerry Malcolm 
wrote:

> We have a production environment where we rarely reboot Tomcat.
> LetsEncrypt auto-updates the certificates every couple of months. But
> the new certificates are not loaded into Tomcat.  So when the original
> expiration date of the certs arrives, users get "certificate expired"
> even though new certs exist.  A simple reboot to load the new certs
> fixes it.  But we want to avoid reboots.  Are there any config
> parameters that tell TC to check for cert updates and reload the new
> certs?  Thx
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Recognizing Certificate Updates

[Jerry Malcolm]

We have a production environment where we rarely reboot Tomcat. 
LetsEncrypt auto-updates the certificates every couple of months. But 
the new certificates are not loaded into Tomcat.  So when the original 
expiration date of the certs arrives, users get "certificate expired" 
even though new certs exist.  A simple reboot to load the new certs 
fixes it.  But we want to avoid reboots.  Are there any config 
parameters that tell TC to check for cert updates and reload the new 
certs?  Thx



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org