with a name not yet present. Once that file is loaded, it's not been loaded
from disk again (as implied by the 'caches'), also not when it changes.
meaning OpenSSL will get then from its cache.
Note that I don't like this behaviour, but I think it is as intended.
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.
Of *Mischa Salle
*Sent:* Tuesday, July 19, 2016 1:27 PM
*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) <
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-----
Salz, Rich
Sent: Tuesday, July 19, 2016 12:55 PM
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
Post by Patel, Anirudh (Anirudh)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.
Post by Patel, Anirudh (Anirudh)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
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=>
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev