You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tomcat.apache.org by Merlin Beedell <MB...@cryoserver.com> on 2020/06/08 14:17:17 UTC

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

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

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

Posted by Romain Manni-Bucau <rm...@gmail.com>.

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 <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 lun. 8 juin 2020 à 16:17, Merlin Beedell <MB...@cryoserver.com> 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
>
>
>

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

Posted by Romain Manni-Bucau <rm...@gmail.com>.

Le mar. 14 juil. 2020 à 15:50, Merlin Beedell <MB...@cryoserver.com> 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 <ch...@christopherschultz.net>
> 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&op=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:
> >
> > <Connector SSLEnabled="true" maxThreads="150" port="443"
> > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> >
> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementatio
> n">
> >
> > <UpgradeProtocol
> > className="org.apache.coyote.http2.Http2Protocol"></UpgradeProtocol>
> >
> >
> >
> <SSLHostConfig certificateVerification="false"
> > ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
> > honorCipherOrder="true" protocols="TLSv1.3,TLSv1.2">
> >
> > <Certificate certificateKeyAlias="tomcat"
> > certificateKeystoreFile="C:\opt\certificates\keystore"
> > certificateKeystorePassword="passphrase"
> > certificateKeystoreType="JKS"></Certificate>
> >
> > </SSLHostConfig>
> >
> > </Connector>
> >
> >
> >
> > And I am trying to reset it to a PKCS12 keystore:
> >
> > <Certificate
> > certificateKeystoreFile="C:\opt\certificates\web_cert.pfx"
> > certificateKeystorePassword="newpass"
> > certificateKeystoreType="PKCS12"></Certificate>
> >
> >
> >
> > 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 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.
>
>
> Other than Mark's response, there is another simple way to solve this:
> use a symlink to your keystore. Change where the symlink points if the
> keystore filename needs to change, then trigger a reload and your new
> keystore will be loaded.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8M470ACgkQHPApP6U8
> pFgD2RAAxL7gaCbGbz4pHw5Oejh6ORND9D5WbTgxhjOBNKa/c4+34k4kFKf7ZTc1
> qnrNlLyJKwh9U1pHjr920pVKaJstsqfnTjyWuAxLQ/Ijcehw9sJJdgHcQd+pRUCc
> 6Axabg8AEjAT/c3opIWdKgtEvH7IkNqbEsAphttjKyJztcLQFk7zzr9LUz5LjMyT
> /E7/f4bt8zq8/Gq7n0cJHGlU48AiqSJfN4muscQmOw7FZakbrS2uOiavuYlOxZC8
> KkORcDDQ0uHQRUFmc+bExzsUfApcsIfxFhIoj3QfC5x7eTHzTDDRnloENieJtJi/
> CKqJ1Lla4xRjPQ+Q62wcmwgJE1TAsy7BoaEf/kOHyTtVZ4IUX6LvaqamZRkiUQ93
> ivgBu6unaqjbl4KT3l4McgLRMEsXfntNQw771dTMzJ++PmZaPrAdiMRyJ6cd7GvW
> QQbSYtA7t3p77ZS/qMgyxt+EtPISU977U2QIym6w3+SnNfj98QH28qdqE/p2NE1Y
> t46ZqRA6BnA39I7qhWanWryahkxTTo60zRJqPFTjrMLzeBKW6nDv6MkAFn7sO2bk
> FyFppxgVrNFkYfqEOIkN9TwZMzz44Hs4iGO2ztmK0eZJ19MX7gXRAcYIBfDQL68a
> SskbZI69VUjfpm8PCAuS0qJtTTKi2vs3VqTk64vNOYwnwiC/z+A=
> =2J6y
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> 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: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

Posted by Christopher Schultz <ch...@christopherschultz.net>.

