[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Mark Thomas --- Fixed in: - 11.0.x for 11.0.0-M12 onwards - 10.1.x for 10.1.14 onwards - 9.0.x for 9.0.81 onwards - 8.5.x for 8.5.94 onwards -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #13 from Remy Maucherat --- (In reply to Michael Osipov from comment #12) > Maybe this listener should receive a reload interface will will decide > whether the file needs to be reloaded or not? We can provide a default impl, > but others can implement their logic?! There's already a JMX command for reload though. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 Michael Osipov changed: What|Removed |Added CC||micha...@apache.org -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #12 from Michael Osipov --- (In reply to Mark Thomas from comment #8) > I've been discussing this with the users recently and came up with the > following approach. > > - Lifecycle listener that ships with Tomcat > - Every X minutes (driven by background process but customisable so checks > don't happen every time the background process runs) > - Checks expiry time of each cert. > - For each cert with less than Y days reload TLS config > - If cert still has less than Y days remaining, log a warning > > This listener would be disabled by default but available as part of the > standard Tomcat distribution. Maybe this listener should receive a reload interface will will decide whether the file needs to be reloaded or not? We can provide a default impl, but others can implement their logic?! -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #11 from Remy Maucherat --- (In reply to Mark Thomas from comment #8) > I've been discussing this with the users recently and came up with the > following approach. > > - Lifecycle listener that ships with Tomcat > - Every X minutes (driven by background process but customisable so checks > don't happen every time the background process runs) > - Checks expiry time of each cert. > - For each cert with less than Y days reload TLS config > - If cert still has less than Y days remaining, log a warning > > This listener would be disabled by default but available as part of the > standard Tomcat distribution. Good feature. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #10 from Mark Thomas --- Not every key/cert is defined by a file. At least one cloud provider (Azure) has a JCA provider that enables Java apps to access keys in the cloud provided vault without any reference to a file on the file system. Support for certificateKeystoreFile to accept "" or "NONE" was implemented for hardware keystores. Without access to a file, a way to determine when to trigger the reload was required. Given this listener is intended for systems that have automated key updates, X days before current key expiry was a simple trigger that worked for all the scenarios. Happy to consider alternatives if someone has a better idea. The logging was intended to be annoying. If you have a system that is meant to automatically updates your TLS keys then a noisy log message when that system fails seems reasonable to me. Thinking about it, you will want a log message when TLS reloading is triggered so there is going to be a log message anyway. There is probably some fine tuning to do once the first draft of this is implemented. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #9 from Christopher Schultz --- (In reply to Mark Thomas from comment #8) > I've been discussing this with the users recently and came up with the > following approach. > > - Lifecycle listener that ships with Tomcat > - Every X minutes (driven by background process but customisable so checks > don't happen every time the background process runs) > - Checks expiry time of each cert. > - For each cert with less than Y days reload TLS config Why have this "must be less than Y days-to-expiration" predicate? Why not just always-reload if e.g. the source timestamp has changed? There are many reasons to swap-out certificates that are not expiring. We probably should make sure the file is at least X ms old to prevent trying to reload a file that it in the process of being re-written. > - If cert still has less than Y days remaining, log a warning I think this will fill the logs. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #8 from Mark Thomas --- I've been discussing this with the users recently and came up with the following approach. - Lifecycle listener that ships with Tomcat - Every X minutes (driven by background process but customisable so checks don't happen every time the background process runs) - Checks expiry time of each cert. - For each cert with less than Y days reload TLS config - If cert still has less than Y days remaining, log a warning This listener would be disabled by default but available as part of the standard Tomcat distribution. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #7 from Christoph Anton Mitterer --- I'd also say that any form of automatic reloading (e.g. via fnotify on respectively periodic reloading of the cert/key files) is a bad idea. It may e.g just happen at the time where only one of the two has already been replaced. Instead, I've asked in bug #66526 for a way to *only* reload key/certificate files - not any other configuration. Such a feature should be easily usable with e.g. certbot and friends. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 Rainer Jung changed: What|Removed |Added Target Milestone|--- |-- Component|Common |Connectors Product|Tomcat Connectors |Tomcat 10 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #6 from Anders Rundgren --- > The OP recommends using a package that is limited (APR only), fragile > (custom non-daemon watcher thread, suspicious call behavior, and (IMHO) > unnecessary. I'm merely proposing adding this kind of functionality. I'm not an expert on Tomcat internals so I have no suggestion on how :) > Another option would be to use Romain Manni-Bucau's complete ACME component > within Tomcat. It handles the whole ACME process, including reloading the > connector as necessary. Although I was unaware of Romain's ACME stuff, I'm a little bit worried about scoping key reload exclusively to ACME. In addition there are several external ACME packages like https://certbot.eff.org/ which are designed to work with arbitrary Web servers. I'm currently using certbot and the mentioned custom APR connector. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #5 from Christopher Schultz --- (In reply to Michael Osipov from comment #4) > Why is it not possible to use the background process to > detect mtime change of cert/private key and initiate a connector reload? It is possible. It's best done using a Listener (or maybe a Valve?) with a background process. Another option would be to use Romain Manni-Bucau's complete ACME component within Tomcat. It handles the whole ACME process, including reloading the connector as necessary. The OP recommends using a package that is limited (APR only), fragile (custom non-daemon watcher thread, suspicious call behavior, and (IMHO) unnecessary. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #4 from Michael Osipov --- Stupid question: Why is it not possible to use the background process to detect mtime change of cert/private key and initiate a connector reload? This would be, of course, off by default. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #3 from Mark Thomas --- I think there is an argument for providing a listener to do this as part of the Tomcat distribution. Those users that need it can then enable it. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #2 from Anders Rundgren --- Since administrating SSL certificates is a major PITA, I'm looking for a built-in solution that is compatible with ACME. For my current use I will use: https://github.com/schnatterer/tomcat-reloading-connector. If there are other ways to achieve this functionality without having OS-specific scripts, that would be fine as well. The most popular solution seems to put another Web server in front of Tomcat. Although certainly doable, this adds more complexity. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 65770] Make keys reload automatically
https://bz.apache.org/bugzilla/show_bug.cgi?id=65770 --- Comment #1 from Remy Maucherat --- I'm not sure it is a very good idea to use an automagical reload here. There is functionality to trigger a reload of the SSL host configs using JMX, this is more predictable. Is it not a good solution for you ? If you still want this, then you can write a custom Server listener, that uses the Tomcat background process feature (this avoids having a dedicated thread) to monitor the resources you want to check, and that would call the reload hook (either normally or through JMX). -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
