DO NOT REPLY 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=42
897>.
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: bugshttpd.apache.org
        ReportedBy: jhaartrimble.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=ema
il
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the
assignee.

------------------------------------------------------------
---------
To unsubscribe, e-mail: bugs-unsubscribehttpd.apache.org
For additional commands, e-mail: bugs-helphttpd.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=42
897>.
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


jortonredhat.com changed:

           What    |Removed                     |Added
------------------------------------------------------------
----------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX




------- Additional Comments From jortonredhat.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=ema
il
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the
assignee.

------------------------------------------------------------
---------
To unsubscribe, e-mail: bugs-unsubscribehttpd.apache.org
For additional commands, e-mail: bugs-helphttpd.apache.org