Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Merlin,

On 7/14/20 09:49, Merlin Beedell wrote:
> I can confirm that changing the certificate by replacing the
> file(s) with the ones with the same name & password but with an
> updated certificate inside does indeed work.  The reason I thought
> otherwise because (I thought that) the useful Presentation by C
> Schultz said it re-read the config - allowing changes to the cipher
> list and TLS types to be altered at the same time.
Right. That could have been more clear: the in-memory configuration is
re-applied to the running SSLContext. Well, actually, we replace the
SSLContext with a new one and allow the GC to clean up the mess.

So if you want to actually reconfigure things, you ave to specifically
reconfigure them first (in memory, likely using JMX / mbeans to do
that) and then invove the reloadSsl operation.

> I had tested by swapping between 2 pfx certificates that I thought
> were different - stupid rookie mistake, the certificates were
> indeed the same.  I created a new self-signed one and that worked
> straight away.

:)

> I presume that I can the 'set' commands in the manager webapp to
> alter the allowed TLS levels?
This should work.

- -chris

> -Original Message- From: Christopher Schultz
>  Sent: 13 July 2020 11:44 PM To:
> dev@tomcat.apache.org Subject: Re: Support for LetsEncrypt certs,
> and update process, in
Tomcat without restart.
>
> Merlin,
>
> On 7/13/20 06:09, Merlin Beedell wrote:
>> Hi all,
>
>> Thank you for your valuable assistance and suggestions so far.
>
>
>
>> I did eventually try this (again, using ‘groovy’ as a
>> simple-to-use scriptable wrapper to Java), which looks like it
>> works:
>
>
>
>> @Grab(group='com.github.groovy-wslite', module='groovy-wslite',
>> version='1.1.3')
>
>
>
>> import wslite.rest.*
>
>> import wslite.http.auth.*
>
>
>
>> RESTClient client = new
>> RESTClient("http://localhost:8080/manager;) //or
>> https://localhost/manager
>
>> client.authorization = new
>> HTTPBasicAuthorization("tomcat-users-name",
>> "and-corresponding-password")
>
>
>
>> def path =
>
> "/jmxproxy/?invoke=Catalina:type=ProtocolHandler,port=443=reloadSsl
Ho
>
>
stConfigs"
>
>> def response
>
>> response = client.get(path: path)
>
>> println response.text
>
>
>
>> And it returns (for example): “*OK - Operation
>> reloadSslHostConfigs without return value*”
>
>> If the certificate file now no longer exists or is corrupted – we
>> get an error response. Thus we know this action provokes the
>> certificate file to be re-read.
>
>> /However/
>
>> If the connector section in server.xml is edited to point to a
>> new certificate path/filename, it is ignored.  The current
>> certificate config continues to be used.
>
>> If the certificate file is replaced by a new certificate, the
>> end-user does not see any change – a fresh browser will still see
>> the old certificate.
>
>
>
>> So: Is there some /other/ action that I need to invoke after the
>>  reloadSslHostConfigs?  Or to invoke it under a different “mbean
>> name”?
>
>> When I change the bean name to include *address=127.0.0.1* as per
>> your curl example
>> (Catalina:type=ProtocolHandler,port=443,address=127.0.0.1) it
>> errors.
>
>> For example – under the Catalina:type=Connector,port=443 – I see
>>  operations “destroy / pause / resume / stop / start / init”.
>
>> And under the ProtocolHandler I see “findSslHostConfigs / start /
>>  destroy / pause / resume / getProperty /
>> closeServerSocketGraceful / findupgradeProtocols / init”
>
>> Would these help?
>
>
>
>> The connector config (simple self-signed cert in this case – not
>> yet changed to a letsencrypt one) looks similar to this:
>
>> > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementat
io
>
>
n">
>
>> > className="org.apache.coyote.http2.Http2Protocol">
>
>>
>
>
> > ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
>> honorCipherOrder="true" protocols="TLSv1.3,TLSv1.2">
>
>> > certificateKeystoreFile="C:\opt\certificates\keystore"
>> certificateKeystorePassword="passphrase"
>> certificateKeystoreType="JKS">
>
>> 
>
>> 
>
>
>
>> And I am trying to reset it to a PKCS12 keystore:
>
>> > certificateKeystoreFile="C:\opt\certificates\web_cert.pfx"
>> certificateKeystorePassword="newpass"
>> certificateKeystoreType="PKCS12">
>
>
>
>> I’m at a loss to know what to do – other than to abandon SSL
>> termination in tomcat and use a proxy to do it instead – that I
>> really wish I could avoid.
>
>
>
>> Some of my findings from trying to refresh the Tomcat SSL config
>> at runtime and trying to decipher the documentation and
>> suggestions:
>
>> 1. The remote JMX feature does not need to be configured (e.g.
>> -Dcom.sun.management.jmxremote.port=9004) if you only need
>> localhost management.  But the webapp “manager” does then need to
>> be installed – as this acts as the entry point for JMX requests.
>> It’s not entirely clear in the 

Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

[Romain Manni-Bucau]

Le mar. 14 juil. 2020 à 15:50, Merlin Beedell  a
écrit :

> Thank you for the responses.
> I can confirm that changing the certificate by replacing the file(s) with
> the ones with the same name & password but with an updated certificate
> inside does indeed work.  The reason I thought otherwise because (I thought
> that) the useful Presentation by C Schultz said it re-read the config -
> allowing changes to the cipher list and TLS types to be altered at the same
> time.
> I had tested by swapping between 2 pfx certificates that I thought were
> different - stupid rookie mistake, the certificates were indeed the same.
> I created a new self-signed one and that worked straight away.
>
> I presume that I can the 'set' commands in the manager webapp to alter the
> allowed TLS levels?
>
> Final Question: If the "Bean Name" can be different depending on various
> configurations - how should I query to get the correct name if trying to
> create a 'generic' process to do this?
>


Assuming you have a single server in the JVM you can use a mbean query and
replace the name by "*" I think.


>
> Merlin Beedell
> 0800 280 0525 / +44 (0)207 045 0520
> DDI: +44 (0)207 045 0528
> Mob: +44 (0)7876 226865
> Cryoserver: A focused, flexible email archive delivered by experts
>
> -Original Message-
> From: Christopher Schultz 
> Sent: 13 July 2020 11:44 PM
> To: dev@tomcat.apache.org
> Subject: Re: Support for LetsEncrypt certs, and update process, in Tomcat
> without restart.
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Merlin,
>
> On 7/13/20 06:09, Merlin Beedell wrote:
> > Hi all,
> >
> > Thank you for your valuable assistance and suggestions so far.
> >
> >
> >
> > I did eventually try this (again, using ‘groovy’ as a simple-to-use
> > scriptable wrapper to Java), which looks like it
> > works:
> >
> >
> >
> > @Grab(group='com.github.groovy-wslite', module='groovy-wslite',
> > version='1.1.3')
> >
> >
> >
> > import wslite.rest.*
> >
> > import wslite.http.auth.*
> >
> >
> >
> > RESTClient client = new
> > RESTClient("http://localhost:8080/manager;) //or
> > https://localhost/manager
> >
> > client.authorization = new
> > HTTPBasicAuthorization("tomcat-users-name",
> > "and-corresponding-password")
> >
> >
> >
> > def path =
> >
> "/jmxproxy/?invoke=Catalina:type=ProtocolHandler,port=443=reloadSslHo
> stConfigs"
> >
> > def response
> >
> > response = client.get(path: path)
> >
> > println response.text
> >
> >
> >
> > And it returns (for example): “*OK - Operation reloadSslHostConfigs
> > without return value*”
> >
> > If the certificate file now no longer exists or is corrupted – we get
> > an error response. Thus we know this action provokes the certificate
> > file to be re-read.
> >
> > /However/
> >
> > If the connector section in server.xml is edited to point to a new
> > certificate path/filename, it is ignored.  The current certificate
> > config continues to be used.
> >
> > If the certificate file is replaced by a new certificate, the end-user
> > does not see any change – a fresh browser will still see the old
> > certificate.
> >
> >
> >
> > So: Is there some /other/ action that I need to invoke after the
> > reloadSslHostConfigs?  Or to invoke it under a different “mbean name”?
> >
> > When I change the bean name to include *address=127.0.0.1* as per your
> > curl example
> > (Catalina:type=ProtocolHandler,port=443,address=127.0.0.1) it errors.
> >
> > For example – under the Catalina:type=Connector,port=443 – I see
> > operations “destroy / pause / resume / stop / start / init”.
> >
> > And under the ProtocolHandler I see “findSslHostConfigs / start /
> > destroy / pause / resume / getProperty / closeServerSocketGraceful /
> > findupgradeProtocols / init”
> >
> > Would these help?
> >
> >
> >
> > The connector config (simple self-signed cert in this case – not yet
> > changed to a letsencrypt one) looks similar to this:
> >
> >  > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> >
> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementatio
> n">
> >
> >  > className="org.apache.coyote.http2.Http2Protocol">
> >
> >
> >
>  > ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
> > honorCipherOrder="true" protocols="TLSv1.3,TLSv1.2">
> >
> >  > certificateKeystoreFile="C:\opt\certificates\keystore"
> > certificateKeystorePassword="passphrase"
> > certificateKeystoreType="JKS">
> >
> > 
> >
> > 
> >
> >
> >
> > And I am trying to reset it to a PKCS12 keystore:
> >
> >  > certificateKeystoreFile="C:\opt\certificates\web_cert.pfx"
> > certificateKeystorePassword="newpass"
> > certificateKeystoreType="PKCS12">
> >
> >
> >
> > I’m at a loss to know what to do – other than to abandon SSL
> > termination in tomcat and use a proxy to do it instead – that I really
> > wish I could avoid.
> >
> >
> >
> > Some of my findings from trying to refresh the Tomcat SSL config at
> > runtime and trying to decipher the documentation and
> > suggestions:
> >
> > 1. The remote JMX 

RE: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

[Merlin Beedell]

Thank you for the responses.
I can confirm that changing the certificate by replacing the file(s) with the 
ones with the same name & password but with an updated certificate inside does 
indeed work.  The reason I thought otherwise because (I thought that) the 
useful Presentation by C Schultz said it re-read the config - allowing changes 
to the cipher list and TLS types to be altered at the same time.
I had tested by swapping between 2 pfx certificates that I thought were 
different - stupid rookie mistake, the certificates were indeed the same.  I 
created a new self-signed one and that worked straight away.

I presume that I can the 'set' commands in the manager webapp to alter the 
allowed TLS levels?

Final Question: If the "Bean Name" can be different depending on various 
configurations - how should I query to get the correct name if trying to create 
a 'generic' process to do this?

Merlin Beedell 
0800 280 0525 / +44 (0)207 045 0520
DDI: +44 (0)207 045 0528
Mob: +44 (0)7876 226865
Cryoserver: A focused, flexible email archive delivered by experts

-Original Message-
From: Christopher Schultz  
Sent: 13 July 2020 11:44 PM
To: dev@tomcat.apache.org
Subject: Re: Support for LetsEncrypt certs, and update process, in Tomcat 
without restart.

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Merlin,

On 7/13/20 06:09, Merlin Beedell wrote:
> Hi all,
>
> Thank you for your valuable assistance and suggestions so far.
>
>
>
> I did eventually try this (again, using ‘groovy’ as a simple-to-use 
> scriptable wrapper to Java), which looks like it
> works:
>
>
>
> @Grab(group='com.github.groovy-wslite', module='groovy-wslite',
> version='1.1.3')
>
>
>
> import wslite.rest.*
>
> import wslite.http.auth.*
>
>
>
> RESTClient client = new
> RESTClient("http://localhost:8080/manager;) //or 
> https://localhost/manager
>
> client.authorization = new
> HTTPBasicAuthorization("tomcat-users-name",
> "and-corresponding-password")
>
>
>
> def path =
>
"/jmxproxy/?invoke=Catalina:type=ProtocolHandler,port=443=reloadSslHo
stConfigs"
>
> def response
>
> response = client.get(path: path)
>
> println response.text
>
>
>
> And it returns (for example): “*OK - Operation reloadSslHostConfigs 
> without return value*”
>
> If the certificate file now no longer exists or is corrupted – we get 
> an error response. Thus we know this action provokes the certificate 
> file to be re-read.
>
> /However/
>
> If the connector section in server.xml is edited to point to a new 
> certificate path/filename, it is ignored.  The current certificate 
> config continues to be used.
>
> If the certificate file is replaced by a new certificate, the end-user 
> does not see any change – a fresh browser will still see the old 
> certificate.
>
>
>
> So: Is there some /other/ action that I need to invoke after the 
> reloadSslHostConfigs?  Or to invoke it under a different “mbean name”?
>
> When I change the bean name to include *address=127.0.0.1* as per your 
> curl example
> (Catalina:type=ProtocolHandler,port=443,address=127.0.0.1) it errors.
>
> For example – under the Catalina:type=Connector,port=443 – I see 
> operations “destroy / pause / resume / stop / start / init”.
>
> And under the ProtocolHandler I see “findSslHostConfigs / start / 
> destroy / pause / resume / getProperty / closeServerSocketGraceful / 
> findupgradeProtocols / init”
>
> Would these help?
>
>
>
> The connector config (simple self-signed cert in this case – not yet 
> changed to a letsencrypt one) looks similar to this:
>
>  protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementatio
n">
>
>  className="org.apache.coyote.http2.Http2Protocol">
>
>
>
 ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
> honorCipherOrder="true" protocols="TLSv1.3,TLSv1.2">
>
>  certificateKeystoreFile="C:\opt\certificates\keystore"
> certificateKeystorePassword="passphrase"
> certificateKeystoreType="JKS">
>
> 
>
> 
>
>
>
> And I am trying to reset it to a PKCS12 keystore:
>
>  certificateKeystoreFile="C:\opt\certificates\web_cert.pfx"
> certificateKeystorePassword="newpass"
> certificateKeystoreType="PKCS12">
>
>
>
> I’m at a loss to know what to do – other than to abandon SSL 
> termination in tomcat and use a proxy to do it instead – that I really 
> wish I could avoid.
>
>
>
> Some of my findings from trying to refresh the Tomcat SSL config at 
> runtime and trying to decipher the documentation and
> suggestions:
>
> 1. The remote JMX feature does not need to be configured (e.g.
> -Dcom.sun.management.jmxremote.port=9004) if you only need localhost 
> management.  But the webapp “manager” does then need to be installed – 
> as this acts as the entry point for JMX requests.
> It’s not entirely clear in the documentation about this, nor the 
> differences in the format or content of the returned information.
> 2. Not being too familiar with /curl/, I could not determine how to 
> pass the manager 

Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Merlin,

On 7/13/20 06:09, Merlin Beedell wrote:
> Hi all,
>
> Thank you for your valuable assistance and suggestions so far.
>
>
>
> I did eventually try this (again, using ‘groovy’ as a
> simple-to-use scriptable wrapper to Java), which looks like it
> works:
>
>
>
> @Grab(group='com.github.groovy-wslite', module='groovy-wslite',
> version='1.1.3')
>
>
>
> import wslite.rest.*
>
> import wslite.http.auth.*
>
>
>
> RESTClient client = new
> RESTClient("http://localhost:8080/manager;) //or
> https://localhost/manager
>
> client.authorization = new
> HTTPBasicAuthorization("tomcat-users-name",
> "and-corresponding-password")
>
>
>
> def path =
>
"/jmxproxy/?invoke=Catalina:type=ProtocolHandler,port=443=reloadSslHo
stConfigs"
>
> def response
>
> response = client.get(path: path)
>
> println response.text
>
>
>
> And it returns (for example): “*OK - Operation
> reloadSslHostConfigs without return value*”
>
> If the certificate file now no longer exists or is corrupted – we
> get an error response. Thus we know this action provokes the
> certificate file to be re-read.
>
> /However/
>
> If the connector section in server.xml is edited to point to a new
> certificate path/filename, it is ignored.  The current certificate
> config continues to be used.
>
> If the certificate file is replaced by a new certificate, the
> end-user does not see any change – a fresh browser will still see
> the old certificate.
>
>
>
> So: Is there some /other/ action that I need to invoke after the
> reloadSslHostConfigs?  Or to invoke it under a different “mbean
> name”?
>
> When I change the bean name to include *address=127.0.0.1* as per
> your curl example
> (Catalina:type=ProtocolHandler,port=443,address=127.0.0.1) it
> errors.
>
> For example – under the Catalina:type=Connector,port=443 – I see
> operations “destroy / pause / resume / stop / start / init”.
>
> And under the ProtocolHandler I see “findSslHostConfigs / start /
> destroy / pause / resume / getProperty / closeServerSocketGraceful
> / findupgradeProtocols / init”
>
> Would these help?
>
>
>
> The connector config (simple self-signed cert in this case – not
> yet changed to a letsencrypt one) looks similar to this:
>
>  protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementatio
n">
>
>  className="org.apache.coyote.http2.Http2Protocol">
>
>
>
 ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
> honorCipherOrder="true" protocols="TLSv1.3,TLSv1.2">
>
>  certificateKeystoreFile="C:\opt\certificates\keystore"
> certificateKeystorePassword="passphrase"
> certificateKeystoreType="JKS">
>
> 
>
> 
>
>
>
> And I am trying to reset it to a PKCS12 keystore:
>
>  certificateKeystoreFile="C:\opt\certificates\web_cert.pfx"
> certificateKeystorePassword="newpass"
> certificateKeystoreType="PKCS12">
>
>
>
> I’m at a loss to know what to do – other than to abandon SSL
> termination in tomcat and use a proxy to do it instead – that I
> really wish I could avoid.
>
>
>
> Some of my findings from trying to refresh the Tomcat SSL config
> at runtime and trying to decipher the documentation and
> suggestions:
>
> 1. The remote JMX feature does not need to be configured (e.g.
> -Dcom.sun.management.jmxremote.port=9004) if you only need
> localhost management.  But the webapp “manager” does then need to
> be installed – as this acts as the entry point for JMX requests.
> It’s not entirely clear in the documentation about this, nor the
> differences in the format or content of the returned information.
> 2. Not being too familiar with /curl/, I could not determine how
> to pass the manager username / password. 3. Nor is it very obvious
> how interpret the jmx query response in order to form effective
> gets and sets (e.g. the ‘bean name’ to use in a get or set). Nor
> how to obtain operations and parameters.  I see all that stuff if I
> enable remote JMX and use the *JConsole*. But can the manager app
> responses provide the same metadata to determine useful stuff?  I
> also see these messages in a popup window when using JConsole to
> access the operations list: Error setting Operation panel
> :org.apache.tomcat.util.net.SSLHostConfigCertificate
>
> Error setting Operation panel
> :org.apache.tomcat.util.net.SSLHostConfig
>
> Error setting Operation panel :org.apache.coyote.Request
>
> 4. I have used the Tomcat “ant” wrapper for manager. I call the
> ant tasks using ‘groovy’ (just to simplify the preparation of the
> /manager/ web requests and responses). I can use the Query/Get/Set
> calls, but I don’t seem to be able to construct an Invoke
> operation call.  After a lot of trial and error, I gave up using
> this! 5. Re: Tomcat Wiki / Documentation and other cert providers…
> It seems that letsencrypt is currently the only provider with an
> automated update service.  Would be great if they all could – then
> this really could be fully automated (i.e. a tomcat 

Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

[Mark Thomas]

On 13/07/2020 11:09, Merlin Beedell wrote:



> If the connector section in server.xml is edited to point to a new
> certificate path/filename, it is ignored.  The current certificate
> config continues to be used.

As expected. server.xml is only read on Tomcat start. Changes made after
that point will not take effect until the next Tomcat restart.

> If the certificate file is replaced by a new certificate, the end-user
> does not see any change – a fresh browser will still see the old
> certificate.

That isn't the behaviour I would expect.

> So: Is there some /other/ action that I need to invoke after the
> reloadSslHostConfigs?

No.

>  Or to invoke it under a different “mbean name”?

No.

> When I change the bean name to include *address=127.0.0.1* as per your
> curl example (Catalina:type=ProtocolHandler,port=443,address=127.0.0.1)
> it errors.

Exact bean names will depend on server configuration.

> The connector config (simple self-signed cert in this case – not yet
> changed to a letsencrypt one) looks similar to this:
> 
>      protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation">
> 
>      className="org.apache.coyote.http2.Http2Protocol">
> 
>      ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
> honorCipherOrder="true" protocols="TLSv1.3,TLSv1.2">
> 
>      certificateKeystoreFile="C:\opt\certificates\keystore"
> certificateKeystorePassword="passphrase"
> certificateKeystoreType="JKS">
> 
>     
> 
>     
> 
>  
> 
> And I am trying to reset it to a PKCS12 keystore:
> 
>      certificateKeystoreFile="C:\opt\certificates\web_cert.pfx"
> certificateKeystorePassword="newpass"
> certificateKeystoreType="PKCS12">

To do that while Tomcat is running you'd need to change the Certificate
attributes to the new values (via JMX) and then call reloadSslHostConfigs.

Mark

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

RE: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

[Merlin Beedell]

Hi all,
Thank you for your valuable assistance and suggestions so far.


I did eventually try this (again, using ‘groovy’ as a simple-to-use scriptable 
wrapper to Java), which looks like it works:

@Grab(group='com.github.groovy-wslite', module='groovy-wslite', version='1.1.3')

import wslite.rest.*
import wslite.http.auth.*

RESTClient client = new RESTClient("http://localhost:8080/manager;)  //or 
https://localhost/manager
client.authorization = new HTTPBasicAuthorization("tomcat-users-name", 
"and-corresponding-password")

def path = 
"/jmxproxy/?invoke=Catalina:type=ProtocolHandler,port=443=reloadSslHostConfigs"
def response
response = client.get(path: path)
println response.text

And it returns (for example): “OK - Operation reloadSslHostConfigs without 
return value”
If the certificate file now no longer exists or is corrupted – we get an error 
response. Thus we know this action provokes the certificate file to be re-read.
However
If the connector section in server.xml is edited to point to a new certificate 
path/filename, it is ignored.  The current certificate config continues to be 
used.
If the certificate file is replaced by a new certificate, the end-user does not 
see any change – a fresh browser will still see the old certificate.

So: Is there some other action that I need to invoke after the 
reloadSslHostConfigs?  Or to invoke it under a different “mbean name”?
When I change the bean name to include address=127.0.0.1 as per your curl 
example (Catalina:type=ProtocolHandler,port=443,address=127.0.0.1) it errors.
For example – under the Catalina:type=Connector,port=443 – I see operations 
“destroy / pause / resume / stop / start / init”.
And under the ProtocolHandler I see “findSslHostConfigs / start / destroy / 
pause / resume / getProperty / closeServerSocketGraceful / findupgradeProtocols 
/ init”
   Would these help?

The connector config (simple self-signed cert in this case – not yet changed to 
a letsencrypt one) looks similar to this:







And I am trying to reset it to a PKCS12 keystore:


I’m at a loss to know what to do – other than to abandon SSL termination in 
tomcat and use a proxy to do it instead – that I really wish I could avoid.

Some of my findings from trying to refresh the Tomcat SSL config at runtime and 
trying to decipher the documentation and suggestions:

  1.  The remote JMX feature does not need to be configured (e.g. 
-Dcom.sun.management.jmxremote.port=9004) if you only need localhost 
management.  But the webapp “manager” does then need to be installed – as this 
acts as the entry point for JMX requests.  It’s not entirely clear in the 
documentation about this, nor the differences in the format or content of the 
returned information.
  2.  Not being too familiar with curl, I could not determine how to pass the 
manager username / password.
  3.  Nor is it very obvious how interpret the jmx query response in order to 
form effective gets and sets (e.g. the ‘bean name’ to use in a get or set). Nor 
how to obtain operations and parameters.  I see all that stuff if I enable 
remote JMX and use the JConsole. But can the manager app responses provide the 
same metadata to determine useful stuff?  I also see these messages in a popup 
window when using JConsole to access the operations list:
Error setting Operation panel 
:org.apache.tomcat.util.net.SSLHostConfigCertificate

Error setting Operation panel :org.apache.tomcat.util.net.SSLHostConfig

Error setting Operation panel :org.apache.coyote.Request

  1.  I have used the Tomcat “ant” wrapper for manager. I call the ant tasks 
using ‘groovy’ (just to simplify the preparation of the manager web requests 
and responses). I can use the Query/Get/Set calls, but I don’t seem to be able 
to construct an Invoke operation call.  After a lot of trial and error, I gave 
up using this!
  2.  Re: Tomcat Wiki / Documentation and other cert providers… It seems that 
letsencrypt is currently the only provider with an automated update service.  
Would be great if they all could – then this really could be fully automated 
(i.e. a tomcat module to provide a fetch-cert-from-provider facility that works 
for all). But until then, a simple, reliable, well documented ‘refresh SSL 
cert’ feature in Tomcat would really help.


Merlin Beedell
From: Romain Manni-Bucau 
Sent: 11 June 2020 7:17 PM
To: Tomcat Developers List 
Subject: Re: Support for LetsEncrypt certs, and update process, in Tomcat 
without restart.

This one was more intended to System.exit but it got aligned with mw impl so it 
is quite close.

Le jeu. 11 juin 2020 à 19:40, Christopher Schultz 
mailto:ch...@christopherschultz.net>> a écrit :
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Romain,

On 6/11/20 13:34, Romain Manni-Bucau wrote:
> @Chris:
https://github.com/rmannibucau/letsencrypt-manager/blob/master/src/main/
java/com/github/rmannibucau/letsencrypt/manager/LetsEncryptManager.java
?

Thanks!

Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

[Romain Manni-Bucau]

This one was more intended to System.exit but it got aligned with mw impl
so it is quite close.

Le jeu. 11 juin 2020 à 19:40, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Romain,
>
> On 6/11/20 13:34, Romain Manni-Bucau wrote:
> > @Chris:
> https://github.com/rmannibucau/letsencrypt-manager/blob/master/src/main/
> java/com/github/rmannibucau/letsencrypt/manager/LetsEncryptManager.java
> 
> ?
>
> Thanks!
>
> Stupid GitHub. I searched all your repositories for "encrypt" and it
> didn't find "letsencrypt". I guess "search" means "prefix match".
> *facepalm*
>
> > it is more or less what we have in meecrowave except meecrowave
> > can hotreload whereas this (pre reloadSslHostConfig method) impl
> > does not.
>
> Your LetsEncryptManager seems to call reloadSslHostConfigs. What does
> Meecrowave do differently?
>
> - -chris
>
> > Le jeu. 11 juin 2020 à 19:20, Christopher Schultz
> >  > > a écrit :
> >
> > Merlin,
> >
> > On 6/10/20 12:32, Merlin Beedell wrote:
> >> Well thanks Christopher - that presentation link was just what I
> >> needed (well - it was your presentation after all!). Really
> >> good. Ideally this could be written into the Tomcat standard
> >> Documentation, as it will crop up quite a bit.
> >
> >> In summary, 3 steps:
> >
> >> 1. Fetch cert update (requires port 80).
> >
> >> – certbot-auto renew
> >
> >> 2. Reformat for Tomcat usage [might be natively handled in later
> >> Tomcat releases?]
> >
> >> – openssl pkcs12 -export -in [cert] -inkey [key] -certfile
> >> [chain] -out [p12file]
> >
> >> 3. Use JMX to flush/reload the SSH Host config (including cipher
> >> list & protocol level) at runtime.
> >
> >> https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandl
> e
> >
> >>
> r,port=8443,address=
> >  er,port=8443,address=
> 
> >"127.0.0.1"=reloadSslHostConfigs
> >
> >  While
> >
> > "[documentation] patches are always welcome", I don't think I'd
> > want to put this into the Tomcat user's manual. If we add
> > information about Let's Encrypt, why not DigiCert? VeriSign?
> > GoDaddy? WhoeeverElseCA ?
> >
> > I could see this being something useful in the Tomcat Wiki.
> >
> > At least one person who has seen my presentation has said "we, I
> > was hoping there was just a letsencrypt='true' configuration flag".
> > I like the outside-in approach certbot takes with their Apache
> > plugins, rather than an inside-out approach where the server
> > actually has a plug-in for let's encrypt (or similar).
> >
> > Romain @ TomEE has written a WAR file that implements this
> > inside-out approach as a generic ACME servlet (context listener?),
> > but I can't seem to find his code anywhere...
> >
> > -chris
> >
> >> -Original Message-
> >
> >> From: Christopher Schultz  > >
> >
> >> Sent: 08 June 2020 9:14 PM
> >
> >> To: Tomcat Developers List  > >; Merlin Beedell
> >> mailto:mbeed...@cryoserver.com>>
> >
> >> Subject: Re: Support for LetsEncrypt certs, and update process,
> >> in Tomcat without restart.
> >
> >
> >
> >> Hash: SHA256
> >
> >
> >
> >> Merlin,
> >
> >
> >
> >> On 6/8/20 10:17, Merlin Beedell wrote:
> >
> >>> I am getting a lot of flack from some senior devs who insist
> >>> that
> >
> >>> Tomcat must be put behind a Proxy – HA Proxy or Nginx, which
> >>> will
> >
> >>> handle the SSL offloading etc.
> >
> >
> >
> >>> While this seems sensible for multi-server environments, they
> >>> want it
> >
> >>> for single server too.  But Tomcat can do all the things that
> >>> are
> >
> >>> required:
> >
> >
> >
> >>> * Certificate handling. * TLS level and Cipher restrictions *
> >>> CORS
> >
> >>> handling (though this could be simpler!)
> >
> >
> >
> >>> But now with the requirement for LetsEncrypt certificates, we
> >>> find
> >
> >>> that Tomcat has to be restarted every 3 months.  Indeed – any
> >>> changes
> >
> >>> to the above require tomcat restarts – and that is found to be
> >
> >>> unacceptable.
> >
> >
> >
> >> Nonsense.
> >
> >
> >
> >> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> >
> >
> >
> >> Updating CORS configuration may require a redeployment of your
> >> web application, but it does not require Tomcat to be shut-down.
> >
> >
> >
> >> There are other reasons to use a reverse proxy in front of
> >> Tomcat, but none of the above are good reasons.
> >
> >
> >
> >>> So what I really want to understand is if Tomcat has any plans
> >>> to
> >
> >>> include the ability to restart an https connector WITHOUT
> >>> needing to
> >
> >>> restart the whole of 

Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Romain,

On 6/11/20 13:34, Romain Manni-Bucau wrote:
> @Chris:
https://github.com/rmannibucau/letsencrypt-manager/blob/master/src/main/
java/com/github/rmannibucau/letsencrypt/manager/LetsEncryptManager.java
?

Thanks!

Stupid GitHub. I searched all your repositories for "encrypt" and it
didn't find "letsencrypt". I guess "search" means "prefix match".
*facepalm*

> it is more or less what we have in meecrowave except meecrowave
> can hotreload whereas this (pre reloadSslHostConfig method) impl
> does not.

Your LetsEncryptManager seems to call reloadSslHostConfigs. What does
Meecrowave do differently?

- -chris

> Le jeu. 11 juin 2020 à 19:20, Christopher Schultz
>  > a écrit :
>
> Merlin,
>
> On 6/10/20 12:32, Merlin Beedell wrote:
>> Well thanks Christopher - that presentation link was just what I
>> needed (well - it was your presentation after all!). Really
>> good. Ideally this could be written into the Tomcat standard
>> Documentation, as it will crop up quite a bit.
>
>> In summary, 3 steps:
>
>> 1. Fetch cert update (requires port 80).
>
>> – certbot-auto renew
>
>> 2. Reformat for Tomcat usage [might be natively handled in later
>> Tomcat releases?]
>
>> – openssl pkcs12 -export -in [cert] -inkey [key] -certfile
>> [chain] -out [p12file]
>
>> 3. Use JMX to flush/reload the SSH Host config (including cipher
>> list & protocol level) at runtime.
>
>> https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandl
e
>
>>
r,port=8443,address=
> "127.0.0.1"=reloadSslHostConfigs
>
>  While
>
> "[documentation] patches are always welcome", I don't think I'd
> want to put this into the Tomcat user's manual. If we add
> information about Let's Encrypt, why not DigiCert? VeriSign?
> GoDaddy? WhoeeverElseCA ?
>
> I could see this being something useful in the Tomcat Wiki.
>
> At least one person who has seen my presentation has said "we, I
> was hoping there was just a letsencrypt='true' configuration flag".
> I like the outside-in approach certbot takes with their Apache
> plugins, rather than an inside-out approach where the server
> actually has a plug-in for let's encrypt (or similar).
>
> Romain @ TomEE has written a WAR file that implements this
> inside-out approach as a generic ACME servlet (context listener?),
> but I can't seem to find his code anywhere...
>
> -chris
>
>> -Original Message-
>
>> From: Christopher Schultz  >
>
>> Sent: 08 June 2020 9:14 PM
>
>> To: Tomcat Developers List  >; Merlin Beedell
>> mailto:mbeed...@cryoserver.com>>
>
>> Subject: Re: Support for LetsEncrypt certs, and update process,
>> in Tomcat without restart.
>
>
>
>> Hash: SHA256
>
>
>
>> Merlin,
>
>
>
>> On 6/8/20 10:17, Merlin Beedell wrote:
>
>>> I am getting a lot of flack from some senior devs who insist
>>> that
>
>>> Tomcat must be put behind a Proxy – HA Proxy or Nginx, which
>>> will
>
>>> handle the SSL offloading etc.
>
>
>
>>> While this seems sensible for multi-server environments, they
>>> want it
>
>>> for single server too.  But Tomcat can do all the things that
>>> are
>
>>> required:
>
>
>
>>> * Certificate handling. * TLS level and Cipher restrictions *
>>> CORS
>
>>> handling (though this could be simpler!)
>
>
>
>>> But now with the requirement for LetsEncrypt certificates, we
>>> find
>
>>> that Tomcat has to be restarted every 3 months.  Indeed – any
>>> changes
>
>>> to the above require tomcat restarts – and that is found to be
>
>>> unacceptable.
>
>
>
>> Nonsense.
>
>
>
>> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
>
>
>
>> Updating CORS configuration may require a redeployment of your
>> web application, but it does not require Tomcat to be shut-down.
>
>
>
>> There are other reasons to use a reverse proxy in front of
>> Tomcat, but none of the above are good reasons.
>
>
>
>>> So what I really want to understand is if Tomcat has any plans
>>> to
>
>>> include the ability to restart an https connector WITHOUT
>>> needing to
>
>>> restart the whole of Tomcat.  Better still, a hook that would
>>> help
>
>>> refresh certificates – like LetsEncrypt.
>
>
>
>
>> https://stackoverflow.com/questions/43571572/programmatically-update-
c
>
>>
ertificates-in-tomcat-8-without-server-restart
> 
>
>
>
>
>
>
>
>> There
>
>
>
>> are no currently-correct answers to that question.
>
>
>
>> I can fix that.
>
>
>
>> -chris
>
>
>
>
- -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>  For additional commands,
> e-mail: dev-h...@tomcat.apache.org
> 
>
-BEGIN 

Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

[Romain Manni-Bucau]

@Chris:
https://github.com/rmannibucau/letsencrypt-manager/blob/master/src/main/java/com/github/rmannibucau/letsencrypt/manager/LetsEncryptManager.java
?
it is more or less what we have in meecrowave except meecrowave can
hotreload whereas this (pre reloadSslHostConfig method) impl does not.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 11 juin 2020 à 19:20, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Merlin,
>
> On 6/10/20 12:32, Merlin Beedell wrote:
> > Well thanks Christopher - that presentation link was just what I
> > needed (well - it was your presentation after all!). Really good.
> > Ideally this could be written into the Tomcat standard
> > Documentation, as it will crop up quite a bit.
> >
> > In summary, 3 steps:
> >
> > 1. Fetch cert update (requires port 80).
> >
> > – certbot-auto renew
> >
> > 2. Reformat for Tomcat usage [might be natively handled in later
> > Tomcat releases?]
> >
> > – openssl pkcs12 -export -in [cert] -inkey [key] -certfile [chain]
> >  -out [p12file]
> >
> > 3. Use JMX to flush/reload the SSH Host config (including cipher
> > list & protocol level) at runtime.
> >
> > https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandle
> r,port=8443,address=
> 
> "127.0.0.1"=reloadSslHostConfigs
>
> While
> >
> "[documentation] patches are always welcome", I don't think I'd
> want to put this into the Tomcat user's manual. If we add information
> about Let's Encrypt, why not DigiCert? VeriSign? GoDaddy? WhoeeverElseCA
> ?
>
> I could see this being something useful in the Tomcat Wiki.
>
> At least one person who has seen my presentation has said "we, I was
> hoping there was just a letsencrypt='true' configuration flag". I like
> the outside-in approach certbot takes with their Apache plugins,
> rather than an inside-out approach where the server actually has a
> plug-in for let's encrypt (or similar).
>
> Romain @ TomEE has written a WAR file that implements this inside-out
> approach as a generic ACME servlet (context listener?), but I can't
> seem to find his code anywhere...
>
> - -chris
>
> > -Original Message-
> >
> > From: Christopher Schultz 
> >
> > Sent: 08 June 2020 9:14 PM
> >
> > To: Tomcat Developers List ; Merlin Beedell
> >  
> >
> > Subject: Re: Support for LetsEncrypt certs, and update process, in
> >  Tomcat without restart.
> >
> >
> >
> > Hash: SHA256
> >
> >
> >
> > Merlin,
> >
> >
> >
> > On 6/8/20 10:17, Merlin Beedell wrote:
> >
> >> I am getting a lot of flack from some senior devs who insist
> >> that
> >
> >> Tomcat must be put behind a Proxy – HA Proxy or Nginx, which
> >> will
> >
> >> handle the SSL offloading etc.
> >
> >
> >
> >> While this seems sensible for multi-server environments, they
> >> want it
> >
> >> for single server too.  But Tomcat can do all the things that
> >> are
> >
> >> required:
> >
> >
> >
> >> * Certificate handling. * TLS level and Cipher restrictions *
> >> CORS
> >
> >> handling (though this could be simpler!)
> >
> >
> >
> >> But now with the requirement for LetsEncrypt certificates, we
> >> find
> >
> >> that Tomcat has to be restarted every 3 months.  Indeed – any
> >> changes
> >
> >> to the above require tomcat restarts – and that is found to be
> >
> >> unacceptable.
> >
> >
> >
> > Nonsense.
> >
> >
> >
> > http://tomcat.apache.org/presentations.html#latest-lets-encrypt
> >
> >
> >
> > Updating CORS configuration may require a redeployment of your web
> >  application, but it does not require Tomcat to be shut-down.
> >
> >
> >
> > There are other reasons to use a reverse proxy in front of Tomcat,
> >  but none of the above are good reasons.
> >
> >
> >
> >> So what I really want to understand is if Tomcat has any plans
> >> to
> >
> >> include the ability to restart an https connector WITHOUT needing
> >>  to
> >
> >> restart the whole of Tomcat.  Better still, a hook that would
> >> help
> >
> >> refresh certificates – like LetsEncrypt.
> >
> >
> >
> >
> > https://stackoverflow.com/questions/43571572/programmatically-update-c
> ertificates-in-tomcat-8-without-server-restart
> 
> >
> >
> >
> >
> >
> >
> > There
> >
> >
> >
> > are no currently-correct answers to that question.
> >
> >
> >
> > I can fix that.
> >
> >
> >
> > -chris
> >
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7iZ88ACgkQHPApP6U8
> 

Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Merlin,

On 6/10/20 12:32, Merlin Beedell wrote:
> Well thanks Christopher - that presentation link was just what I
> needed (well - it was your presentation after all!). Really good.
> Ideally this could be written into the Tomcat standard
> Documentation, as it will crop up quite a bit.
>
> In summary, 3 steps:
>
> 1. Fetch cert update (requires port 80).
>
> – certbot-auto renew
>
> 2. Reformat for Tomcat usage [might be natively handled in later
> Tomcat releases?]
>
> – openssl pkcs12 -export -in [cert] -inkey [key] -certfile [chain]
>  -out [p12file]
>
> 3. Use JMX to flush/reload the SSH Host config (including cipher
> list & protocol level) at runtime.
>
> https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandle
r,port=8443,address="127.0.0.1"=reloadSslHostConfigs

While
>
"[documentation] patches are always welcome", I don't think I'd
want to put this into the Tomcat user's manual. If we add information
about Let's Encrypt, why not DigiCert? VeriSign? GoDaddy? WhoeeverElseCA
?

I could see this being something useful in the Tomcat Wiki.

At least one person who has seen my presentation has said "we, I was
hoping there was just a letsencrypt='true' configuration flag". I like
the outside-in approach certbot takes with their Apache plugins,
rather than an inside-out approach where the server actually has a
plug-in for let's encrypt (or similar).

Romain @ TomEE has written a WAR file that implements this inside-out
approach as a generic ACME servlet (context listener?), but I can't
seem to find his code anywhere...

- -chris

> -Original Message-
>
> From: Christopher Schultz 
>
> Sent: 08 June 2020 9:14 PM
>
> To: Tomcat Developers List ; Merlin Beedell
>  
>
> Subject: Re: Support for LetsEncrypt certs, and update process, in
>  Tomcat without restart.
>
>
>
> Hash: SHA256
>
>
>
> Merlin,
>
>
>
> On 6/8/20 10:17, Merlin Beedell wrote:
>
>> I am getting a lot of flack from some senior devs who insist
>> that
>
>> Tomcat must be put behind a Proxy – HA Proxy or Nginx, which
>> will
>
>> handle the SSL offloading etc.
>
>
>
>> While this seems sensible for multi-server environments, they
>> want it
>
>> for single server too.  But Tomcat can do all the things that
>> are
>
>> required:
>
>
>
>> * Certificate handling. * TLS level and Cipher restrictions *
>> CORS
>
>> handling (though this could be simpler!)
>
>
>
>> But now with the requirement for LetsEncrypt certificates, we
>> find
>
>> that Tomcat has to be restarted every 3 months.  Indeed – any
>> changes
>
>> to the above require tomcat restarts – and that is found to be
>
>> unacceptable.
>
>
>
> Nonsense.
>
>
>
> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
>
>
>
> Updating CORS configuration may require a redeployment of your web
>  application, but it does not require Tomcat to be shut-down.
>
>
>
> There are other reasons to use a reverse proxy in front of Tomcat,
>  but none of the above are good reasons.
>
>
>
>> So what I really want to understand is if Tomcat has any plans
>> to
>
>> include the ability to restart an https connector WITHOUT needing
>>  to
>
>> restart the whole of Tomcat.  Better still, a hook that would
>> help
>
>> refresh certificates – like LetsEncrypt.
>
>
>
>
> https://stackoverflow.com/questions/43571572/programmatically-update-c
ertificates-in-tomcat-8-without-server-restart
>
>
>
>
>
>
> There
>
>
>
> are no currently-correct answers to that question.
>
>
>
> I can fix that.
>
>
>
> -chris
>
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7iZ88ACgkQHPApP6U8
pFiMOQ//XsUcdESt//fApST4TGad+KpkTX964+jhgqaC0uprpTpd/GRpo81yxupI
oRbQ/UVwZHOWglClZCQoL8fbFYSCcizAIWhJqmMiTMshx6sYXIINC478zcO/B7VY
V8i+DpT0mdi3jYwc59lZD4e/P/v9jJJjGAuS6YrlrHjdAt5IcEJ5+2JG3HaGnhzp
ALYbq0OaQfM0jTnDymIHuXmuoAZbhon0+4tYAO/hHIbMJE+xvgeud3qRJXNhjpIv
YjWfQ06zNAuuOMvUtYjN8ONAUAl8FR5rOcC0lT6nMK1EpIglmtqcu3CIuXxtEu3M
zEkOSWDVqziN00lmcaoZ2GqYYOPS0+GH+OfcM489X731bZDJR9VUlepFBaYM21X6
BAsdmT2U6yvpEw/wOyuRMbo50toMLc1eULeAPgsCudNaWWA2T7AUaxpYbzw8jt4t
oIZhIGsEEHySWzxO7e17Puq/Z9zWC0T9+vFIfL19n1EDC+8UuhPOBnZ7Vvgu1GHn
wdHG26+Rc9NPUnkY5L2AG33itBD/lvo53HRryFHxzgbw1n0KdxethczsBarzdKGl
7W0GUkYZi4aSxcdcOHcs0Brcnv7RwWEU2FcI96BHoVn80TW8qUuE83Dfr6py2gzR
EP2dqd7JiGpTrDZZdIBkcoQ5B4/z/39KuyZkeYPNPp85gcPdayI=
=5mUH
-END PGP SIGNATURE-

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

RE: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

[Merlin Beedell]

Well thanks Christopher - that presentation link was just what I needed (well - 
it was your presentation after all!). Really good.  Ideally this could be 
written into the Tomcat standard Documentation, as it will crop up quite a bit.

In summary, 3 steps:

  1.  Fetch cert update (requires port 80).

- certbot-auto renew

  1.  Reformat for Tomcat usage [might be natively handled in later Tomcat 
releases?]

- openssl pkcs12 -export -in [cert] -inkey [key] -certfile [chain] -out 
[p12file]

  1.  Use JMX to flush/reload the SSH Host config (including cipher list & 
protocol level) at runtime.

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



Merlin Beedell

-Original Message-

From: Christopher Schultz 

Sent: 08 June 2020 9:14 PM

To: Tomcat Developers List ; Merlin Beedell 


Subject: Re: Support for LetsEncrypt certs, and update process, in Tomcat 
without restart.



-BEGIN PGP SIGNED MESSAGE-

Hash: SHA256



Merlin,



On 6/8/20 10:17, Merlin Beedell wrote:

> I am getting a lot of flack from some senior devs who insist that

> Tomcat must be put behind a Proxy - HA Proxy or Nginx, which will

> handle the SSL offloading etc.

>

> While this seems sensible for multi-server environments, they want it

> for single server too.  But Tomcat can do all the things that are

> required:

>

> * Certificate handling. * TLS level and Cipher restrictions * CORS

> handling (though this could be simpler!)

>

> But now with the requirement for LetsEncrypt certificates, we find

> that Tomcat has to be restarted every 3 months.  Indeed - any changes

> to the above require tomcat restarts - and that is found to be

> unacceptable.



Nonsense.



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



Updating CORS configuration may require a redeployment of your web application, 
but it does not require Tomcat to be shut-down.



There are other reasons to use a reverse proxy in front of Tomcat, but none of 
the above are good reasons.



> So what I really want to understand is if Tomcat has any plans to

> include the ability to restart an https connector WITHOUT needing to

> restart the whole of Tomcat.  Better still, a hook that would help

> refresh certificates - like LetsEncrypt.

>

> https://stackoverflow.com/questions/43571572/programmatically-update-certificates-in-tomcat-8-without-server-restart



There

>

are no currently-correct answers to that question.



I can fix that.



- -chris

-BEGIN PGP SIGNATURE-

Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/



iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7em/oACgkQHPApP6U8

pFiuqw//SfBmQ4eMhXUw0WkiQ5Fe9dJIa724h0wv60ghJQK80n9cu7CdcB9om9R4

w4tbhvxkBCc/ENBQP2gfszRwT8Y7EleyDTY09OKaQ1aiqgnWaE4hj2Srmoi/kUFi

LAbgNm/vpHzTS/ozp3+T/vD8GtLHc1UXDnsKY3zzMc8CFgRo10YDyAMJoC8S4SGe

1Ji4NF1uY2aqeY7LPBMDU1IrQTK4EW2SNFV9JSyEjsPBB8yKCzvGdCJRPvJih/mg

ZsTI6w/X2cldSbVvpAUh5hOUglo8+5BqN2W1aOKttwxbds/KbckQg5vOHs4+sCPk

M6ngE0sYggz2JsF/IZQ9PtMDtuZdKxmCWsXwbTw7G5qpjv6RWQW2GtMl52d1qabO

Xna7npVd1kiGOvA/uuNPxI7Z3qOhYiCs78JCG6oaUQejqywgvKO4HyibNlFJD1F+

P3S/SLuxQB7uhC5CuY3wKXckJEbGbL7D04wkCY90N1q5PQO0oy5j/jyS3y6cDmHw

SZNuH3Gvc7WUE8xbJNx5W8fP9m5mpwAJ0lwcCgqN8zqUEqbbE4imrMOrVxjmqPiT

V/jySH8D0ckk+jyQ8gADmId8vGF5KrQCrfTwxjpLhxSuEZ+cB3d7tsOCCI6Xw9o1

ShMM500fXsMgHkrhyqg7gG6Pf7zVutqhgOBkUZUntFkuMEB38Ow=

=O9u2

-END PGP SIGNATURE-

Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Merlin,

On 6/8/20 10:17, Merlin Beedell wrote:
> I am getting a lot of flack from some senior devs who insist that
> Tomcat must be put behind a Proxy – HA Proxy or Nginx, which will
> handle the SSL offloading etc.
>
> While this seems sensible for multi-server environments, they want
> it for single server too.  But Tomcat can do all the things that
> are required:
>
> * Certificate handling. * TLS level and Cipher restrictions * CORS
> handling (though this could be simpler!)
>
> But now with the requirement for LetsEncrypt certificates, we find
> that Tomcat has to be restarted every 3 months.  Indeed – any
> changes to the above require tomcat restarts – and that is found to
> be unacceptable.

Nonsense.

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

Updating CORS configuration may require a redeployment of your web
application, but it does not require Tomcat to be shut-down.

There are other reasons to use a reverse proxy in front of Tomcat, but
none of the above are good reasons.

> So what I really want to understand is if Tomcat has any plans to
> include the ability to restart an https connector WITHOUT needing
> to restart the whole of Tomcat.  Better still, a hook that would
> help refresh certificates – like LetsEncrypt.
>
> https://stackoverflow.com/questions/43571572/programmatically-update-c
ertificates-in-tomcat-8-without-server-restart

There
>
are no currently-correct answers to that question.

I can fix that.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7em/oACgkQHPApP6U8
pFiuqw//SfBmQ4eMhXUw0WkiQ5Fe9dJIa724h0wv60ghJQK80n9cu7CdcB9om9R4
w4tbhvxkBCc/ENBQP2gfszRwT8Y7EleyDTY09OKaQ1aiqgnWaE4hj2Srmoi/kUFi
LAbgNm/vpHzTS/ozp3+T/vD8GtLHc1UXDnsKY3zzMc8CFgRo10YDyAMJoC8S4SGe
1Ji4NF1uY2aqeY7LPBMDU1IrQTK4EW2SNFV9JSyEjsPBB8yKCzvGdCJRPvJih/mg
ZsTI6w/X2cldSbVvpAUh5hOUglo8+5BqN2W1aOKttwxbds/KbckQg5vOHs4+sCPk
M6ngE0sYggz2JsF/IZQ9PtMDtuZdKxmCWsXwbTw7G5qpjv6RWQW2GtMl52d1qabO
Xna7npVd1kiGOvA/uuNPxI7Z3qOhYiCs78JCG6oaUQejqywgvKO4HyibNlFJD1F+
P3S/SLuxQB7uhC5CuY3wKXckJEbGbL7D04wkCY90N1q5PQO0oy5j/jyS3y6cDmHw
SZNuH3Gvc7WUE8xbJNx5W8fP9m5mpwAJ0lwcCgqN8zqUEqbbE4imrMOrVxjmqPiT
V/jySH8D0ckk+jyQ8gADmId8vGF5KrQCrfTwxjpLhxSuEZ+cB3d7tsOCCI6Xw9o1
ShMM500fXsMgHkrhyqg7gG6Pf7zVutqhgOBkUZUntFkuMEB38Ow=
=O9u2
-END PGP SIGNATURE-

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

Re: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

[Romain Manni-Bucau]

Hi Merlin,

you can reload the certificates already (think it is in JMX but you can
also do it programmatically through a listener or valve - which is
convenient to handle the let's encrypt public part), you can have a look to
https://github.com/apache/openwebbeans-meecrowave/blob/master/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt/LetsEncryptReloadLifecycle.java#L155
for
an impl.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 8 juin 2020 à 16:17, Merlin Beedell  a
écrit :

> I am getting a lot of flack from some senior devs who insist that Tomcat
> must be put behind a Proxy – HA Proxy or Nginx, which will handle the SSL
> offloading etc.
>
> While this seems sensible for multi-server environments, they want it for
> single server too.  But Tomcat can do all the things that are required:
>
>- Certificate handling.
>- TLS level and Cipher restrictions
>- CORS handling (though this could be simpler!)
>
> But now with the requirement for LetsEncrypt certificates, we find that
> Tomcat has to be restarted every 3 months.  Indeed – any changes to the
> above require tomcat restarts – and that is found to be unacceptable.
>
>
>
> So what I really want to understand is if Tomcat has any plans to include
> the ability to restart an https connector WITHOUT needing to restart the
> whole of Tomcat.  Better still, a hook that would help refresh certificates
> – like LetsEncrypt.
>
>
> https://stackoverflow.com/questions/43571572/programmatically-update-certificates-in-tomcat-8-without-server-restart
>
>
>
> Merlin Beedell
>
>
>