DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=42897>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=42897 Summary: httpd can't reload CRLs without restarts in a chroot jail Product: Apache httpd-2 Version: 2.2.3 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: mod_ssl AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] We run Apache under modsecurity (and chroot patch before that) in a higher-than-usual security environment, and use mod_ssl with client certificates to limit access. So the CRL becomes of paramount importance to ensure only valid users can access the area... Anyway, as it's in a jail, HUPs and USR1 signals don't work as usual - Apache finds all the libraries have disappeared, along with modules, etc. I could move those whole lot into the jail - but it sort of reduces the point of using modsecurity/etc to do the job. So currently I have to do a full restart to get Apache to notice the CRL has been updated - which breaks existing downloads/etc. Google'ing for "apache crl reload" finds there's a few others experiencing the same issue. So I was wondering about a compromise. Having copies of the updated CRL files in the jail wouldn't be a big problem, so what about putting some form of auto-reloading of the CRLs when the files change - like Samba does with it's config files? Even if it isn't instantaneous it would be a vast improvement. e.g. Apache starts, loads the CRL along with a timestamp of when it did it. Then if (say) 20 minutes later someone connects with a cert, Apache could decide the CRL has timed out, reopens and reloads the CRL files (which in my case will be copies in the jail) and resets the timestamp. That way the CRL stays "almost" up to date - and doesn't need any signaling to Apache. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
