GS> So, I'm working with an EAP-TLS system running under freeradius. GS> I've setup things to use a CRL [not OSCP] to revoke certificates and GS> all works well.
GS> However, the parameter default_crl_days=XXX puzzles me. GS> Through trial and error [mostly error] I know that if I don't GS> regenerate the CTL every default_crl_days, the CRL expires and then GS> freeradius won't auth anything at all. GS> So, I thought - why should I set the default_crl_days to some low GS> number. I assume that it [the CRL] can be replaced with a "new" CRL, GS> should we need one, long before the default_crl_days limit is reached. GS> Is that correct? GS> So, if that's the case, what would be the downside of making the GS> default_crl_days equal to the validity of the CA itself, for example? GS> [e.g. If the CA cert is valid for 100 years, why not set the GS> default_crl_days to 36500+/- days too?] GS> I assume there's some other use, other than EAP-TLS, where doing this GS> might be a bad plan, but I'm afraid I can't think of one in the GS> EAP-TLS context with FreeRadius. Am I missing something? GS> [And I'd be glad to be pointed to another context, if there is one, GS> where setting a very long-ish default_crl_days would be bad - even if GS> it's fine in the setting I'm discussing. Knowing would be good GS> education.] === Perhaps it would be helpful if I give what I understand of this param, and someone can tell me if I'm right or not. As I understand it, if the CRL is older than the default_crl_days specified, it will ignore the CRL and ALL verification will fail. If you use a very long default_crl_days value, then an attacker could get you to accept a very old cached CRL by preventing you from retrieving the "new" CRL. Thus, this could likely be a security vuln. because you might not have all the proper revocations contained in a "current" CRL, and you rely on a cached version. By using a short default_crl_days you prevent any verification from relying on a cached CRL for longer than the default_crl_days. However in the FreeRadius setup I'm using, the FreeRadius server doesn't need to retrieve the CRL from anywhere else. It's local to the FreeRadius server. So, a very long CRL default_crl_days doesn't seem like a problem, as long as I make sure that the CRL on the FR server is current [i.e. contains all the revocations I need.] What I'm not certain about is: If I set default_crl_days to a really large value - can I update the CRL more often than the set value. [I'm virtually certain I can, but I'm not positive. It appears to be an upper-value limit, not a lower-value limit. (i.e. It *can* be replaced long before the default_crl_days expires, but it MUST be replaced before it's age exceeds default_crl_days - or the certificate checking will fail.] So, is that right, in general? TIA ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