-----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
> <ch...@christopherschultz.net> 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&op=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:
>
>> <Connector SSLEnabled="true" maxThreads="150" port="443"
>> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementat
io
>
>
n">
>
>> <UpgradeProtocol
>> className="org.apache.coyote.http2.Http2Protocol"></UpgradeProtocol>
>
>>
>
>
> <SSLHostConfig certificateVerification="false"
>> ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
>> honorCipherOrder="true" protocols="TLSv1.3,TLSv1.2">
>
>> <Certificate certificateKeyAlias="tomcat"
>> certificateKeystoreFile="C:\opt\certificates\keystore"
>> certificateKeystorePassword="passphrase"
>> certificateKeystoreType="JKS"></Certificate>
>
>> </SSLHostConfig>
>
>> </Connector>
>
>
>
>> And I am trying to reset it to a PKCS12 keystore:
>
>> <Certificate
>> certificateKeystoreFile="C:\opt\certificates\web_cert.pfx"
>> certificateKeystorePassword="newpass"
>> certificateKeystoreType="PKCS12"></Certificate>
>
>
>
>> 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 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.
>
>
> Other than Mark's response, there is another simple way to solve
> this: use a symlink to your keystore. Change where the symlink
> points if the keystore filename needs to change, then trigger a
> reload and your new keystore will be loaded.
>
> -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
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8N9MkACgkQHPApP6U8
pFg0/xAAv4yhokHvOXdQh+6Geoo2IvRtZnQbWWfRK/jIRygtHRsJvO9hzk7eLbq7
hgWaE4FKdJUMwps24Z4RG9aC4AMs0ZysMkSIcvGzSK99SRzuGQPa8q97AHh/REWo
El7wyW92ylrxEL2ouAz3GhumIAKIY6kK0UypkhmHsr47WQRkeXpVaqZZLSiAuVCx
cuH32DeNORVmz3H8p9Lo2IK8JM4k1WTgSDwRGau/sLVz6bVvngRYE19BDW7sOJj/
O/+jBOun5BH9aQ1l6MP/ZJqy09fY0IgStc4lqPHeAzos4NhaavhIgYDEB/qzpAWK
/I1XEnSSElpTRE6HC1Shq1e9uCoWirWPHn5iUsj6Qe6AwDhyiB+HHzNX4nAmFj5V
OkI0y5e4WqRXGxUan9dJwsFmrJEuVnYmdsyPGMBgWQ1+yhUSkbWjwF57S520CORk
tWuzSTTd0te1KSqWTykoI1i9nu8n4ZWxPKpDk3CsFAK0gB+Z+g8sSwcdQgLL05C+
As/4sfdOPLAHxrm+ijCwuy4fD3QD/nqPdSgtWBASWQlU/Mvf31qZJGW2Nu0r4L1/
DpkSWld2HSYV9TMKNvgCyhwMucHy8HulYOuugU1P9AKwSsGtyZNUpWocTvHC7QkE
h2IgMjq0iHb/PkmljU7CwceBA5dt0Kp74IgMm/VWnULQdFxu4Uw=
=OyEt
-----END PGP SIGNATURE-----

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

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

Posted by Merlin Beedell <MB...@cryoserver.com>.

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 <ch...@christopherschultz.net> 
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&op=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:
>
> <Connector SSLEnabled="true" maxThreads="150" port="443"
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementatio
n">
>
> <UpgradeProtocol
> className="org.apache.coyote.http2.Http2Protocol"></UpgradeProtocol>
>
>
>
<SSLHostConfig certificateVerification="false"
> ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
> honorCipherOrder="true" protocols="TLSv1.3,TLSv1.2">
>
> <Certificate certificateKeyAlias="tomcat"
> certificateKeystoreFile="C:\opt\certificates\keystore"
> certificateKeystorePassword="passphrase"
> certificateKeystoreType="JKS"></Certificate>
>
> </SSLHostConfig>
>
> </Connector>
>
>
>
> And I am trying to reset it to a PKCS12 keystore:
>
> <Certificate
> certificateKeystoreFile="C:\opt\certificates\web_cert.pfx"
> certificateKeystorePassword="newpass"
> certificateKeystoreType="PKCS12"></Certificate>
>
>
>
> 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 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.


