I've done quite a bit of reading about PKI in ADCS and CRL/OCSP, but I can't seem to find an answer to a small couple of questions I still have:

It is clear to me that even with OCSP in place, you still need a (delta) CRL (OCSP relies on a CRL to check if a certificate is valid or not for example) but that it's also important that clients have a URL to access the (delta) CRL.

What is not clear is whether a client will still download CRLs/delta CRLs even if a OCSP URL is provided in a certificate and that OCSP can be contacted.

It seems to me that what would make sense is something similar to (example with web server):

  • Client gets certificate from web server
  • Client needs to validate certificate so :
    • starts by checking whether the issuing CA is trusted
    • checks whether it has a recent CRL/OCSP reply in its cache, if so and if the cached reply says the cert is valid, then job done.
    • no cached reply is available so if both CRL and OCSP prefer OCSP over CRL list and ask the OCSP provider if certificate is valid. If OCSP replies, trust whatever it said.
    • If the OCSP does not reply/cannot be contacted, then fallback to using a CRL in which case a CRL is downloaded and used.
    • If CRL list cannot be downloaded either then... let's not get into this because that's a whole other topic on its own :)

Now what I'm not certain about is whether the above assumptions are correct, but even if they are it raises a few other questions (all questions assume that the above procedure is correct):

  1. If a certificate specifies both a OCSP and CRL and the OCSP fails to provide a reply, then the client falls back to CRL (and caches it). So what happens the next time that the user tries to go to the same website? Bearing in mind that a reply from CRL is cached, will it always trust that so long as its TTL hasn't expired and not attempt to contact the OCSP again?

  2. Does a client really only ever download a CRL/delta CRL if there is either no OCSP provided on the certificate or if the OCSP provides no answer?

  3. I have read that Vista OCSP Client caches replies, but cannot find information about how long it caches them for and whether this is configurable, can anyone clarify

  • I'm not sure what the base for two of your basic claims is, i.e. that OCSP relies on CRL (OCSP could directly be handled from the CA, no need to have CRL as an intermediate step) and that clients still need to have the URL for the (delta) CRL. CRL is for offline lookup, OCSP is for online lookup and there is no need for a client to do both online and offline lookup. Commented Mar 27, 2019 at 11:09
  • @SteffenUllrich documented here: blogs.technet.microsoft.com/askds/2009/06/24/… . As for whether the clients need to have the URL for the (delta) CRL it's clear they don't need to, but I assuming that if both OCSP and CRL listed in cert client will first check OSCP and if it can't CRL it makes sense to have a fallback (i.e., CRL).
    – JonU
    Commented Mar 27, 2019 at 12:06
  • I would rather say that some clients can make use of OCSP while other clients don't. Usually browsers don't download the CRL. And what you describe regarding OCSP relying on CRL: this is only necssary if there is a specific OCSP responder which is not the CA itself and which thus has no other source for revocation information than the CRL. Commented Mar 27, 2019 at 12:23
  • @SteffenUllrich that still doesn't answer what happens when both URLs for CRL and OCSP are available and a client is able to use both. Is my assumption above true in those scenarios? As for the OCSP Responder in ADCS, is there documentation confirming what you said? I couldn't find any myself and have to admit was surprised that an OCSP installed on a CA would still rely on CRLs ...
    – JonU
    Commented Mar 27, 2019 at 12:51
  • I can only tell you how it is with CRL and OCSP in general. But your question only marginally mentions a context of ADCS and otherwise asks for CRL and OCSP in a more general PKI context. The example given is also not specific for ADCS but describes only the communication between browser and webserver in general. If you want to restrict your question to ADCS then please make this more clear. Commented Mar 27, 2019 at 13:25

1 Answer 1


Section 6.3 of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile describes certificate validation using CRLs only - no mention of OCSP.

From Section 3.1 of RFC 5019 - The Lightweight Online Certificate Status Protocol (OCSP) for High-Volume Environments we can see that it's all rather vague (from a RFC 2119 point of view):

3.1. OCSP Responder Discovery

Clients MUST support the authorityInfoAccess extension as defined in [PKIX] and MUST recognize the id-ad-ocsp access method. This enables CAs to inform clients how they can contact the OCSP service.

In the case where a client is checking the status of a certificate that contains both an authorityInformationAccess (AIA) extension pointing to an OCSP responder and a cRLDistributionPoints extension pointing to a CRL, the client SHOULD attempt to contact the OCSP responder first. Clients MAY attempt to retrieve the CRL if no OCSPResponse is received from the responder after a locally configured timeout and number of retries.

[PKIX] above refers to RFC 3280 which has been obsoleted by RFC 5280

Therefore, it is mainly down to the client-side implementation as to the exact order of processing.

As to your last question (3), I believe Windows caches OCSP responses until they expire (nextUpdate) except where expiry information is not included, in which case they do not cache the response.

You must log in to answer this question.

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