Hi Gregory,
-Original Message-
From: Gregory Sloop
[snip]
So, I thought - why should I set the default_crl_days to some low
number. I assume that it [the CRL] can be replaced with a new CRL,
should we need one, long before the default_crl_days limit is reached.
Is that correct?
So, if that's the case, what would be the downside of making the
default_crl_days equal to the validity of the CA itself, for example?
[e.g. If the CA cert is valid for 100 years, why not set the
default_crl_days to 36500+/- days too?]
Because some clients won't check back for 100 years...
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
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
I don't claim any expertise in this area, but RFC 5280 5.1.2.5 seems pretty
clear:
5.1.2.5 Next Update
This field indicates the date by which the next CRL will be issued.
The next CRL could be issued before the indicated date, but it will
not be issued
So, I'm working with an EAP-TLS system running under freeradius.
I've setup things to use a CRL [not OSCP] to revoke certificates and
all works well.
However, the parameter default_crl_days=XXX puzzles me.
Through trial and error [mostly error] I know that if I don't
regenerate the CTL every