Other than Mark's response, there is another simple way to solve this:
use a symlink to your keystore. Change where the symlink points if the keystore filename needs to change, then trigger a reload and your new keystore will be loaded.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8M470ACgkQHPApP6U8
pFgD2RAAxL7gaCbGbz4pHw5Oejh6ORND9D5WbTgxhjOBNKa/c4+34k4kFKf7ZTc1
qnrNlLyJKwh9U1pHjr920pVKaJstsqfnTjyWuAxLQ/Ijcehw9sJJdgHcQd+pRUCc
6Axabg8AEjAT/c3opIWdKgtEvH7IkNqbEsAphttjKyJztcLQFk7zzr9LUz5LjMyT
/E7/f4bt8zq8/Gq7n0cJHGlU48AiqSJfN4muscQmOw7FZakbrS2uOiavuYlOxZC8
KkORcDDQ0uHQRUFmc+bExzsUfApcsIfxFhIoj3QfC5x7eTHzTDDRnloENieJtJi/
CKqJ1Lla4xRjPQ+Q62wcmwgJE1TAsy7BoaEf/kOHyTtVZ4IUX6LvaqamZRkiUQ93
ivgBu6unaqjbl4KT3l4McgLRMEsXfntNQw771dTMzJ++PmZaPrAdiMRyJ6cd7GvW
QQbSYtA7t3p77ZS/qMgyxt+EtPISU977U2QIym6w3+SnNfj98QH28qdqE/p2NE1Y
t46ZqRA6BnA39I7qhWanWryahkxTTo60zRJqPFTjrMLzeBKW6nDv6MkAFn7sO2bk
FyFppxgVrNFkYfqEOIkN9TwZMzz44Hs4iGO2ztmK0eZJ19MX7gXRAcYIBfDQL68a
SskbZI69VUjfpm8PCAuS0qJtTTKi2vs3VqTk64vNOYwnwiC/z+A=
=2J6y
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
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: Support for LetsEncrypt certs, and update process, in Tomcat without restart.

Posted by Christopher Schultz <ch...@christopherschultz.net>.

-----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&op=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:
>
> <Connector SSLEnabled="true" maxThreads="150" port="443"
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
>
sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementatio
n">
>
> <UpgradeProtocol
> className="org.apache.coyote.http2.Http2Protocol"></UpgradeProtocol>
>
>
>
<SSLHostConfig certificateVerification="false"
> ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
> honorCipherOrder="true" protocols="TLSv1.3,TLSv1.2">
>
> <Certificate certificateKeyAlias="tomcat"
> certificateKeystoreFile="C:\opt\certificates\keystore"
> certificateKeystorePassword="passphrase"
> certificateKeystoreType="JKS"></Certificate>
>
> </SSLHostConfig>
>
> </Connector>
>
>
>
> And I am trying to reset it to a PKCS12 keystore:
>
> <Certificate
> certificateKeystoreFile="C:\opt\certificates\web_cert.pfx"
> certificateKeystorePassword="newpass"
> certificateKeystoreType="PKCS12"></Certificate>
>
>
>
> 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 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.


Other than Mark's response, there is another simple way to solve this:
use a symlink to your keystore. Change where the symlink points if the
keystore filename needs to change, then trigger a reload and your new
keystore will be loaded.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8M470ACgkQHPApP6U8
pFgD2RAAxL7gaCbGbz4pHw5Oejh6ORND9D5WbTgxhjOBNKa/c4+34k4kFKf7ZTc1
qnrNlLyJKwh9U1pHjr920pVKaJstsqfnTjyWuAxLQ/Ijcehw9sJJdgHcQd+pRUCc
6Axabg8AEjAT/c3opIWdKgtEvH7IkNqbEsAphttjKyJztcLQFk7zzr9LUz5LjMyT
/E7/f4bt8zq8/Gq7n0cJHGlU48AiqSJfN4muscQmOw7FZakbrS2uOiavuYlOxZC8
KkORcDDQ0uHQRUFmc+bExzsUfApcsIfxFhIoj3QfC5x7eTHzTDDRnloENieJtJi/
CKqJ1Lla4xRjPQ+Q62wcmwgJE1TAsy7BoaEf/kOHyTtVZ4IUX6LvaqamZRkiUQ93
ivgBu6unaqjbl4KT3l4McgLRMEsXfntNQw771dTMzJ++PmZaPrAdiMRyJ6cd7GvW
QQbSYtA7t3p77ZS/qMgyxt+EtPISU977U2QIym6w3+SnNfj98QH28qdqE/p2NE1Y
t46ZqRA6BnA39I7qhWanWryahkxTTo60zRJqPFTjrMLzeBKW6nDv6MkAFn7sO2bk
FyFppxgVrNFkYfqEOIkN9TwZMzz44Hs4iGO2ztmK0eZJ19MX7gXRAcYIBfDQL68a
SskbZI69VUjfpm8PCAuS0qJtTTKi2vs3VqTk64vNOYwnwiC/z+A=
=2J6y
-----END PGP SIGNATURE-----

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

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

