On 1/8/20 5:18 AM, Christopher Schultz wrote:
. . .
Now the URL line becomes (for me, using a management port):
http://localhost:8217/manager/jmxproxy?invoke=Catalina:type%3DProtocolHa
ndler,port%3D8215&op=reloadSslHostConfigs
. . .
Have you configured any <SSLHostConfig> elements, or are you using the
old-style configuration like:
<Connector SSLProtocol="TLS" keystoreFile="..." />
I just have a connector definition in server.xml, almost exactly the
same as I've been using in Tomcat 7 installations. I don't think prior
to this discussion, I'd even *heard* of "SSLHostConfig."
You may need to change your connector configuration to use nested
<SSLHostConfig> elements if it's not that way already.
Try invoking the "findSslHostConfigs" operation to see if it
completes. That will at least tell you if you have your objectname
correct.
Like this:
$ curl -k -u "test:test"
"https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocol
Handler,port%3D8443,address%3D127.0.0.1&op=findSslHostConfigs"
This gave me a stacktrace:
curl -k -u "test:test"
"https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocolHandler,port%3D8443,ad
dress%3D127.0.0.1&op=findSslHostConfigs"
But omitting the address parameter, as in your own test, gave me this:
curl -k -u test:test
"https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocolHandler,port%3D8443&
op=findSslHostConfigs"
OK - Operation findSslHostConfigs returned:
org.apache.tomcat.util.net.SSLHostConfig@1a9b80c2
curl -k -u test:test
"https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocolHandler,port%3D8443&
op=reloadSslHostConfigs"
OK - Operation reloadSslHostConfigs without return value
And I just now confirmed that the latter did indeed reload the keystore
when I swapped between the regular keystore and a self-signed one, even
though I just have the old-style connector definition.
So apparently, it was the "address" parameter that was killing me.
Interesting.
The idea was to put the Tomcat server on the same certificate and
private key files as the httpd server on the same EC2 box. Do I need
this newfangled "SSLHostConfig" for that?
At any rate, I think we have another breakthrough here, but at the same
time, I think I also need to disable the "test" user, and get back to
another project I have going, at least for now.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org