I run my local machine with a hardware time of GMT and a local time of US/Arizona (Mountain Standard), which is GMT -7. When I generate a new CRL, the time in the CRL for last update and no update is in GMT. Output from openssl crl -text -noout -in crl.pem shows: Last Update: Oct 30 17:21:57 2002 GMT Next Update: Nov 29 17:21:57 2002 GMT for a CRL created at 10:21:57 MST on October 30. However, mod_ssl says all client certificates are invalid until 17:21:57 MST: [Wed Oct 30 15:14:01 2002] [warn] Found CRL is expired - revoking all certificates until you get updated CRL [Wed Oct 30 15:14:01 2002] [error] Certificate Verification: Error (12): CRL has expired [Wed Oct 30 15:14:01 2002] [error] Re-negotiation handshake failed: Not accepted by client!? mod_ssl seems to be taking the CRL date as MST instead of GMT. (System is OpenBSD 3.1.)
I've misdiagnosed the problem. The issue is not a time zone discrepancy, the issue appears to be that the server needs to be restarted in order to load the new CRL, similar to the need to restart to load a new server certificate. This is somewhat less intuitively obvious for the CRL than for the server certificate. Is this documented anywhere?
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?
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.
Reclassified as a feature request against mod_ssl. Thanks for the suggestion.
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
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.
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
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.
Created attachment 22109 [details] 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.
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.
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.
This just bit me today. I'm using client-certificate authentication on a web server that I admin for my company, and yesterday I had to revoke one of the certificates due to a termination of an employee, and today I decided to verify that the revocation actually worked by temporarily revoking my own certificate, and surprise(!), I was still able to authenticate to the site. I had to reload Apache before it would reject my authentication. This is not the behavior I expected. It's not as though the contents of the CRLs is conceptually being "included" into the configuration like a modular config file would be; no, the CRL is a piece of volatile data that the configuration *references*, and the server needs to notice when the file changes. At the very least, the Apache mod_ssl documentation needs to note that any changes to the CRL files at SSLCARevocationPath will require a reload of the server configuration in order to take effect. This could have been disastrous if I hadn't thought to double check that Apache was actually rejecting the revoked certs.
I would also like to see the patch in Comment 9 implemented in standard code. I agree with Comment 12 that this is ancillary information and should NOT require a restart when the CRL file is modified. It is an unnecessary and error prone extra step.
Please rate the comments related to this on http://httpd.apache.org/docs/2.4/en/mod/mod_ssl.html#comment_3344 for updating the documentation, at least.