-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Merlin,
On 7/14/20 09:49, Merlin Beedell wrote:
> 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.
Right. That could have been more clear: the in-memory configuration is
re-applied to the running SSLContext. Well, actually, we replace the
SSLContext with a new one and allow the GC to clean up the mess.
So if you want to actually reconfigure things, you ave to specifically
reconfigure them first (in memory, likely using JMX / mbeans to do
that) and then invove the reloadSsl operation.
> 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?
This should work.
- -chris
> -----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.
>
> 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=reloadSsl
Ho
>
>
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.JSSEImplementat
io
>
>
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
>
> ---------------------------------------------------------------------
>
>
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
>
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8N9MkACgkQHPApP6U8
pFg0/xAAv4yhokHvOXdQh+6Geoo2IvRtZnQbWWfRK/jIRygtHRsJvO9hzk7eLbq7
hgWaE4FKdJUMwps24Z4RG9aC4AMs0ZysMkSIcvGzSK99SRzuGQPa8q97AHh/REWo
El7wyW92ylrxEL2ouAz3GhumIAKIY6kK0UypkhmHsr47WQRkeXpVaqZZLSiAuVCx
cuH32DeNORVmz3H8p9Lo2IK8JM4k1WTgSDwRGau/sLVz6bVvngRYE19BDW7sOJj/
O/+jBOun5BH9aQ1l6MP/ZJqy09fY0IgStc4lqPHeAzos4NhaavhIgYDEB/qzpAWK
/I1XEnSSElpTRE6HC1Shq1e9uCoWirWPHn5iUsj6Qe6AwDhyiB+HHzNX4nAmFj5V
OkI0y5e4WqRXGxUan9dJwsFmrJEuVnYmdsyPGMBgWQ1+yhUSkbWjwF57S520CORk
tWuzSTTd0te1KSqWTykoI1i9nu8n4ZWxPKpDk3CsFAK0gB+Z+g8sSwcdQgLL05C+
As/4sfdOPLAHxrm+ijCwuy4fD3QD/nqPdSgtWBASWQlU/Mvf31qZJGW2Nu0r4L1/
DpkSWld2HSYV9TMKNvgCyhwMucHy8HulYOuugU1P9AKwSsGtyZNUpWocTvHC7QkE
h2IgMjq0iHb/PkmljU7CwceBA5dt0Kp74IgMm/VWnULQdFxu4Uw=
=OyEt
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
