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