Posted by Mark Thomas <ma...@apache.org>.

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

<snip/>

> 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:
> 
>     <Connector SSLEnabled="true" maxThreads="150" port="443"
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation">
> 
>         <UpgradeProtocol
> className="org.apache.coyote.http2.Http2Protocol"></UpgradeProtocol>
> 
>         <SSLHostConfig certificateVerification="false"
> ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
> honorCipherOrder="true" protocols="TLSv1.3,TLSv1.2">
> 
>             <Certificate certificateKeyAlias="tomcat"
> certificateKeystoreFile="C:\opt\certificates\keystore"
> certificateKeystorePassword="passphrase"
> certificateKeystoreType="JKS"></Certificate>
> 
>         </SSLHostConfig>
> 
>     </Connector>
> 
>  
> 
> And I am trying to reset it to a PKCS12 keystore:
> 
>             <Certificate
> certificateKeystoreFile="C:\opt\certificates\web_cert.pfx"
> certificateKeystorePassword="newpass"
> certificateKeystoreType="PKCS12"></Certificate>

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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

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

Posted by Merlin Beedell <MB...@cryoserver.com>.

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&op=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:
    <Connector SSLEnabled="true" maxThreads="150" port="443" protocol="org.apache.coyote.http11.Http11Nio2Protocol" sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation">
        <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"></UpgradeProtocol>
        <SSLHostConfig certificateVerification="false" ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA" honorCipherOrder="true" protocols="TLSv1.3,TLSv1.2">
            <Certificate certificateKeyAlias="tomcat" certificateKeystoreFile="C:\opt\certificates\keystore" certificateKeystorePassword="passphrase" certificateKeystoreType="JKS"></Certificate>
        </SSLHostConfig>
    </Connector>

