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
