There are many fields on a certificate revocation list (CRL) like Algorithm, Parameters, Issuer Name, This update date, Next update date, user certificate serial #, etc. While I understand the purpose of most of the fields, of what purpose is the field "next update date on a certificate revocation List?


Oooh, that's a tricky one.

Theoretically, the nextUpdate field is meant to be a (future) date at which a new, updated version of the CRL should be made available. The idea is that if you have a cached CRL, then there is no point trying to download a new one before that date.

In "true X.509" each relying party (a "relying party" is "some system which tries to validate a certificate") is supposed to have its own policy with regards to how old a CRL can become before becoming "too old". Yet a RP cannot guess when a new CRL will be available for all possible CA; we use certificates precisely because a RP does not know all possible CA in advance. Hence the nextUpdate field which conveys information about the CA update policy.

In practice, though, everybody took nextUpdate as a CRL expiry date. So the nextUpdate field means "don't bother download a new CRL before date T", all implementations of X.509 certificate validation consider it to mean "don't use this CRL beyond date T". That's not the same concept. "True X.509" does not handle CRL expiration at all, since every RP is supposed to apply its own policy, but that does not work in the Real World: existing CA, both root and non-root, don't have coherent enough CRL update policies to make a RP-local policy workable. E.g. some CA will update CRL only once per week, or even less than that, especially for offline CA; while others publish new CRL every hour.

Since everybody uses nextUpdate as a CRL expiration date, the CA have adapted and also fill that field with these semantics. Microsoft has also defined an extension called "Next CRL Publish" ( to convey the information about the scheduled next CRL publication date, i.e. the historical role of nextUpdate (this is a Microsoft-specific extension, I doubt anybody else uses it).

A common strategy for CA is to use some overlap: for instance, they publish one CRL every 24 hours, and the nextUpdate field is set to thisUpdate + 36 hours. That way, the new CRL is available 12 hours before the previous one "expires". Most clients will bother downloading a new CRL only if the one they have in their cache has its nextUpdate "in the past". Some clients (notably Windows) will download the new CRL some time before the nextUpdate if they have some good indication that a new CRL is indeed available, thus making the pre-fetch worth the effort (e.g. because there is a "Next CRL Publish" extension).

  • So certificate revocation list needs to be redistributed to everyone's browser periodically? If so, how does this revocation mechanism defend against a DoS on the channel used for CRL distribution? – doughgle Nov 3 '18 at 2:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy