DO NOT REPLY [Bug 14104] not documented: must restart server to load new CRL

2011-11-21 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=14104

--- Comment #11 from tlhack...@yahoo.com 2011-11-21 17:05:01 UTC ---
Still interested in this.

I'd like to see the patch in comment 9 work with revocationpath, and the
multiple CA bug reported in comment 10 fixed as well.

9 years after this was first reported, X.509 certificates are even more
important...and CRLs are part of the support.  

I still consider the current behavior a bug, not a new feature since httpd is
ignoring the CRL's expiration date.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org



DO NOT REPLY [Bug 14104] not documented: must restart server to load new CRL

2010-07-29 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=14104

Benjamin Dauvergne  changed:

   What|Removed |Added

 CC|bdauver...@entrouvert.com   |

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org



DO NOT REPLY [Bug 14104] not documented: must restart server to load new CRL

2010-07-28 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=14104

--- Comment #10 from nada  2010-07-28 13:51:55 
EDT ---
I've tested the from Comment #9 against httpd 2.2.15

I'm having here a setup with multiple sub-CAs (each with its own CRL) - and
could successfully login with revoked certs from the sub-CAs after the patch
above was applied.

So, this patch seems to have following bug:
If you have multiple CRLs within one file the patch only loads the first one.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org



DO NOT REPLY [Bug 14104] not documented: must restart server to load new CRL

2009-01-15 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=14104


Sam Bryan  changed:

   What|Removed |Added

 CC||sam.br...@montal.com




-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org



DO NOT REPLY [Bug 14104] not documented: must restart server to load new CRL

2008-09-05 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=14104


Benjamin Dauvergne <[EMAIL PROTECTED]> changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 14104] not documented: must restart server to load new CRL

2008-06-11 Thread bugzilla
https://issues.apache.org/bugzilla/show_bug.cgi?id=14104





--- Comment #9 from Grzegorz <[EMAIL PROTECTED]>  2008-06-11 06:44:48 PST ---
Created an attachment (id=22109)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22109)
Automatically reload CRL when the previous one expires and a new one is
available

With this patch applied, Apache will reload a certificate revocation list (CRL)
file, when
* previous CRL, stored in memory expired
* a new CRL file is available (based on file mtime)

It only works with CRLs loaded with SSLCARevocationFile, but if there's
interest, I'll extend it to support SSLCARevocationPath as well.

It doesn't require any additional options; Apache's behavior will not change if
you don't supply fresh CRLs. If you do, it will automagically reload them when
needed.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 14104] - not documented: must restart server to load new CRL

2007-12-05 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




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



DO NOT REPLY [Bug 14104] - not documented: must restart server to load new CRL

2007-12-04 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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





--- Additional Comments From [EMAIL PROTECTED]  2007-12-04 09:20 ---
I agree that reloading of CRLs when necessary is a highly desirable feature.

OpenSSL 0.9.9 does have some improved CRL support but adding generic reloading
to cover all cases into OpenSSL isn't really practical. OpenSSL 0.9.8 doesn't
have reloading support but its handling isn't as broken as mod_ssl manual CRL
handling.

As a general solution there are several options.

One is to run a local OCSP responder which makes use of CRLs to provide
revocation information. Then mod_ssl can determine certificate status over OCSP
and the responder can deal with CRLs in an appropriate manner. I did write such
a responder for a similar situation but never got round to getting the
implementation into a publicly usable form.

Another option is to have a database of CRL information in mod_ssl. A bit like
the session cache but for revocation information. Note that I say "revocation
information" as opposed to storing full CRLs because CRLs can be quite large and
decoding on each use is a considerable overhead. It is better to just store the
set of revoked certificates serial numbers (CRL entries) and have a lookup 
mechanism which each thread could use.


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



DO NOT REPLY [Bug 14104] - not documented: must restart server to load new CRL

2006-05-23 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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





--- Additional Comments From [EMAIL PROTECTED]  2006-05-23 12:58 ---
Hi All,

