[openssl-users] Something causing "Error 12"/Expired CRL during CRL processing
ohaya at yahoo.com
Wed Mar 9 00:09:43 UTC 2016
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.
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
> 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)
the result of the "openssl hash" gives an
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
issuer names will produce the same hash. Equivalent (i.e.
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
the CRLs into a big PEM file instead of as individual files
> 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
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
A question back: is
the CRL set fixed when you start the server or are you
trying to update them in real time?
Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
More information about the openssl-users