While studying a security course I have been asked this very question:
Why are CRL periodically renewed, even if there are no new revoked certificates to add to the list?

Honestly I can't find the answer, if any of you could be so kind to shed some light on it, I would be very grateful.

  • Well, a client using a CRL doesn't really know if there's a new entry. All it does is get the new list periodically, if there's a new entry then good, if there isn't then they check again later.
    – Adi
    Commented May 30, 2013 at 13:43
  • First of all thanks for the fast answer. I understand what you said, I still got one question tho: If I am the server, and I got no new revoked cert to add, why do i renew it? I basically keep it the same. Thanks again
    – AscaL
    Commented May 30, 2013 at 13:49

3 Answers 3


A couple fundamental things:

  • The basis of a CRL is a promise for a certain time period. That means a begin time and an end time. Once a CRL is made and signed, it can't be changed, so it lasts as long as it lasts, and can't be trusted after that.

  • In essence, you won't know until you check. A CRL in its regular form is one big list. You can't assume that the size is an indication... the verifier needs to know exactly what Certificates are no longer trusted. So you need to get a fresh copy, either way. There's no protocol to check "is this the same as my old one?"

  • The primary implementation of CRLs is not "go get one when you need it" but "get it ahead of time, and check it when you need to". Which means the primary mechanism of distribution is a series of file downloads and caches. A server won't know that the next CRL is exactly the same as the currently expiring CRL until it has both - at which point, if you have a fresh version, why check? If what is needed is a "ask when you need it, you'll always have access" sort of structure, then go with OSCP.

  • The basic rationale of validity dates is to allow PKI implementers to make a conscious decision about how long to go with out checking in with the CRL issuer. A PKI system will make this decision on an issuer by issuer basis, in accordance with the risk to the system and the patterns of its intended usage. It's a real challenge - the validity should be commensurate with the risk - how long are the system protectors willing to wait before checking in on the "known bad guy" list?

  • There's a basic premise here that I relate to looking at canned food in a submarine... the expiration date is how long the manufacturer promises that it'll be OK to consume it. Can you eat meat a day after the expiration date? Yep. In fact, day-old meat is a way better option than starving to death. What about meat that is 6 months past it's expiration date? Well.. what kind of germs are you up against? There's a real possibility that this food will make you sicker than not eating anything (just shutting down and doing no transactions until you have a fresh CRL). In all cases, the reality is, you weight the cost of doing business against the risk of uncertain data.

NOTE: All this applies only to a general, garden variety CRL. There's a number of alternate formats out there. Last I looked, they were all proprietary... but it's been a while... some of these alternate formats can work differently, as they all aim at simplifying.

  • CRLs don't have expirations - nextUpdate was never intended to mean "don't use after this date", despite the fact that this is indeed how all browsers treat it. Expiration policy, if you wanted one, was to be set out-of-band and was not communicated within the CRL. Commented Dec 21, 2015 at 19:32

In the X.509 model, there is no restriction on download. When a verifier (say, a Web browser) wants to validate a certificate, it will try to obtain extra information through other objects: certificates, CRL... and it may obtain these objects over insecure channels. That's the point of CRL being signed: a verifier will trust a CRL not because it just obtained it from a specific Web site, but because the CRL is signed by an authorized CRL issuer (usually the CA itself).

The bright side of such a principle is that it makes X.509 certificates applicable to all kinds of networks. Otherwise, you would have a rather harsh chicken-and-egg problem: how would you trust that you got the right, most recent revocation information ? Because you downloaded it from a HTTPS server ? But how did you verify the certificate of that server ? And so on...

But there is a dark side, of course: a CRL is a snapshot of revocation information at a given date. Being signed, it is immutable. It cannot be changed. It is thus always a bit stale. A verifier will require that the CRL it uses are "not too old" -- and that, inherently, implies regular publishing of newer CRL.

On the technical point of view, we may envision a specific kind of CRL which does not contain the whole list of revoked certificates (which can be bulky) but only a short message stating "no certificate revoked since that date", thus allowing to somehow extend the lifetime of a CRL. This exists; it is called delta CRL. With delta CRL, a new CRL is virtually emitted at regular intervals, without necessarily forcing the download of a new big file.

Unfortunately, not all software out there know how to use delta CRL.

Another technique is segmentation: split the CRL into many smaller files, each talking about only a subset of certificates. Down that road lie very small CRL which assert the revocation status of only one certificate at a time; this is known as OCSP. There again, support is in deployment.


What is crl And why Should it be revoked

From RFC 3280

A certificate revocation list (CRL) is a time-stamped listidentifying revoked certificates that is signed by a CA or CRL issuerand made freely available in a publicrepository.Each revoked certificate is identified in a CRL by itscertificate serial number.

When a certificate-using system uses a certificate (e.g., for verifying a remote user's digital signature), that system not only checks the certificate signatureand validity but also acquires a suitably recent CRL and checks hat the certificate serial number is not on that CRL.

From RFC 5280

The meaning of "suitably recent" may vary with local policy, but it usuallymeans the most recently issued CRLA new CRL is issued on a regular periodic basis (e.g., hourly, daily, or weekly).

An entryis added to the CRL as part of the next update following notification of revocation. An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyondthe revoked certificate's validity period.

An advantage of this revocation method is that CRLs may be
distributed by exactly the same means as certificates themselves, namely, via untrusted servers and untrusted communications.

CRl's would revoke when private key of an asymmetric encryption key pair (whose public key has been certified by the CA) is stolen.In such a situation, anybody with the private key could decrypt all communication between a user and the certified entity.

CRLs Will be issued periodically, in which case certificates that have expired may be tagged as revoked, or they may be issued as soon as a certificate is revoked. To keep CRLs from being faked, they are signed by the public key of the CA and contain a timestamp, after which the CRLs themselves expire.

Reasons for revocation :

According to ietf the common reasons for revocation were :


Reference 2

Reference 3

  • 2
    Plagiarism isn't welcome here, always make sure to mention the source. mysecurecyberspace.com/encyclopedia/index/…
    – Adi
    Commented May 30, 2013 at 14:29
  • 1
    You must clearly identify quoted text. Just saying “Reference” is not enough: you're claiming that the ideas are not original but that the words are your own, but it's a lie. Commented Oct 8, 2015 at 17:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .