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

[o haya]

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