I have also the same problem.

You seems to forget the exact role of a CRL. 
Remember : CRL X509 format is a list of Revoked Certificates. Thus, the goal 
here is to stop the access to someone that has a revoked certificates.

For a security point of view, waiting until the CRL Expiration date is not a 
good solution (can be 2 days or more). You put your business at risk. In fact, 
According to some PKI Policies (CSP - Cerificate Security Policies), depending 
of your working environment, (as in my case), the Revoked certificates must be 
blocked maximum 10 seconds after the effective revoke. Thus in my case, soon as 
the CRL has been updated, you have to reload it, and to block any access. This 
is not only special to my case, any companies (like insurrance,financial, ...) 
has these types of rules.

More : A crl, on our case is published every 30 min, even if no revoke occurs 
(to avoid overwritte of our CRL and ensure that all chains is working). or 
immediately after a revoke. His expiration date (next update) is at least 48 
hours (this is only for business continuity, to have time to make intervention 
in  case of CRL distribution problem or whatever).

More : We are also using Appliance Reverse proxy hardware, XML security 
Gateway, Software Application Firewall Hardware. All of them has these types of 
feature about the CRL. It load it, else based on a regular verification time 
(ie every 5 seconds), or immediatly after it detects the change. It's depends 
of the product. Why this will be different in Apache ? IIS of microsoft is 
working also like that.

Regards






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



DO NOT REPLY [Bug 14104] - not documented: must restart server to load new CRL

2006-01-13 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |
Version|2.0.43  |2.0.54




--- Additional Comments From [EMAIL PROTECTED]  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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 14104] - not documented: must restart server to load new CRL

2005-01-19 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2005-01-19 14:46 ---
Periodically reloading the CRL file from within httpd does not really sound
feasible (would you re-load and reparse it in each child? what if the children
got out of synch? what if the re-load failed? what about thread-safety issues
since the CRL is stored in the server-global config structure).

If the CRL changes relatively infrequently over time, you could cron a
(graceful) restart to pick up changes.  If it is updated so frequently that
restarting to pick up changes is not practical, you need OCSP (or something like
it).

-> WONTFIX

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



DO NOT REPLY [Bug 14104] - not documented: must restart server to load new CRL

2004-12-26 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|normal  |enhancement
  Component|Documentation   |mod_ssl




--- Additional Comments From [EMAIL PROTECTED]  2004-12-26 22:30 ---
Reclassified as a feature request against mod_ssl. Thanks for the suggestion.

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



DO NOT REPLY [Bug 14104] - not documented: must restart server to load new CRL

2004-11-25 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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





--- Additional Comments From [EMAIL PROTECTED]  2004-11-25 07:58 ---
I would actually like to see some way of enabling/forcing Apache to re-read the
crl file episodically.

This could either be based on the "next update" field within the CRL itself, or
more flexibly, some interval specified in a new mod_ssl Directive.  I favour the
latter as basing it on the "next update" field in the CRL raises issues about
what to do once that date/time has passed and the CRL file has not been updated.

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



DO NOT REPLY [Bug 14104] - not documented: must restart server to load new CRL

2004-11-22 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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





--- Additional Comments From [EMAIL PROTECTED]  2004-11-22 15:04 ---
The server needs to be restarted for just about any change to take effect. It's
not clear that this is explicitly documented anywhere, and I'm not really sure
where that information should be placed where it would be effective. Any change
of configuration requires a server restart. This is not SSL specific. Perhaps an
entry in the FAQ is warranted? Thoughts?

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



DO NOT REPLY [Bug 14104] - not documented: must restart server to load new CRL

2004-06-07 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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

not documented: must restart server to load new CRL

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|mod_ssl |Documentation

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 14104] - not documented: must restart server to load new CRL

2003-02-23 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14104

not documented: must restart server to load new CRL

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|time zone discrepancy in|not documented: must restart
   |evaluating CRL timeliness   |server to load new CRL

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]