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

Dr. Stephen Henson steve at openssl.org
Tue Mar 8 23:35:18 UTC 2016


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


More information about the openssl-users mailing list