[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