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

[Mischa Salle]

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> 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] On Behalf Of
> Salz, Rich
> Sent: Tuesday, July 19, 2016 12:55 PM
> To: openssl-dev at openssl.org
> Subject: Re: [openssl-dev] openssl.org #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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160719/6472aa94/attachment-0001.html>