And I am trying to reset it to a PKCS12 keystore:
            <Certificate certificateKeystoreFile="C:\opt\certificates\web_cert.pfx" certificateKeystorePassword="newpass" certificateKeystoreType="PKCS12"></Certificate>

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 <rm...@gmail.com>
Sent: 11 June 2020 7:17 PM
To: Tomcat Developers List <de...@tomcat.apache.org>
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 <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
> <ch...@christopherschultz.net>
> <ma...@christopherschultz.net>>> 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=
> <https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandl
er,port=8443,address=>"127.0.0.1"&op=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 <ch...@christopherschultz.net>
> <ma...@christopherschultz.net>>>
>
>> Sent: 08 June 2020 9:14 PM
>
>> To: Tomcat Developers List <de...@tomcat.apache.org>
> <ma...@tomcat.apache.org>>>; Merlin Beedell
>> <MB...@cryoserver.com> <ma...@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
> <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
>
>
>
>
- ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
> <ma...@tomcat.apache.org>> For additional commands,
> e-mail: dev-help@tomcat.apache.org<ma...@tomcat.apache.org>
> <ma...@tomcat.apache.org>>
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7ibIYACgkQHPApP6U8
pFirPQ//XcSOJVLFXJWaHLJRLWfyZD3r12uVET731o/ciz3NbTA38XkziYPwWwj1
XimI1KVExvWdbvY/FjS7k2fddtp8tIPm4NWvbxyTpvnLR20w1K1YNltiSuv4SUlJ
rGO32XouKgE0u3vFP/bESgWSmuKgv6NHAiKlfVPsjadWyaqlG6+gQiq+QVokMcje
UOmuRp+DF7UVJ9ZHRyz4qRLZaqBElaEJwhvJc1QrvWlWZeC5vFN3m2qoUCqmyHyw
7TVjcGnbL7DTjW8DBfiItL0EzNQxWiOLFoNOf4PvBZToUrw9EGRUBZU6Vg3XKKte
vkXw+sTALXZtnHut9ObsywwMWjaMPI1HF5HKa88WwBKHlhCpmIeW0Noz5m9GXm7W
gNbJQ317MrPql+6tdL31CjQLkeytIU3JgINHjHrUSUKoBYpd8aq0ESN9Lghx62YH
MVGtgj4TQ7fW+lexeAnNhWCW0ap2h0F2uC2YeutrXUY4poC/5kKdJN1vtpprJ72D
jWWGiyE/8o90IFx8O3XOv7Fpu8ISAvpCIzSbBJf2WmmLDksmPtDJtoMr2kNCQctn
tYZHlq1+NXWcUxxsdGzZRhSB59LTxK3H09bXHNdfp2522RRk+C0MShYJBykmaTjd
D473GqjZ7it5MndnTsQxEatcw4u5+/c+pGjcqTvMuL1ADz6WwgA=
=KRBb
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org<ma...@tomcat.apache.org>
For additional commands, e-mail: dev-help@tomcat.apache.org<ma...@tomcat.apache.org>

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

Posted by Romain Manni-Bucau <rm...@gmail.com>.

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 <
chris@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
> <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
> > <chris@christopherschultz.net
> > <ma...@christopherschultz.net>> 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=
> > <https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandl
> er,port=8443,address=
> <https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443,address=>
> >"127.0.0.1"&op=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 <chris@christopherschultz.net
> > <ma...@christopherschultz.net>>
> >
> >> Sent: 08 June 2020 9:14 PM
> >
> >> To: Tomcat Developers List <dev@tomcat.apache.org
> > <ma...@tomcat.apache.org>>; Merlin Beedell
> >> <MBeedell@cryoserver.com <ma...@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
> > <https://stackoverflow.com/questions/43571572/programmatically-update-
> certificates-in-tomcat-8-without-server-restart
> <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
> >
> >
> >
> >
> - ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > <ma...@tomcat.apache.org> For additional commands,
> > e-mail: dev-help@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> >
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7ibIYACgkQHPApP6U8
> pFirPQ//XcSOJVLFXJWaHLJRLWfyZD3r12uVET731o/ciz3NbTA38XkziYPwWwj1
> XimI1KVExvWdbvY/FjS7k2fddtp8tIPm4NWvbxyTpvnLR20w1K1YNltiSuv4SUlJ
> rGO32XouKgE0u3vFP/bESgWSmuKgv6NHAiKlfVPsjadWyaqlG6+gQiq+QVokMcje
> UOmuRp+DF7UVJ9ZHRyz4qRLZaqBElaEJwhvJc1QrvWlWZeC5vFN3m2qoUCqmyHyw
> 7TVjcGnbL7DTjW8DBfiItL0EzNQxWiOLFoNOf4PvBZToUrw9EGRUBZU6Vg3XKKte
> vkXw+sTALXZtnHut9ObsywwMWjaMPI1HF5HKa88WwBKHlhCpmIeW0Noz5m9GXm7W
> gNbJQ317MrPql+6tdL31CjQLkeytIU3JgINHjHrUSUKoBYpd8aq0ESN9Lghx62YH
> MVGtgj4TQ7fW+lexeAnNhWCW0ap2h0F2uC2YeutrXUY4poC/5kKdJN1vtpprJ72D
> jWWGiyE/8o90IFx8O3XOv7Fpu8ISAvpCIzSbBJf2WmmLDksmPtDJtoMr2kNCQctn
> tYZHlq1+NXWcUxxsdGzZRhSB59LTxK3H09bXHNdfp2522RRk+C0MShYJBykmaTjd
> D473GqjZ7it5MndnTsQxEatcw4u5+/c+pGjcqTvMuL1ADz6WwgA=
> =KRBb
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

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

