-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 12/4/16 3:24 PM, Mark Thomas wrote: > On 04/12/2016 20:09, Christopher Schultz wrote: >> All, >> >> On 12/1/16 6:07 PM, Christopher Schultz wrote: >>> All, >> >>> On 12/1/16 5:59 PM, Christopher Schultz wrote: >>>> All, >> >>>> I'm trying to use JMX to do things with Tomcat Connectors and >>>> ProtocolHandlers. Specifically, I'd like to re-load the >>>> keystore (really certificate) used for an HTTPs connection. >> >>>> I'm currently using Tomcat 8.0.30 for my testing. >> >>>> It looks like the ProtocolHandler is really the place where >>>> the TLS configuration is taking effect, and not the >>>> Connector, so I'm largely ignoring the Connector for now. Is >>>> that the right choice to make, here? > > It depends. What you actually need to do is swap out the > SSLContext. This is in the SSLHostConfigCertificate. Yeah, I knew I really needed to swap-out the SSLContext. I wasn't sure how easy that would be, so I started out with what was possible with JMX . >>>> It seems that calling the pause()/resume() or stop()/start() >>>> on the ProtocolHandler have no effect on resetting the >>>> SSLServerSockeyFactory, which is what would be required to >>>> achieve my goals (update a certificate for a running Tomcat >>>> instance). > > You need new code to do this if you want to handle it smoothly. > Failing that, you need to trigger bind(). Which means: > bindOnInit=false start() stop() > > change TLS config > > stop() * drop existing connections, new connections fail here * > this is generally a Bad Thing (tm) start() > > new TLS config available I'll have to check again, but above I was talking about the protocol handler, not the Connector. I believe that bouncing the protocol handler does not reload the certificate, etc. >>>> I suspect I'll have to call init(). When I do this without >>>> specifying bindOnInit=false awful things happen. First, >>>> calling init() gets me an error on stdout that the address is >>>> already in use, and then it's basically not possible to >>>> restart the ProtocolHandler after that point: it's dead as >>>> far as I can tell, because you can't call start() or resume() >>>> without getting a whole bunch of errors. > > You can't just call any method you like. You have to respect the > standard Lifecycle state transitions even though Endpoint doesn't > enforce them (the Interface and supporting base classes are not > visible to the package. :) Yeah. I was just flailing about a bit, here. >>>> Does that sound like a problem to anyone? I would think that >>>> failure to call init() would leave the ProtocolHandler in an >>>> uninitialized state, but I'm wondering if trying to >>>> RE-initialize the ProtocolHandler should be something that >>>> won't damage a previously-initialized component. When trying >>>> to script these types of connections, having a >>>> non-destructive init() might be useful. > > This is not a problem. Ok. >>>> So, I set bindOnInit="false" which is documented[1] to unbind >>>> on "stop". When calling stop(), the port continues to be >>>> bound by Tomcat. Calling stop() and then start() throws a >>>> BindException. :( Destroying the ProtocolHandler also leaves >>>> the port still bound, and also (unsurprisingly) destroys the >>>> ProtocolHandler. > > That sounds like a possible problem but we have unit tests that > explicitly test this behaves as expected (TestXxxEndpoint) so a > Tomcat bug looks unlikely. I think this ended up being an error with the keystore itself which caused the connector to get itself into a stat from which it could not be resurrected. I'll repeat my observations with a bit more care and report back. I think there is in fact something here that could be improved. >>>> Stopping the Connector also does not release the port. :( >>>> Calling stop() and then start() also throws a BindException. >> >>>> At this point, I think I'm stuck. Is there a bug here? >> >>>> I'm going to upgrade to 8.0.latest and repeat my tests, just >>>> in case. >> >>> I updated to 8.0.39 and noticed that I had moved my keystore >>> out of the way temporarily and so the connector was failing at >>> some point looking for that. I'll be repeating my tests with >>> more attention to detail, but what I think I've noticed is that >>> there are certain errors which can occur that cause the >>> Connector to get itself into a bad state. >> >>> Specifically, I think that problems with the crypto setup >>> cause the connector to bind to the port, then fail and not >>> unbind. Any later attempt to re-start the Connector fails >>> because the port is still bound. >> >>> I think the connector should catch (some?) exceptions and >>> unbind the port in those cases when bindOnInit=false. >> >> Any comments on whether or not these items should be considered >> bugs? Specifically, uncaught exceptions which can prevent the >> connector from coming back up again? > > If you find a sequence where start-up fails due to bad config and > puts the connector in a start where it can't be started once the > config has been fixed then that is probably a bug but likely only a > minor one. Okay. I'm fairly sure I can come up with a minimal set of steps-to-reproduce. I'll report back. Thanks, - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYRey+AAoJEBzwKT+lPKRYMAgP/11tR0gZsd6E2zhf9HcVsl37 xQzXLZqLELBXBj0Ih+aK9fk598M8k4KMKBsdMlMSKGvcM0MCSgANHvoGSjYW7znn 9w7Y3+oVmjpR3NNcL4IoHyy15n7zSC8f3E8bDbf6RsWix2YHm6ZE/zf672yzCPJW 1F5ADICbBy0nQt6PPU2gMEnd4T3DE2bG4K/s+EhRKUsY174ohOwmjK+90zhEd0Yi UFbbSHgv3B3KBFh+lY7S3Cskc3UF/lu4bc/npVSr6AVXEtODO4RHdvifpgEFyG23 okj0jEFKOlKDAoC1UTsbENLXF2OHFamtDbgsj5ynNDKCAzwHbw9/b26mCmdS6ba5 EILBxKHQS1MyMIoSRUzGxmfq9WiprWSCxugcx96q7Wj6se74GT5A8anDWFgl/rMk 4wLeyunHv590CitoAxDusAoG/w+UdNad4MxQ41Y4T61jblbMIOLIk8hFWGj9vNvG x14KI9YpR4+YPebCGWYQX4N+x/lsLI5Vy8nZVPHgAfMtNkTU5Ru8S1CQHXA1TzIW B8Eltr3LLaL2uGfZ7b1by0/DKCsrCmGzEM40T8QqM4WCpImIX4q7xd/+HC7ml7Ct /CUrROSAzhfwHdL2SWgoCYXg5clbOM0UXBnOWBfGHo0sBYdSxeGWU9B6g6KpUhM6 YwlshmQ5UkbcqzUHKDzm =BFbw -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
