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