Le mar. 14 juil. 2020 à 15:50, Merlin Beedell <mbeed...@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-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
>
>
