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
