[openssl-dev] openssl.org #4615 Cache utility behaving strange with X509_LOOKUP_add_dir

[Patel, Anirudh (Anirudh)]

Man page for X509_LOOKUP_hash_dir states something different though:


X509_LOOKUP_hash_dir is a more advanced method, which loads certificates and CRLs on demand, and caches them in memory once they are loaded. As of OpenSSL 1.0.0, it also checks for newer CRLs upon each lookup, so that newer CRLs are as soon as they appear in the directory

When checking for new CRLs once one CRL for given hash value is loaded, hash_dir lookup method checks only for certificates with sequence number greater than that of the already cached CRL.

a)      If you look at my scenario, firstly I did not had any CRL files under the CRL directory which has been loaded in the store when my server starts. For the incoming chain as ID/Sub CA/Root CA verify_callback is invoked which gives 3 errors X509_V_ERR_UNABLE_TO_GET_CRL one for each certificate and then follows with further validation.

b)      Then, when I placed the respective CRL files under the directory and I get the same incoming connection (chain: ID/Sub CA/Root CA) openssl verify_callback stops complaining about CRL files not found for the certs. Please note that I did not stop/start the server to load the store with CRL directory again. As stated in the man page, openssl rightly did a lookup and found new CRL files during the handshake.

c)       The problem is when a new CRL file for one the above issuer is placed under the CRL directory (with an incremented sequence number .rN) openssl is not looking at the newer CRL file but only considering the ones in the cache.

Let me know if the manual page description meant something different.

Thanks.

From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Mischa Salle
Sent: Tuesday, July 19, 2016 1:27 PM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] openssl.org #4615 Cache utility behaving strange with X509_LOOKUP_add_dir

Hi Anirudh,
this is as far as I know a very old issue (at least since 2002 or so). Basically a server needs to restart periodically in order to pick up changed CRLs. There are some workarounds, like forcibly reloading all the CRLs periodically, even those already in the store.
Mischa Salle

On Tue, Jul 19, 2016 at 9:32 AM, Patel, Anirudh (Anirudh) <anirudhp at avaya.com<mailto:anirudhp at avaya.com>> wrote:
It is not re-checking the files (new CRL for the same issuer) in the CRL directory
IssuerHash_YYYY.r0 (old crl for sub-ca)
IssuerHash_YYYY.r1 (new crl for sub-ca) ---> not looked up for an incoming client connection
IssuerXXXX.r0 (old crl for root ca)

I have mentioned the complete scenario in the ticket#4615

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org<mailto:openssl-dev-bounces at openssl.org>] On Behalf Of Salz, Rich
Sent: Tuesday, July 19, 2016 12:55 PM
To: openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>
Subject: Re: [openssl-dev] openssl.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__openssl.org&d=CwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=LGoV-7-LnJ190GCUHmne799_dEEFi6KVc51xhuhtJ10&s=ultotvw_l8QsxQ1Zf_5rbTjOo-JG_iZbExIaV7qPLOs&e=> #4615 Cache utility behaving strange with X509_LOOKUP_add_dir


> I have earlier raised an issue on how openssl is not looking up for newer CRLs in each lookup. The only CRL files it is taking into consideration are the ones present in the cache.

> Could you please provide some inputs on this as I am blocked on the implementation front.

You mean it's not fetching CRL's over the network?  Or re-checking the files?

--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwIF-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=aetYwxnSuG9CLQakXoaWRTkyEyx2DzRAan4VyAwUF44&s=V6DU-ZDPxeXtjMHdOVafHx4u7EzISeITtikifV3D7gs&e=
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=LGoV-7-LnJ190GCUHmne799_dEEFi6KVc51xhuhtJ10&s=F3JmB5AFiuX4fyQGRse7p8_yKB86uPYSSBlCWfApGfM&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160719/3f9b879f/attachment.html>