Hello Dr. Henson, It's been a very long time since I've been on this list... it's great that you're still here :)!!!
We were kind of wondering about the hashes (we couldn't find how they were calculated, etc.). 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? I'm not on our production site yet, so I'll ask someone who is. I'm pretty sure that they didn't check for that as they have an automated task or something that they run under a cron job to re-calculate the hashes when they are downloaded. 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? A couple of more questions: 1) Re. what I said about about HOW the hashes are calculated: The docs say "based on the Issuer name". Is that mean literally, i.e., the hash is only a hash of the Issuer name inside the CRL and the other contents of the CRL, like signatures, etc. don't affect the value of the hash that openssl calculates?? In other words, assuming that the Issuer names in the CRLs don't change, can we just download update CRL files and NOT re-calculate the hashes in the CRL directory? 2) When you said "A couple of possibilities": Would the duplicate hashes cause an "Error 12"/Expired CRL error? That seems like an incorrect error? Thanks, Jim -------------------------------------------- On Tue, 3/8/16, Dr. Stephen Henson <st...@openssl.org> wrote: Subject: Re: [openssl-users] Something causing "Error 12"/Expired CRL during CRL processing To: "o haya" <oh...@yahoo.com>, openssl-users@openssl.org Date: Tuesday, March 8, 2016, 2:46 PM On Tue, Mar 08, 2016, o haya wrote: > > Our websites are configured for SSL client authentication with CRLs in a directory pointed to by SSLCACertificateRevocationPath and SSLCARevocationCheck set to "chain". We then place our CRLs in the directory and create the hashes for them using an app or script that we wrote. I think that this essentially does something like: > > ln -s ca.crl `openssl crl -hash -noout -in ca.crl`.r0 > > However, when we did a test upgrade one of our production instances the requests are failing and, in the error logs, we are seeing the following messages: > > A couple of possibilities. One is that the time isn't properly set on the machine which has this problem. Another is that there may be multiple CRLs with the same hash: have you checked for that? If there are you need to use the form .r1, .r2 etc. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
