-----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
