Regarding this piece of code in verify.c:
if(X509_cmp_current_time(next_update)<0) { s_log(LOG_WARNING, "Found CRL is expired - " "revoking all certificates until you get updated CRL"); X509_STORE_CTX_set_error(callback_ctx, X509_V_ERR_CRL_HAS_EXPIRED); X509_OBJECT_free_contents(&obj); return 0; /* reject connection */ }
I don't believe this is correct functionality. The "next update" field is not an expiration of the CRL, but more of an indicator that you, as the holder of the CRL, should obtain a new one.
Snippet from this link:
http://www.netscape.ca/browser/netscape8/help/en/ssl_help.html#next_update
About the "Next Update" Date
The browser uses the CRLs it has available to check the validity of certificates issued by the corresponding CAs. If a certificate is listed as revoked, the browser won't accept it as evidence of identity.
A CA typically publishes an updated CRL at regular intervals. Every CRL includes a date, specified in the Next Update field, by which the CA will publish the next update of that CRL. In general, if the date in the Next Update field is earlier than the current date, you should obtain the most recent version of the CRL. To view CRL information and set up automatic CRL updating, see Viewing and Managing CRLs.
CAs are required to produce a new CRL by the Next Update date. However, the absence of the most recent CRL does not by itself invalidate a certificate. For this reason, if the most recent CRL is not available, a certificate may be validated even though the most recent CRL shows it as expired. Automatic CRL updating can help to avoid this situation.
I'd like to suggest removing this check.
Thanks, Steve
Steve Hoffman wrote:
I don't believe this is correct functionality. The "next update" field is not an expiration of the CRL, but more of an indicator that you, as the holder of the CRL, should obtain a new one. ...
I'd like to suggest removing this check.
Hi there
I think you're right Steve - but I'd not like to see that check disappear :-)
We're big users of PKI (well in my mind we are) and every product I've seen that supports CRLs treats it like stunnel today does. i.e. a CRL that is older than the "next update" field is treated as an error condition and access is refused until it is fixed.
However, some of those products did provide this feature as a flag. So you could basically ignore this issue if you wished. I for one 100% rely on it causing SSL-based products to refuse new connections until it is fixed. We have a 24 hour lifespan and all products looks for CRL updates every hour, so there should be no normal way that this causes a problem. However, if it did happen, it would imply something was majorly wrong and failing closed is the correct response.
... of course this does bring up an old question about stunnel's CRL support (see: "stunnel and expiring CRLs" ;-)
2009/2/4 Jason Haar [email protected]:
Steve Hoffman wrote:
I don't believe this is correct functionality. The "next update" field is not an expiration of the CRL, but more of an indicator that you, as the holder of the CRL, should obtain a new one. ...
I'd like to suggest removing this check.
Hi there
I think you're right Steve - but I'd not like to see that check disappear :-)
Hello,
I do not concur to your conclusion. The next update field is a protection against the following scenario : - CRL #1 on Monday, next update "some day" : empty - Tuesday : I loose my certificate -> new CRL #2 , next update "another day" and indicating my certificate as revoked.
If the server does not verify the field "next update", it can run with CRL #1 forever, ignoring the revocation of my certificate.
In fact, the field "next update" is a compromise between good confidence in the veracity of the CRL and the cost of updating a CRL on all servers which use the CRL. This compromise has to be decided by the CA itself, according to (defined by in fact) the Certification Policy. The server, using certificates and CRL which mention the Certification Policy has to apply the policy, which means refusing connection when CRL is expired.
Next to this topic, I posted a "strange CRL verification behaviour" mail on "Mon Nov 3 15:44:43 CET 2008" because I was baffled by the LOG "CRL passed" when in fact no CRL was found to verify a certificate.
Ref : RFC 2527 - Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework (http://tools.ietf.org/html/rfc2527) See ยง4.4.4 Certificate Suspension and Revocation
-- Christophe Nanteuil
-
Christophe Nanteuil -
Jason Haar -
Steve Hoffman