httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 14104] - not documented: must restart server to load new CRL
Date Sat, 14 Jan 2006 00:59:48 GMT
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=14104>.
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=14104


tlhackque@yahoo.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |
            Version|2.0.43                      |2.0.54




------- Additional Comments From tlhackque@yahoo.com  2006-01-14 01:59 -------
I, too have been tripped up by this.  Please reconsider.

It seems to me that the current behavior is undesirable, and that the problems 
joe raises are all soluble.  The CRL is unlike other configuration changes; it 
has a expiration date and is expected to require periodic refresh.

I update my crl daily with a lifetime of several days - more on general 
principles than because it's highly volatile.  However, if something bad 
happens, I'd like a reasonable latency till the crl is refreshed.

I agree that polling "just in case" could a lot of extra synchronization, and 
is probably overkill.

But it does not seem friendly or robust to have apache stop service when it 
knows what's wrong & the data it needs is sitting on the disk where the config 
file says it is.

Apache seems to have sufficient synchronization to "revoke all certificates 
until you get updated CRL".  It also has sufficient smarts to do a graceful 
restart.

So, why not do this:

When a thread finds that the CRL is out of date, it synchronizes on a CRL 
update lock.  Under that lock, it looks to see if there's a new CRL.  If there 
is, it schedules a graceful restart, placing the request that detected the 
problem back on the service queue.  The request will be picked up by the new 
generation of the configuration DB after the restart.

This way, the update only happens when there is a problem; existing mechanisms 
are used.  The only delay is to the requests at time of crl expiration.  And by 
adjusting the expiration time, an administrator can minimize the impact.

The work-around of apachectl -k graceful in the crl rebuild script should work 
on a single system, single server.  But in a more interesting environment (say, 
multiple systems with the crl on a networked disk), it's a lot more work.

But at an absolute minimum, update the documentation for the 
SSLCARevocationFile directive to indicate that a restart is required when the 
file changes.  As an experienced system manager, but new to apache, it was by 
no means obvious to me.



-- 
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


Mime
View raw message