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 <[email protected]>
Sent: 11 June 2020 7:17 PM
To: Tomcat Developers List <[email protected]>
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
<[email protected]<mailto:[email protected]>> 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
> <[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>> 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
>> <[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>>
>
>> Sent: 08 June 2020 9:14 PM
>
>> To: Tomcat Developers List
>> <[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>>; Merlin Beedell
>> <[email protected]<mailto:[email protected]>
>> <mailto:[email protected]<mailto:[email protected]>>>
>
>> 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:
> [email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> For additional commands,
> e-mail: [email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
>
-----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:
[email protected]<mailto:[email protected]>
For additional commands, e-mail:
[email protected]<mailto:[email protected]>