Posted by Christopher Schultz <ch...@christopherschultz.net>.

-----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
> <chris@christopherschultz.net
> <ma...@christopherschultz.net>> 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=
> <https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandl
er,port=8443,address=>"127.0.0.1"&op=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 <chris@christopherschultz.net
> <ma...@christopherschultz.net>>
>
>> Sent: 08 June 2020 9:14 PM
>
>> To: Tomcat Developers List <dev@tomcat.apache.org
> <ma...@tomcat.apache.org>>; Merlin Beedell
>> <MBeedell@cryoserver.com <ma...@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
> <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
>
>
>
>
- ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org> For additional commands,
> e-mail: dev-help@tomcat.apache.org
> <ma...@tomcat.apache.org>
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7ibIYACgkQHPApP6U8
pFirPQ//XcSOJVLFXJWaHLJRLWfyZD3r12uVET731o/ciz3NbTA38XkziYPwWwj1
XimI1KVExvWdbvY/FjS7k2fddtp8tIPm4NWvbxyTpvnLR20w1K1YNltiSuv4SUlJ
rGO32XouKgE0u3vFP/bESgWSmuKgv6NHAiKlfVPsjadWyaqlG6+gQiq+QVokMcje
UOmuRp+DF7UVJ9ZHRyz4qRLZaqBElaEJwhvJc1QrvWlWZeC5vFN3m2qoUCqmyHyw
7TVjcGnbL7DTjW8DBfiItL0EzNQxWiOLFoNOf4PvBZToUrw9EGRUBZU6Vg3XKKte
vkXw+sTALXZtnHut9ObsywwMWjaMPI1HF5HKa88WwBKHlhCpmIeW0Noz5m9GXm7W
gNbJQ317MrPql+6tdL31CjQLkeytIU3JgINHjHrUSUKoBYpd8aq0ESN9Lghx62YH
MVGtgj4TQ7fW+lexeAnNhWCW0ap2h0F2uC2YeutrXUY4poC/5kKdJN1vtpprJ72D
jWWGiyE/8o90IFx8O3XOv7Fpu8ISAvpCIzSbBJf2WmmLDksmPtDJtoMr2kNCQctn
tYZHlq1+NXWcUxxsdGzZRhSB59LTxK3H09bXHNdfp2522RRk+C0MShYJBykmaTjd
D473GqjZ7it5MndnTsQxEatcw4u5+/c+pGjcqTvMuL1ADz6WwgA=
=KRBb
-----END PGP SIGNATURE-----

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

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

Posted by Romain Manni-Bucau <rm...@gmail.com>.

@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 <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 jeu. 11 juin 2020 à 19:20, Christopher Schultz <
chris@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=
> <https://localhost/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443,address=>
> "127.0.0.1"&op=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 <ch...@christopherschultz.net>
> >
> > Sent: 08 June 2020 9:14 PM
> >
> > To: Tomcat Developers List <de...@tomcat.apache.org>; Merlin Beedell
> >  <MB...@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
> <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/
>
> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

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

Posted by Christopher Schultz <ch...@christopherschultz.net>.

-----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"&op=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 <ch...@christopherschultz.net>
>
> Sent: 08 June 2020 9:14 PM
>
> To: Tomcat Developers List <de...@tomcat.apache.org>; Merlin Beedell
>  <MB...@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
>
>
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org

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

Posted by Merlin Beedell <MB...@cryoserver.com>.

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"&op=reloadSslHostConfigs



Merlin Beedell

-----Original Message-----

From: Christopher Schultz <ch...@christopherschultz.net>

Sent: 08 June 2020 9:14 PM

To: Tomcat Developers List <de...@tomcat.apache.org>; Merlin Beedell <MB...@cryoserver.com>

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.

Posted by Christopher Schultz <ch...@christopherschultz.net>.

-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org