You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2007/07/15 04:57:54 UTC
DO NOT REPLY [Bug 42897] New: - httpd can't reload CRLs without restarts in a chroot jail
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: bugs@httpd.apache.org
ReportedBy: jhaar@trimble.co.nz
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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 42897] - httpd can't reload CRLs without restarts in a chroot jail
Posted by bu...@apache.org.
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
jorton@redhat.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
------- Additional Comments From jorton@redhat.com 2007-11-05 02:25 -------
Working out how to reload CRLs periodically adds a significant amount of
complexity, and also a number of policy issues (what to do if CRL unreadable
etc); for little gain - if you want a "live" revocation decision you need
something like OCSP anyway (covered by other bugs).
Graceful restarts are a sufficient solution for many users; the fact that chroot
jails break that doesn't really make the alternative more compelling.
--
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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org