4

We've got a scenario where the CRL is distributed to 2 different Locations. One ist accessable from a private network and not from the internet. The other one is asseccable from the internet but not from the private network. So to make sure that everey client (either located in the internet or in the private network) can access the CRL via http, I assume that I have to include both Locations as CRL Distribution Points in the certificate. I also assume that the Client (when checking the CRLs) is asking the 1st CRL Distribution Point first and if it does not get an "appropriate answer", it's asking the 2nd CRL Distribution Point. If it does get an "appropriate answer", it stops. Am I right until here?

What is an "appropriate answer", that makes the client stop asking next CRL Distribution Points? Does it only stop if it gets a proper CRL-File, or are there other scenarios (error codes, "not available"-messages) that make the Client stop trying "next" CRL Distribution Points?

mnnhrt
  • 41
  • 1

1 Answers1

3

CRL distribution points are location that the client must be able to resolve to a file. If the client is unable to obtain that file, it will go to the next location.

In order to obtain that file, the client must be able to:

  • Understand the schema of the endpoint (HTTP, LDAP, File, Whatever...)
  • Resolve the host name (if appropriate).
  • Contact the host name using the protocol mandated by the schema (HTTP, SMB, LDAP, etc.)
  • Query for the file path and receive an answer that is not an error.
  • Obtain the file data and verify that is is signed by the relevant certificate chain. (see RFC 5280 for reference)
  • Verify that the file is still valid (i.e. that the "next publish date" field is not in the past)

Now, the exact behavior of the client is dependent of the implementation so it's hard to be specific and since CRL validation tends to increase connection time massively, most real-life client will, by default, include some performance optimization that will cause the actual CRL validation not to be fully performed in many cases.

Community
  • 1
Stephane
  • 18,557
  • 3
  • 61
  • 70
  • `including not performing the validation at all by default under Windows, for instance` -- it is incorrect statement. – Crypt32 Mar 07 '19 at 11:32
  • @Crypt32 That default has changed over the time but for Windows 2008R2, at the very least, server CRL is disabled in internet options. – Stephane Mar 07 '19 at 11:40
  • Internet Options affect only IE and some built-in applications (not all. For example, mstsc, SSTP VPN client aren't affected by this setting). In fact, strict revocation checking is application-specific. Each application decides whether to fail on `RevocationOffline` error or silently continue. There is no OS-wide setting for revocation checking configuration. – Crypt32 Mar 07 '19 at 11:47
  • Just to backup my previous statement: https://social.technet.microsoft.com/wiki/contents/articles/964.certificate-revocation-list-crl-verification-an-application-choice.aspx this article covers just few Windows applications and services. – Crypt32 Mar 07 '19 at 11:54
  • @Crypt32 That setting affect any software that uses the WinHTTP component without changing its default. It might not affect the VPN but it does affect a great many Windows applications. – Stephane Mar 07 '19 at 12:09
  • @Crypt32 I've removed the comment: no matter who is right, it doesn't change anything to the answer – Stephane Mar 07 '19 at 12:50
  • The rest of your answer seems legit to me. – Crypt32 Mar 07 '19 at 12:51