> 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...
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 corr
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 an
s 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_cr
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> reg
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 def
