[openssl-users] Something causing "Error 12"/Expired CRL during CRL processing

[o haya]

Dr. Henson,

It turns out that the app apparently makes copies of the old CRL files before downloading new ones, i.e., so there were multiple copies of CRL files for the same CA.

They cleaned out the directory and left only one CA CRL and the ROOT CA CRL and then it worked.

Question:  What exactly is determines the ORDER in which the CRLs would be selected?

In other words, say there were two CRL files (the previous one and the current one) but one hash (only .r0) pointing to the current CRL file.  The reason for my question is that we're (or I) am still trying to understand why we'd get the Error 12/Expired CRL?  

In this case, there'd be only one hash/soft link, pointing to one of the CRL files, and no softlink pointing to the other CRL file.

So how does OpenSSL (or Apache?) decide which of the CRLs to work with?

Thanks,
Jim

--------------------------------------------
On Tue, 3/8/16, o haya <ohaya at yahoo.com> wrote:

 Subject: Re: [openssl-users] Something causing "Error 12"/Expired CRL during CRL processing
 To: "o haya" <ohaya at yahoo.com>, "Dr. Stephen Henson" <steve at openssl.org>
 Cc: openssl-users at openssl.org
 Date: Tuesday, March 8, 2016, 7:09 PM
 
 I'm not sure about the answer to your
 last question, but I will check tomorrow.
 
 I do know that the set of CAs is configured by us, and then
 they have either an app or script that gets run to
 re-download each of the CRLs intermittently.
 
 What I don't know is whether they restart/reload the Apache,
 but I'm guessing that that they do do that.  I'll
 confirm tomorrow.
 
 
 Based on what you said, and assuming we use individual files
 per CRL and with the hashes, and assuming that we just
 happen to have more than one CRL file that resulted in the
 same hash string, would that account for an Error 12/Expired
 CRL error?
 
 
 I guess the thing that still bothers me is that they've been
 using this scheme/approach for awhile with the earlier
 Apache and with openssl 0.9.8 until this upgrade attempt
 recently, and it's hard to believe that they'd all of sudden
 be encountering hash collisions and just at the time of
 upgrading the Apache 2.4.16 and openssl 1.0.1e?  Talk
 about bad luck :)!!
 
 
 I will post back tomorrow.
 
 Thanks,
 Jim
 
 
 
 --------------------------------------------
 On Tue, 3/8/16, Dr. Stephen Henson <steve at openssl.org>
 wrote:
 
  Subject: Re: [openssl-users] Something causing "Error
 12"/Expired CRL during CRL processing
  To: "o haya" <ohaya at yahoo.com>
  Cc: openssl-users at openssl.org
  Date: Tuesday, March 8, 2016, 6:35 PM
  
  On Tue, Mar 08, 2016, o
  haya wrote:
  
  > 
  > Can you clarify what you mean by
  "multiple CRLs with the same hash"?  Do you
  > mean a situation where we have several of
  the CRL files (for different CAs)
  > where
  the result of the "openssl hash" gives an
  identical number/string?
  > 
  
  The hash depends on the CRL
  issuer name only. It is first converted to a
  canonical form and then a hash taken of the
  encoding. That guarantees that
  identical
  issuer names will produce the same hash. Equivalent (i.e.
  equal but
  not having the same encoding)
  issuer names *should* produce the same hash. The
  hash is only 8 hex digits so there are only
  2^32 possible hashes which gives a
  1 in 2^16
  chance of a collision: but you'd get a different error
  in that case.
  
  > 
  > Re. the "time":  I'm pretty
  sure the system time is correct, but will have
  > them check, BUT if the time was wrong, how
  would it be able to work when we
  > put
  the CRLs into a big PEM file instead of as individual
 files
  with the
  > hashes?  In other words, if
  the system time was wrong, wouldn't that also
  > cause the CRL verify to fail when the CRLs
  were all in one big PEM file?
  > 
  
  If the CRLs are in a big file
  then the duplicate hash issue wont affect this.
  What this might be is if you have two CRLs with
  identical issuer name one of
  which has a
  nextUpdate after the current time (which is what causes
 the
  error)
  and one before. In the case of the
  hashes in a directory calling everytyhing
  .r0 only one CRL would be downloaded. In a big
  file the valid CRL would be
  selected of the
  two.
  
  A question back: is
  the CRL set fixed when you start the server or are you
  trying to update them in real time?
  
  Steve.
  --
  Dr
  Stephen N. Henson. OpenSSL project core developer.
  Commercial tech support now available see: http://www.openssl.org